The find functions do not require the generic Value parameter. Moving them to __RawDictionaryStorage allows to define them with only one generic parameter: the Key.
This allows the optimizer to share specializations for dictionaries which have the same Key, but a different Value.
Also, prevent inlining of the find-functions to save some additional code size.
This commit adds initial build system support for macCatalyst,
an Apple technology that enables code targeting iOS
to be recompiled so that it can be executed on macOS while still using
iOS APIs. This is the first in a series of commits building out support for
macCatalyst in the compiler, runtime, standard library, and overlays. Swift
for macCatalyst represents the work of multiple people, including
Devin Coughlin, Ross Bayer, and Brent Royal-Gordon.
Under macCatalyst, compiler-provided shared libraries (including overlays)
are built as one of four kinds (or "flavors") of libraries,
each with different install names and Mach-O load commands. This commit
adds the build system infrastructure to produce these different
library flavors.
**macOS-like Libraries**
A "macOS-like" library (such as the GLKit overlay) is a plain-old macOS library
that can only be loaded into regular macOS processes. It has a macOS slice with
a single load command allowing it to be loaded into normal macOS processes.
**iOS-like Libraries**
An "iOS-like" library, such as the UIKit overlay, is a library with a
macOS slice but with a load command that only allows it be loaded into
macCatalyst processes. iOS-like libraries are produced by passing a new
target tuple to the compiler:
swiftc ... -target x86_64-apple-ios13.0-macabi ...
Here 'ios' (and an iOS version number) is used for OS portion
of the triple, but the 'macabi' environment tells the compiler
that the library is intended for macCatalyst.
**Zippered Libraries**
A "zippered" library can be loaded into either a macCatalyst process or
a standard macOS process. Since macCatalyst does not introduce a new Mach-O
slice, the same code is shared between both processes. Zippered libraries
are usually relatively low level and with an API surface that is similar
between macOS and iOS (for example, both the Foundation overlay and the Swift
Standard Library/Runtime itself are zippered).
Zippered libraries are created by passing both the usual `-target`
flag to the compiler and an additional `-target-variant` flag:
swiftc ... -target x86_64-apple-macos10.15 \
-target-variant x86_64-apple-ios13.0-macabi
Just like the -target flag, -target-variant takes a target tuple.
This tells the compiler to compile the library for the -target tuple but
to add an extra load command, allowing the library to be loaded into processes
of the -target-variant flavor as well.
While a single zippered library and slice is shared between macOS and
macCatalyst, zippered libraries require two separate .swiftinterface/.swiftmodule
files, one for macOS and one for macCatalyst. When a macOS or macCatalyst client
imports the library, it will use module file for its flavor to determine what
symbols are present. This enables a zippered library to expose a subset of its
target APIs to its target-variant.
**Unzippered-Twin Libraries**
"Unzippered Twins" are pairs of libraries with the same name but different
contents and install locations, one for use from macOS processes and one for
use from macCatalyst processes. Unzippered twins are usually libraries that
depend on AppKit on macOS and UIKit on iOS (for example, the MapKit overlay)
and so do not share a common implementation between macOS and macCatalyst.
The macCatalyst version of an unzippered twin is installed in a parallel
directory hierarchy rooted at /System/iOSSupport/. So, for example, while macOS
and zippered Swift overlays are installed in /usr/lib/swift/, iOS-like and
the macCatalyst side of unzippered twins are installed in
/System/iOSSupport/usr/lib/swift. When building for macCatalyst, the build system
passes additional search paths so that the macCatalyst version of libraries is
found before macOS versions.
The add_swift_target_library() funciton now take an
optional MACCATALYST_BUILD_FLAVOR, which enables swift libraries to indicate
which flavor of library they are.
Move the special flag handling for the non-atomic runtime into the build
system rather than spreading it across the build system and the helper
utilities.
This moves the build configuration information into the block which
prints the full configuration details for the Swift runtime. Simplify
the condition by merging the two blocks for building the standard
library and the `Differentiation` module.
SR-3871: Dynamic casting of existentials stored in Obj-C references
Arbitrary Swift objects get packaged into __SwiftValue containers so
that pointers to them can be passed into Obj-C. (Obviously, Obj-C
code can't do anything particularly useful with such pointers other
than refcount them and give them back to Swift code.) Those values come
back into Swift as either `Any` (existential box) or `AnyObject`
(anonymous object pointer) values. Dynamically casting those requires
first inspecting the outer value to get access to the actual type and
value in the __SwiftValue container.
The tryDynamicCastBoxedSwiftValue() function that handles this
was missing a check for the `Any` case, which is why directly
casting from `Any` would routinely fail.
Resolves SR-3871
This additional check lets the optimizer eliminate most of the append-code in specializations where the appended sequence is also an Array.
For example, when "adding" arrays, e.g. arr += other_arr
To allow more pervasive use of TypeRefs in LLDB, we need a way to build mangled
names from TypeRef pointers to allow round-tripping between TypeRefs and AST
types. The goal is to experiment with making lldb::CompilerType backed by
TypeRefs instead of AST types.
<rdar://problem/55412775>
This is a second pass at the original patch, which broke an OS test.
Due to an oversight it seems that we never added a
withContigousStorageIfAvailable implementation to SubString.UTF8View,
which meant that if you sliced a String you lost the ability to get fast
access to the backing storage. There's no good reason for this
functionality to be missing, so this patch adds it in by delegating to
the Slice implementation.
Resolves SR-11999.
This reverts commit 3e932c075d.
The compiler does not support @_alwaysEmitIntoClient properties
specially wrt property descriptors. The revert commit would introduce an
ABI incompatability when a keypath to Array.first is formed:
let greetings = ["hello", "hola"]
let count = greetings[keyPath: \[String].first?.count]
Runmning on an older runtime would lead to linker errors against $sSa5firstxSgvpMV
the property descriptor for Array.first.
rdar://58484319
All mutating Array functions must be annotated with semantics, because otherwise some high level optimizations get confused.
The semantic attributes prevent inlining those functions in high-level-sil.
This is need so that the optimizer sees that the Array is taken as inout and can reason that it's modified.
This restriction is not needed anymore when we’ll have COW representation in SIL.
rdar://problem/58478089
Due to an oversight it seems that we never added a
withContigousStorageIfAvailable implementation to SubString.UTF8View,
which meant that if you sliced a String you lost the ability to get fast
access to the backing storage. There's no good reason for this
functionality to be missing, so this patch adds it in by delegating to
the Slice implementation.
Resolves SR-11999.
Added a new flag to the GenericMetadataPatternFlags flagset for whether
the metadata has a set of flags at its tail. When that flag is set,
there will be an extra uint64_t flagset at the end of the metadata. For
struct metadata, the type of that flagset will be
StructMetadataTrailingFlags. The first flag in that trailing flagset
indicates whether the metadata was statically specialized. The second
flag in that trailing flagset indicates whether the metadata is
statically canonical.
When verifying the metadata cache, a check is done for whether the
metadata was statically specialized and whether it was known to be
canonical statically. If so, verification is skipped. Skipping it is
necessary because the known-canonical statically specialized metadata
will not be in the cache. In that case, the canonical statically
specialized metadata will be returned from the metadata accessor and
never be cached.
