Objective-C subscripts don't have special declarations like
properties; they're just specially-named methods (or method pairs),
and we have to make an independent SubscriptDecl in Swift. This means
that when a subclass wants to make a subscript settable, they just add
the appropriately-named setter method.
Swift handled this by detecting when the getter and setter weren't
declared in the same type, and assuming this meant it was a subclass
adding a setter. Unfortunately, the same condition /also/ picked up
the case where the getter (and only the getter) is /redeclared/ in a
subclass (perhaps to add an attribute), and the new subscript was
getting added to the base class instead of the subclass.
The fix relies on the fact that the original decl we provide is what
we use to look up the other accessor. If the getter and setter are in
different types, whichever one we started with must be the
more-derived one. So the final change is just "did we start with the
setter?" rather than "is there a setter at all?".
I'm not sure why this is only just now causing problems, given that we
seem to have been getting this wrong for years, but it definitely
/was/ wrong and now it's not.
rdar://problem/36033356
(and vice versa)
Inadvertant fallout from 7725e38d96, which concerned accidental ambiguity
when mirroring protocol methods onto an implementing class.
https://bugs.swift.org/browse/SR-5959
Rather than storing contextual types in the type witnesses and associated
conformances of NormalProtocolConformance, store only interface types.
@huonw did most of the work here, and @DougGregor patched things up to
complete the change.
These kinds of synthesized declarations no longer need to go
through the constraint solver, since they have simple enough
bodies that we can construct type checked AST directly:
- rawValue getter and init(rawValue:)
- memberwise struct initializer
- zero struct initializer
Partially reverts f4f8349 (from July!) which caused us to start
importing global blocks with unbridged parameters, breaking source
compatibility. I'm still investigating whether there's an actual hole
in the logic; see next few commits.
rdar://problem/34913634
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.
