This seems to be the single most common bridge cast,
and repeated lookup seems to be a performance issue
for the common operation of bridging a string-valued
NSDictionary into Swift. Spending a couple of static
words of memory to memoize it should be a nice perf win.
Resolves rdar://55237013
The demangler tolerates arbitrary suffixes on mangled names, and parses them as a Suffix node. When looking up a class by an ObjC mangled name, we don't want such demanglings to succeed, because this will result in false positives. It's expected that NSClassFromString(someClassName + "some suffix") will fail, unless something has actually created a class with that suffix.
rdar://problem/60012296
These should hopefully all be uncontroversial, minimal changes to deal
with progressing the build to completion on OpenBSD or addressing minor
portability issues. This is not the full set of changes to get a
successful build; other portability issues will be addressed in future
commits.
Most of this is just adding the relevant clauses to the ifdefs, but of
note in this commit:
* StdlibUnittest.swift: the default conditional in _getOSVersion assumes
an Apple platform, therefore the explicit conditional and the relevant
enums need filling out. The default conditional should be #error, but
we'll fix this in a different commit.
* tgmath.swift.gyb: inexplicably, OpenBSD is missing just lgammal_r.
Tests are updated correspondingly.
* ThreadLocalStorage.h: we use the pthread implementation, so it
seems we should typedef __swift_thread_key_t as pthread_key_t.
However, that's also a tweak for another commit.
getDescription takes its argument at +1, but the implementation was passing the value directly. This caused the contained error value to be destroyed.
rdar://problem/59512630
The ConformanceCandidate constructor would eagerly instantiate metadata for
all non-generic types in the conformance cache. This was not the intention
of the code though, because it can compare nominal type descriptors --
which are emitted statically -- for those types that have them, namely
everything except for foreign and Objective-C classes.
Change the order of two calls so that the lazy path has a chance to run.
This fixes a crash when type metadata uses weakly-linked symbols
which are not available, which can come up in backward deployment
scenarios.
Fixes <rdar://problem/59460603>.
* SR-12161 Casting P.self to P.Type regressed in iOS13.4 beta
An earlier fix for certain protocol casts inadvertently disabled
the check for a protocol being cast to its own metatype.
This rearranges the code so that identical types always succeed.
It also updates swift_dynamicCastMetatypeUnconditional to
include recent changes to swift_dynamicCastMetatype.
Note: These fixes only apply to debug/non-optimized builds.
Cast optimizations still break a lot of these cases.
Extracted implementation of SpecializedGenericStructMetadataBuilder into
SpecializedGenericNominalMetadataBuilderBase, a CRTP with a template
template argument for the CRTP superclass and a template argument for
the implementation. That new type is now subclassed by
SpecializedGenericStructMetadataBuilder. Additionally, this new type is
also subclassed by the newly added SpecializedGenericEnumMetadataBuilder
which is responsible for build the prespecialization of generic enum
metadata.
rdar://problem/56960887
Due to some unfortunate interplay between clang and libstdc++, clang was
not able to correctly identify to alignment of PoolRange and
SideTableRefCountBits, causing it to emit library calls instead of
inlining atomic operations. This was fixed by adding the appropriate
alignment to those types. In addition to that the march for the Linux
target was set to 'core2', which is the earliest architecture to support
cx16, which is necessary for the atomic operations on PoolRange.
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.
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
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>
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.
