Fixes rdar://55560962 and https://bugs.swift.org/browse/SR-11495
This bug was caused because we'd fail to lookup C in B, because we
hadn't computed its type yet and therefore B is filtered from lookup.
Just remove the filter for interface type.
This removes it from the AST and largely replaces it with AnyObject
at the SIL and IRGen layers. Some notes:
- Reflection still uses the notion of "unknown object" to mean an
object with unknown refcounting. There's no real reason to make
this different from AnyObject (an existential containing a
single object with unknown refcounting), but this way nothing
changes for clients of Reflection, and it's consistent with how
native objects are represented.
- The value witness table and reflection descriptor for AnyObject
use the mangling "BO" instead of "yXl".
- The demangler and remangler continue to support "BO" because it's
still in use as a type encoding, even if it's not an AST-level
Type anymore.
- Type-based alias analysis for Builtin.UnknownObject was incorrect,
so it's a good thing we weren't using it.
- Same with enum layout. (This one assumed UnknownObject never
referred to an Objective-C tagged pointer. That certainly wasn't how
we were using it!)
Harden more of the serialization functions to propagate errors for
the caller to handle these errors gracefully. This fixes a crash in
finishNormalConformance when indexing a system module with an
implementation-only import.
rdar://problem/52837313
...fulfilling the promised audit from 0747d9a339. No intended
functionality change /other/ than the order of already-unsorted lists.
This affected a number of SIL tests that relied on deserialization
order matching the original source order; I have no idea why the old
hash logic would make that the case. If we think that's a valuable
property, we should serialize a list of functions in addition to the
iterable table. (Maybe just in SIB mode?)
This means that we no longer have the invariant that the extendedType always
contains the generic parameters. So we need to fix the assertions/test cases
for it.
The change to relax forced autolinking symbol emission restrictions
caused a regression due to over-fitting of the output where the
symbol's comdat annotation was not accounted for. Adjust the test
accordingly.
This flag is set by DefinitInitialization if the lifetime of the stored value is controlled dynamically.
If the flag is set, it's not (easily) possibly to statically calculate the lifetime of the stored value.
If we're allowed to know at IRGen time what the underlying type of an opaque type is, we can
satisfy references to the opaque type's metadata or protocol witness tables by directly referencing
the underlying type instead.
The android API level can be ignored when loading the module. The API
level controls the NDK APIs which are available and is equivalent to the
SDK version for Darwin. This allows us to keep the API level in the
triple which future versions of Android's toolchain does.
Accessors logically belong to their storage and can be synthesized
on the fly, so removing them from the members list eliminates one
source of mutability (but doesn't eliminate it; there are also
witnesses for derived conformances, and implicit constructors).
Since a few ASTWalker implementations break in non-trivial ways when
the traversal is changed to visit accessors as children of the storage
rather than peers, I hacked up the ASTWalker to optionally preserve
the old traversal order for now. This is ugly and needs to be cleaned up,
but I want to avoid breaking _too_ much with this commit.
Once accessors are no longer listed as members of their parent context,
a failure to deserialize a VarDecl or SubscriptDecl needs to create a
MissingMemberDecl with the total number of vtable entries expected for
all of the accessors of the storage.
Note that until the accessor change actually lands, we always compute
the expected number of vtable entries as 0.
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
on behalf of the debugger. The debugger will read the LinkLibrary's
from all the modules it sees, and hand load all the required dependencies,
and since the symbol is weak it doesn't even tell us whether a
required dependency is missing. So it serves no purpose in this case.
<rdar://problem/51463642>
If a protocol inherits from a protocol that can't be loaded, drop it
entirely. Similarly, if it has requirements that reference types in
other modules that can't be loaded, drop the protocol entirely---at
least for now, we don't want to deal with a protocol that exists but
has the wrong requirement signature. That "in other modules" isn't
perfect, but it avoids cases where two protocols depend on each other.
Unfortunately, it means the compiler may still get into exactly the
situation above if a protocol depends on another protocol in the same
module, and /that/ protocol can't be loaded for some other reason. But
it's progress.
This comes up when referencing implementation-only-imported protocols
from non-public protocols, but is also just general deserialization
recovery goodness.
rdar://problem/52141347
When the outermost property wrapper associated with a property has a
`wrapperValue`, create the projection property (with the `$` prefix)
at the same access level as the original property. This puts the
wrapped-value interface and the projection interface at the same level.
The newly-introduced @_projectionValueProperty attribute is implicitly
created to establish the link between the original property and the
projection value within module interfaces, where both properties will
be explicitly written out.
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
