Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Allows us to distinguish between "we know this conformance exists" and
"we're doing a detailed check of this conformance". Use it, rather
than membership in the nebulous ASTContext-wide caching structure
"ConformsTo", to detect recursive attempts to complete a conformance.
Swift SVN r26248
* Lift NormalProtocolConformance::hasTypeWitness() to
ProtocolConformance. This method can be used to determine whether a
potentially invalid conformance has a particular type witness.
* ProtocolConformance::getWitness() may return nullptr if the witness
does not exist.
* In TypeChecker::getWitnessType(), don't complain that a builtin
protocol is broken if it's the conformance that's broken.
* ConformanceChecker should only emit diagnostics from within calls to
checkConformance().
* TypeChecker::conformsToProtocol() now returns true if the type
has a declared conformance to the protocol, regardless of whether the
conformance is valid. Clients must check the validity of the
ProtocolConformance themselves if necessary.
<rdar://problem/19495341> Can't upcast to parent types of type constraints without forcing
Swift SVN r25326
... and stop doing it when we're separating the archetypes of
extensions from the types they extend. I wasn't able to isolate a
useful test case for this; it triggers when building the standard
library with extension archetypes separated.
Swift SVN r20814
Previously, we only retained the module in which a normal protocol
conformance occurred, which meant we either had to go searching for
the appropriate extension (yuck) or do without that information. This
is part of the separating-extension-archetypes work.
Swift SVN r20793
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
