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 fixes the following two bugs:
1. We sometimes would create new conformances when deserializing a
witness method which would not be mapped in the SILModule to the
appropriate witness table. This would cause us to be unable to perform
devirtualization of this witness method. This is tested via a new
verifier check.
2. Different conformances would be created for an instance of a base
protocol and the original protocol. This would cause IRGen to try to
emit witness table global variables with differing types, hitting an
assertion. This is tested via a traditional test.
Swift SVN r15362
After chatting with Doug about this issue, the conclusion was reached that it is
more important to have the pointer identity of a protocol conformance be the
same for all types that reduce to the same canonical type.
Swift SVN r15335
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
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
1. Implement parser and sema support for our subscript syntax proposal in
protocols. Now you have to use subscript(..) { get } or {get set} to
indicate what you want. I suspect that the syntax will evolve, but at
least we can express what we need now.
2. Change the representation of SubscriptDecls in protocols to make
(empty) funcdecls for the getter and setter. This guarantees that
every subscript has at least a getter.
Swift SVN r12555
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
This prints the identifying info for a protocol conformance without the actual witness maps, recursively naming specialized or inherited conformances.
Swift SVN r10899
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
Factor the ProtocolConformance class into a small hierarchy of
protocol conformances:
- "normal" conformance, which provides a complete mapping for the
explicit conformance of a nominal type (which may be generic) to a
protocol;
- "specialized" conformance, which specializes a generic
conformance by applying a set of substitutions; and
- "inherited" conformance, which projects the conformance from a
superclass to a conformance for a subclass.
In this scheme "normal" conformances are fairly heavyweight, because
they provide a complete mapping. Normal conformances are unique,
because they're associated with explicit conformance declarations
(which cannot be repeated within a module; checking is TBD). Thus, IR
generation will eventually emit them as strong symbols.
"Specialized" and "inherited" conformances occur when we're dealing
with generic specializations or subclasses. They project most of their
members through to some underlying conformance, eventually landing at
a "normal" conformance. ASTContext is responsible for uniquing these
conformances when it sees them. The IR generation model for
specialized conformances will involve runtime specialization of the
underlying witness table; inherited conformances are probably no-ops
from the IR generation perspective.
Aside from being the right thing to do, having small, uniqued
conformances for the specialization and inheritance cases is good for
compile-time performance and memory usage. We're not really taking
advantage of this everywhere we could, yet.
This change uncovered a few existing issues (one known, one not
known), particularly because we're projecting inherited conformances
rather than building new conformances:
- <rdar://problem/14620454>: protocol witnesses to methods of
classes need to perform dynamic dispatch. See the
test/Interpreter/typeof.swift test for an example.
- <rdar://problem/14637688>: comparing NSString and String with ==
fails, because they are inter-convertible. I suspect we were missing
some protocol conformances previously, and therefore accepting this
obviously-invalid code.
Swift SVN r6865
When we notice that a type implicitly conforms to a protocol but is
not explicitly stated to do so, note this and provide a Fix-It
attaching the conformance to a declaration within the translation
unit, e.g.,
t.swift:28:16: error: type 'S1' does not explicitly conform to protocol 'P'
var p1 : P = S1()
^
t.swift:8:8: note: introduce explicit conformance to protocol 'P'
struct S1 : Q {
^
, P
Swift SVN r6760
This makes ProtocolConformances fully self-identifying so that a ProtocolConformance* pointer alone is enough to identify a conformance as a link entity.
We currently lose the conforming decl during deserialization because trying to deserialize a reference to an ExtensionDecl asserts out. I'll bug Jordan about that.
Swift SVN r6735
Previously, we only tracked the mapping from associated types to their
type witnesses. Now, also track the protocol conformances for each of
the requirements placed on the associated types.
Swift SVN r6655
