We don't need to serialize the protocol's superclass, we can compute it from the
generic signature. Previously, we would drop the superclass while
serializing because we didn't check the generic signature in
SuperclassTypeRequest, which would cause us to cache `NULL` when we
called `setSuperclass` for a protocol with a superclass constraint.
Fixes rdar://50526401
...specifically `@objc dynamic`, that is. This is one case where we
/know/ that the override does not depend on the base in any way---any
attributes have already been propagated down, and there's no vtable
entry. This is especially important for properties, which have no
recovery if their accessors can't be deserialized.
rdar://50827914
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
The merge-modules phase doesn't have an active type checker, so we were bailing
out of property-wrapper queries before we had a chance to check the cache.
Move the check later, to the points where we actually need a type checker.
Fixes SR-10844 / rdar://problem/51484958.
Double-underscored names suggest the symbols aren't supposed to be used by framework
clients. This patch excludes the doc-comments of these symbols in swiftdoc files.
rdar://51468650
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
While computing a type of member via `getTypeOfMemberReference`
let's delay opening generic requirements associated with function
type until after self constraint has been created, that would give
a chance for contextual types to get propagated and make mismatch
originated in generic requirements much easier to diagnose.
Consider following example:
```swift
struct S<T> {}
extension S where T == Int {
func foo() {}
}
func test(_ s: S<String>) {
s.foo()
}
```
`foo` would get opened as `(S<$T>) -> () -> Void` and contextual `self`
type is going to be `S<String>`, so applying that before generic requirement
`$T == Int` would make sure that `$T` gets bound to a contextual
type of `String` and later fails requirement constraint `$T == Int`.
This is much easier to diagnose comparing to `$T` being bound to
`Int` right away due to same-type generic requirement and then
failing an attempt to convert `S<String>` to `S<Int>` while simplifying
self constraint.
Resolves: rdar://problem/46427500
Resolves: rdar://problem/34770265
That is, if a struct's generic requirements can't be deserialized,
drop the struct. This is the same logic that's already in play for
enums and (as of the previous commit) classes, so it should be pretty
well tested by now. (Hence the sole test I'm adding here, snuck into
superclass.swift because it's a superclass /constraint/ being tested.)
I don't know of any outstanding issues caused by this, but it was
weird to have it for enums and classes but not structs, so here we
are.
...instead of crashing. Also drop the class if its generic
requirements depend on a type that can't be loaded (instead of
crashing).
rdar://problem/50125674
Check the availability of decls that declare an opaque return type to ensure they deploy to a
runtime that supports opaque types.
rdar://problem/50731151
To distinguish between classes which have the same name (but are in different contexts).
Fixes a miscompile if classes with the same name are used from a different module.
SR-10634
rdar://problem/50538534
Serialize the relationship between a property that has an attached delegate
and its backing variable, so deserialization can reestablish that link.
Fixes rdar://problem/50447022.
This does several different things to improve how platforms are described in availability diagnostics:
• Mentions the platform in diagnostics for platform-specific @available(unavailable) attributes.
• Replaces “OS X” with “macOS”.
• Replaces “fooOS application extension” with “application extensions for fooOS”.
• Replaces “on fooOS” with “in fooOS”.
Fixes <rdar://problem/49963341>.
When Swift always copied the overlay dylibs into app bundles, it was OK
for these symbol references to be non-weak, but with the overlays now
part of the OS on Apple platforms, we need to handle backward deployment
scenarios where a new overlay does not exist on an old OS version.
A weak reference will serve to pull in the overlay dylib if it exists,
without causing a fatal error if it does not. rdar://problem/50110036
Fix a trio of issues involving mangling for opaque result types:
* Symbolic references to opaque type descriptors are not substitutions
* Mangle protocol extension contexts correctly
* Mangle generic arguments for opaque result types of generic functions
The (de-)serialization of generic parameter lists for opaque type
declarations is important for the last bullet, to ensure that the
mangling of generic arguments of opaque result types works across
module boundaries.
Fixes the rest of rdar://problem/50038754.
When we build incrementally, we produce "partial swiftmodules" for
each input source file, then merge them together into the final
compiled module that, among other things, gets used for debugging.
Without this, we'd drop @_implementationOnly imports and any types
from the modules that were imported during the module-merging step
and then be unable to debug those types
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
The OS sadly changes between Android ARMv7 and Android AArch64, to
avoid this and any future problems, mark the autolinking tests that
I can find with `UNSUPPORTED: autolink-extract`, which should apply
to all platforms that need autolink-extract.
This should remove these tests from failing in Android 64.
We already detected when a typealias /changed/ incompatibly; being
unable to deserialize it at all is just a very dramatic version of
that, right?
https://bugs.swift.org/browse/SR-9811
With this change, swiftc will still look for standard library and overlay modules in ../lib/swift (relative to the compiler), but if it doesn’t find them there, it will now look in usr/lib/swift in the SDK.
