Add the request `ProtocolRequiresClassRequest` to lazily determine if a
`ProtocolDecl` requires conforming types to be a class.
Note that using the request evaluator to compute `requiresClass` introduces
cycle errors for protocol declarations, where this computation didn't
previously emit diagnostics. For now, we'll allow duplicate diagnostics in this
case, with the eventual goal of removing explicitly checking for cycles
via `checkCircularity` (instead letting the request evaluator handle cycle
diagnostics).
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.
When deserializing an opaque type xref inside an extension context, we were looking
incorrectly in the base module of the type being extended, rather than in the module
of the extension, where the opaque type would really be. Fixes rdar://problem/51775500.
This includes a small refactoring of OpaqueTypeDecl deserialization to break the inevitable
cycle between deserializing the namingDecl, and the namingDecl turning around and re-
deserializing its opaque return type. This is NFC but avoids some unnecessary work.
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
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
Similar to 517f5d6b6a, the "shadowed" terminology didn't end up
describing the most common use of the feature; there is pretty much no
intended case where a Swift module shadows a Clang module without also
re-exporting it. Switch to "underlying", which was already in use in a
few places, and which better parallels "overlay".
No intended functionality change.
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.
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.
Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
* Moves the IsStatic flag from VarDecl to AbstractStorageDecl.
* Adds a StaticSubscriptKind to SubscriptDecl.
* Updates serialization for these changes.
* Updates SubscriptDecl constructor call sites for these changes.
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
Introduce stored property default argument kind
Fix indent
Assign nil to optionals with no initializers
Don't emit generator for stored property default arg
Fix problem with rebase
Indentation
Serialize stored property default arg text
Fix some tests
Add missing constructor in test
Print stored property's initializer expression
cleanups
preserve switch
complete_constructor
formatting
fix conflict
It still has side effects, and it's still a lambda rather than a
helper function because it's not used anywhere else, but `[&]`
captures in helper lambdas make me nervous (as opposed to callback
lambdas).
Decls need to do this to avoid re-entrancy issues, but it turns out
types are simpler. I left a dummy "result" variable in the minimize
churn, since I'm going to move all the cases into their own functions
anyway.
