We just import this as a property, and Swift doesn't support
properties with dynamic Self type, even if they are read-only. Don't
mark the getter as returning dynamic Self in this case.
(This was only a problem in builds with the AST verifier turned on.)
https://bugs.swift.org/browse/SR-5684
Now that the GenericSignatureBuilder is no longer sensitive to the input
module, stop uniquing the canonical GSBs based on that module. The main
win here is when deserializing a generic environment: we would end up
creating a canonical GSB in the module we deserialized and another
canonical GSB in the module in which it is used.
Implement a module-agnostic conformance lookup operation within the GSB
itself, so it does not need to be supplied by the code constructing the
generic signature builder. This makes the generic signature builder
(closer to) being module-agnostic.
Once we compute a generic signature from a generic signature builder,
all queries involving that generic signature will go through a separate
(canonicalized) builder, and the original builder can no longer be used.
The canonicalization process then creates a new, effectively identical
generic signature builder. How silly.
Once we’ve computed the signature of a generic signature builder, “register”
it with the ASTContext, allowing us to move the existing generic signature
builder into place as the canonical generic signature builder. The builder
requires minimal patching but is otherwise fully usable.
Thanks to Slava Pestov for the idea!
Funnel all places where we create a generic signature builder to compute
the generic signature through a single entry point in the GSB
(`computeGenericSignature()`), and make `finalize` and `getGenericSignature`
private so no new uses crop up.
Tighten up the signature of `computeGenericSignature()` so it only works on
GSB rvalues, and ensure that all clients consider the GSB dead after that
point by clearing out the internal representation of the GSB.
This is legal Objective-C code:
typedef NSBar <NSFooing> BarAndFoo
@interface MyBaz : BarAndFoo
@end
// Equivalent
@interface MyBaz : NSBar <NSFooing>
@end
In Swift 3, we usually handled these by just dropping the protocol
part, making everything appear to work. (The protocols get added to
the class later, without looking at sugar.) However, in Swift 4, we
started supporting these compositions directly* and suddenly
inheriting from them didn't work (read: crashed the compiler). As an
extra twist, even Swift 3 can hit the problem case when the base type
is NSObject, because we figured 'id <NSObject, NSFooing>' was a better
approximation of 'NSObject <NSFooing> *' than 'NSObject *' was.
Fix this by just ignoring protocols when looking for a superclass. As
mentioned, we attach those separately anyway, so we aren't losing any
information.
* This isn't exactly true; there's still a difference between
'NSBar <NSFooing>' and 'NSBar <NSFooing> *'. Jacopo Andrea Giola fixed
a previous issue with this in a598277ad. But Swift doesn't do anything
meaningful with the first form, so it usually just pretends it's the
second.
rdar://problem/34586035
Funnel all places where we create a generic signature builder to compute
the generic signature through a single entry point in the GSB
(`computeGenericSignature()`), and make `finalize` and `getGenericSignature`
private so no new uses crop up.
Tighten up the signature of `computeGenericSignature()` so it only works on
GSB rvalues, and ensure that all clients consider the GSB dead after that
point by clearing out the internal representation of the GSB.
Once we compute a generic signature from a generic signature builder,
all queries involving that generic signature will go through a separate
(canonicalized) builder, and the original builder can no longer be used.
The canonicalization process then creates a new, effectively identical
generic signature builder. How silly.
Once we’ve computed the signature of a generic signature builder, “register”
it with the ASTContext, allowing us to move the existing generic signature
builder into place as the canonical generic signature builder. The builder
requires minimal patching but is otherwise fully usable.
Thanks to Slava Pestov for the idea!
Funnel all places where we create a generic signature builder to compute
the generic signature through a single entry point in the GSB
(`computeGenericSignature()`), and make `finalize` and `getGenericSignature`
private so no new uses crop up.
Tighten up the signature of `computeGenericSignature()` so it only works on
GSB rvalues, and ensure that all clients consider the GSB dead after that
point by clearing out the internal representation of the GSB.
...so that we don't have to keep coming back to update it every major
release. And also so we can actually put methods on it instead of
using free functions.
No intended behavior change (yet).
forEachDistinctName might produce the same name for Swift 4 and Swift
5, but it's possible that for some reason the name will only work in
one mode or the other. In that case, even though we're trying the
"same" name again, we still want to invoke the callback once more.
Add a boolean return to the callback to support this.
Tests to come at the end of this patch series -- this shows up when in
Swift 3 mode and the canonical version for types is set to Swift 5.
If an imported type conforms to a protocol with a synthesized
conformance, we only add a SynthesizedProtocolAttr, without
adding an entry to the inheritance clause. Otherwise the
ConformanceLookupTable records an explicit conformance and the
LazyConformanceLoader is lost.
There was some duplicate code for adding protocols to inheritance
clauses and constructing the SynthesizedProtocolAttrs that indicate
a conformance should have a LazyConformanceLoader.
Clean this up to make it less error-prone.
NFC for now, until further changes land.
Preparation for making ImportNameVersion a generalized struct rather
than an enum. We could have kept cramming it into a bitfield, sure,
but we don't actually need this.
No intended functionality change.
The base mutability of storage is part of the signature, so be sure
to compute that during validation. Also, serialize it as part of
the storage declaration, and fix some places that synthesize
declarations to set it correctly.
Right now the ClangImporter relies on Sema to synthesize typealiases
in some cases, which doesn't work if a Sema instance is not available,
for example when the ClangImporter is asked to import a declaration
while deserializing SIL during optimization.
Begin addressing this by synthesizing typealiases for the following
conformances:
- ExpressibleByArrayLiteral.ArrayLiteralElement while importing
OptionSets.
- RawRepresentable.RawValue while importing raw-valued enums.
- ObjectiveCBridgeable._ObjectiveCType while importing bridged
newtypes.
Until further changes land, this is mostly NFC, except for a change
in generated interface printing where the new typealiases are now
explicitly shown.
Note that non-bridged newtypes whose raw type is ObjectiveCBridgeable
still rely on associated type inference, because the ClangImporter
cannot safely "copy" the _ObjectiveCType typealias from the raw type
to the newtype, for various reasons mostly having to do with
circularity. Subsequent patches will address this, in a rather novel
fashion that will shock you.
Seen as @available attributes being printed with "_" in interface
generation, but fixing it in the importer means they can't leak into
anywhere else.
rdar://problem/30451293
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
