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
