Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
'Self' can be used within parameters whenever the corresponding
parameter in a subclass will be contravariant, and in result types
when the method returns dynamic Self. This also applies to subscript
indices. More of <rdar://problem/16996872>.
Swift SVN r18788
sane and ad ProtocolConformance::getSubstitutedGenericParams() for
returning the generic params that were substituted into by a specialized
protocol conformance.
I am going to use this to handle inherited specialized inherited
conformance devirtualization.
Swift SVN r16907
This code is supposed to check that each subclass of ProtocolConformance
implements the invoked method. The copy-pasto was that when we were
supposed to be checking if SpecializedProtocolConformance overrode a
method, we were instead checking if InheritedProtocolConformance did so.
Luckily when I fixed this it looks like we are implementing all the
appropriate methods. But still a nice catch I feel.
Swift SVN r15273
Pass in the context generic parameters that correspond to the substitution vector in Substitution::subst. When we build the type substitution map, also collect the conformances from the substitutions into a map we can use to fill in those conformances in substituted substitutions where necessary, without relying on the '.Archetype' field.
Swift SVN r14964
Previously, we would try to generate a conformance for the type variable
(to the witness's requirement), fail, and then assert that we should have
succeeded. Now, we just let the type variable pass through with a null
conformance.
<rdar://problem/16078944>
Swift SVN r14617
A protocol conformance of a class A to a protocol P can be inherited
by a subclass B of A unless
- A requirement of P refers to Self (not an associated type thereof)
in its signature,
+ *except* when Self is the result type of the method in P and the
corresponding witness for A's conformance to B is a DynamicSelf
method.
Remove the uses of DynamicSelf from the literal protocols, going back
to Self. The fact that the conformances of NSDictionary, NSArray,
NSString, etc. to the corresponding literal protocols use witnesses
that return DynamicSelf makes NSMutableDictionary, NSMutableArray,
NSMutableString, and other subclasses still conform to the
protocol. We also correctly reject attempts to (for example) create an
NSDecimalNumber from a numeric literal, because NSNumber doesn't
provide a suitable factory method by which any subclass can be literal
convertible.
Swift SVN r14204
Change GenericFunctionType to reference a GenericSignature instead of containing its generic parameters and requirements in-line, and clean up some interface type APIs that awkwardly returned ArrayRef pairs to instead return GenericSignatures instead.
Swift SVN r13807
When applying getInheritedConformance to a specialized conformance, reapply the specialization to the found inherited conformance so we get a conformance for the same type we put in, making the specializer's job easier when finding conformances to insert into archetype_methods. To expose the problems this fixes, add a check in the SIL verifier that ArchetypeMethodInsts carry a ProtocolConformance that actually matches their lookup type.
Swift SVN r12988
Substitute a...um...substitution by remapping its Replacement mapping and recursively remapping any ProtocolConformances it has. Modify the Specializer to use Substitution::subst when specializing the substitutions of ArchetypeMethod and Apply instructions.
Swift SVN r12900
This is infrastructure toward allowing us to construct conformances
where there are type variables <rdar://problem/15168483>, which keeps
tripping up library work.
Swift SVN r12899
Lower types for SILDeclRefs from the interface types of their referents, dragging the old type along for the ride so we can still offer the context to clients that haven't been weaned off of it. Make SILFunctionType's interface types and generic signature independent arguments of its Derive the context types of SILFunctionType from the interface types, instead of the other way around. Do a bunch of annoying inseparable work in the AST and IRGen to accommodate the switchover.
Swift SVN r12536
SILGen eagerly produces witness tables for all of the conformances defined in the module, which is what we want in order to make them runtime-unique. Have IRGen follow suit. This should address a ton of radars about breakage with non-unique conformances once SIL witnesses are turned on. We will need some runtime machinery to handle witness tables with dependent fields, but since we currently ignore the associated type fields of witnesses, we can get away with emitting direct references to all witness tables for now.
Swift SVN r11608
We'll need to perform name lookup based on the file-level
DeclContext*, so the module no longer suffices. No functionality
change here yet.
Swift SVN r11523
This is a structural baby step toward lazily filling in protocol
conformances. We always build a ProtocolConformance, then mark it
either "complete" (when it's well-formed) or "invalid" (when it's
ill-formed). At present, the only benefit to this is that it slows
diagnostic cascades from invalid conformances.
Swift SVN r11492
A SpecializedProtocolConformance intentionally contains all of the
information we need to synthesize the type witnesses from the
underlying (generic) conformance. Do so lazily rather than eagerly,
because we won't always need all of them.
As a nice side effect, we no longer need to serialize the witnesses of
these specialized protocol conformances, so we can save some space in
the Swift module file.
Swift SVN r11303
It's useful to know what the open type variables in a generic protocol conformance are. For now, make the somewhat shaky assumptions that a NormalProtocolConformance for a bound generic type is for the DeclaredTypeInContext of its originating nominal type, that all type variables of the nominal type are open, and that specialized and inherited conformances bind all of the generic parameters.
Swift SVN r11274
