When we scan the type metadata records or conformances to look
for a type by name, skip over indirect Objective-C class
references. We won’t find anything new there, but we’ll
currently crash if they exist.
Classes defined in Objective-C are mangled differently from
Swift-defined classes, and have no nominal type
descriptor. Recognize this mangling and search for the
appropriate Objective-C class using the Objective-C
runtime. Thread the resulting metadata through the mangled name
-> metadata decoder.
Protocols defined in Objective-C are mangled differently from
Swift-defined protocols. Recognize this mangling and search for the
appropriate Objective-C protocol using the Objective-C runtime.
Swift-defined @objc protocols are registered with the Objective-C runtime
under the Swift 3 mangling scheme; look in the Objective-C runting using
objc_getProtocol() with the appropriate name.
Also, correctly compute the "class bound" bit when forming a protocol
composition metatype. The information isn't in the mangled name when it
can be recovered from the protocols themselves, so look at the protocols.
Search through the new section containing Swift protocol descriptor
references to resolve protocols by mangled name. Use this
functionality to support protocol composition types within
_typeForMangledName.
Introduce a new section that contains (relative) references to all of the
Swift protocol descriptors emitted into this module. We'll use this to
find protocol descriptors by name.
TypeDecoder's interface with its builders already treated protocols as
a type (due to their being mangled as "protocol composition containing
one type"), and intermixed protocols with superclasses when forming
compositions. This makes for some awkwardness when working with
protocol descriptors, which are very much a distinct entity from a
type.
Separate out the notion of a "protocol declaration" (now represented
by the builder-provided BuiltProtocolDecl type) from "a protocol
composition containing a single type", similarly to the way we handle
nominal type declarations. Teach remote mirrors and remote AST to
handle the new contract.
_getTypeByMangledName() is more general and will be the way forward. Use
that instead. Note that we're still keeping around Foundation-only SPI
function _typeByName() in the Swift standard library, until we settle
on what the standard library API should be like for this functionality.
Now that all nominal types have nominal type descriptors, directly
search for nominal type descriptors when looking up metadata by
mangled name. This eliminates some bouncing between metadata and
nominal type descriptor when decoding a mangled name.
Introduce a flags parameter to swift_getTupleTypeMetadata(). Add a flag
stating when the "labels" parameter points into nonconstant memory, in
which case we need to make a copy of the string before adding an entry
into the concurrent map.
Introduce a standard library/runtime entry point that produces type metadata
given a mangled name, based on the TypeDecoder logic lifted from the remote
mirrors library.
Implement support for tuple types as a proof-of-concept.
Now that we use nominal type descriptors for everything that we can within
protocol conformance records, eliminate the unused
"NonuniqueDirectType" case and all of the code that supports it. Leave
this value explicitly reserved for the future.
Rather than emitting unique, direct type metadata for non-foreign
types, emit a reference to the nominal type descriptor. This collapses
the set of type metadata reference kinds to 3: nominal type
descriptor, (indirect) Objective-C class object, and nonuniqued
foreign type metadata.
Now that references to Objective-C class objects are indirected
(via UniqueIndirectClass), classes with Swift type metadata can be
directly referenced (via UniqueDirectType) rather than hopping through
swift_getObjCClassMetadata().
This is a small code size win, and also gives us some abstraction so that future cooperative ObjC compilers/runtimes might be able to interoperate ObjC class objects with Swift type metadata efficiently than they currently are in the fragile Swift runtime.
While I'm here, I also noticed that swift_getObjCClassMetadata was unnecessarily getting exposed in non-ObjC-interop runtime builds, so I fixed that as well.
Previously it was part of swiftBasic.
The demangler library does not depend on llvm (except some header-only utilities like StringRef). Putting it into its own library makes sure that no llvm stuff will be linked into clients which use the demangler library.
This change also contains other refactoring, like moving demangler code into different files. This makes it easier to remove the old demangler from the runtime library when we switch to the new symbol mangling.
Also in this commit: remove some unused API functions from the demangler Context.
fixes rdar://problem/30503344
This makes the demangler about 10 times faster.
It also changes the lifetimes of nodes. Previously nodes were reference-counted.
Now the returned demangle node-tree is owned by the Demangler class and it’s lifetime ends with the lifetime of the Demangler.
Therefore the old (and already deprecated) global functions demangleSymbolAsNode and demangleTypeAsNode are no longer available.
Another change is that the demangling for reflection now only supports the new mangling (which should be no problem because
we are generating only new mangled names for reflection).
Use the generic type lowering algorithm described in
"docs/CallingConvention.rst#physical-lowering" to map from IRGen's explosion
type to the type expected by the ABI.
Change IRGen to use the swift calling convention (swiftcc) for native swift
functions.
Use the 'swiftself' attribute on self parameters and for closures contexts.
Use the 'swifterror' parameter for swift error parameters.
Change functions in the runtime that are called as native swift functions to use
the swift calling convention.
rdar://19978563
The old method of constructing a mangled class name does not work anymore with the new mangling scheme.
Also, by using the re-mangler, _typeByName now works with class names containing non-ascii characters.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
The code we use to interface with the platform dynamic linker is turning into a rat's nest of conditionals that's hard to maintain and extend. Since ELF, Mach-O, and PE platforms have pretty fundamentally different dynamic linker interfaces and capabilities, it makes sense to factor that code into a separate file per-platform, instead of trying to conditionalize the logic in-line. This patch factors out a much simpler portable interface for lazily kicking off the protocol conformance and type metadata lookup caches, and factors the guts out into separate MachO, ELF, and Win32 backends. This should also be a much cleaner interface to interface static binary behavior into, assisting #5349.
This adds an Android target for the stdlib. It is also the first
example of cross-compiling outside of Darwin.
Mailing list discussions:
1. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151207/000171.html
2. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000492.html
The Android variant of Swift may be built using the following `build-script`
invocation:
```
$ utils/build-script \
-R \ # Build in ReleaseAssert mode.
--android \ # Build for Android.
--android-ndk ~/android-ndk-r10e \ # Path to an Android NDK.
--android-ndk-version 21 \
--android-icu-uc ~/libicu-android/armeabi-v7a/libicuuc.so \
--android-icu-uc-include ~/libicu-android/armeabi-v7a/icu/source/common \
--android-icu-i18n ~/libicu-android/armeabi-v7a/libicui18n.so \
--android-icu-i18n-include ~/libicu-android/armeabi-v7a/icu/source/i18n/
```
Android builds have the following dependencies, as can be seen in
the build script invocation:
1. An Android NDK of version 21 or greater, available to download
here: http://developer.android.com/ndk/downloads/index.html.
2. A libicu compatible with android-armv7.
This reverts commit 893d1dc523.
This looks like a likely culprit that broke tests on the iOS Simulator:
Failing Tests (6):
Swift :: IRGen/class_resilience.swift
Swift :: IRGen/concrete_inherits_generic_base.swift
Swift :: IRGen/enum_resilience.swift
Swift :: IRGen/foreign_types.sil
Swift :: IRGen/nested_types.sil
Swift :: IRGen/struct_resilience.swift
need to be modified by the runtime, and only actually store to them
when that would change anything.
Unfortunately, Linux is considerably better than Darwin at shaking
these bugs out because Darwin will leave global data mutable after
resolving relocations in it.
initialization in-place on demand. Initialize parent metadata
references correctly on struct and enum metadata.
Also includes several minor improvements related to relative
pointers that I was using before deciding to simply switch the
parent reference to an absolute reference to get better access
patterns.
Includes a fix since the earlier commit to make enum metadata
writable if they have an unfilled payload size. This didn't show
up on Darwin because "constant" is currently unenforced there in
global data containing relocations.
This patch requires an associated LLDB change which is being
submitted in parallel.
initialization in-place on demand. Initialize parent metadata
references correctly on struct and enum metadata.
Also includes several minor improvements related to relative
pointers that I was using before deciding to simply switch the
parent reference to an absolute reference to get better access
patterns.
