resolution. When we see a polymorphic function type, we substitute
"deducible generic parameter" types for each of the generic
parameters. Coercion then deduces those deducible generic parameter
types. This approach eliminates the confusion between the types used
in the definition (which must not be coerced) and the types used when
the generic function is referenced (which need to be coerced).
Note that there are still some terrible inefficiencies in our handling
of these types.
Swift SVN r2297
Mangling is still a hack, pending a better type AST. Fixed
a bug where arguments passed indirectly were not being destroyed
by the callee (when passed by value). Changed some of the protocol
signatures to use the generic opaque pointer type, making the
types a bit more self-documenting in the IR.
Swift SVN r2274
value witnesses goes.
There are three major remaining things to do to support protocols:
- laying out the actual protocol members
- emitting witnesse for the actual protocol members
- detecting uses of the actual protocol members and funnelling
them through the witnesses as appropriate
All this work was just to let us treat protocol types as
first-class values.
Swift SVN r1899
in general, not sound. For the limited cases where we did use this
expression kind on lvalues (member access or instance method
invocations on a superprotocol), leave the conversion to the client of
their respective AST nodes (MemberRefExpr, DotSyntaxCallExpr). We may
decide to enrich these ASTs in the future with more information about
the conversion path, but it's not clear that it's actually useful
information for, e.g., IRgen.
Swift SVN r1830
pairs in extensions. The AST here is a little wierd; I don't
really get why there needs to be a PatternBindingDecl here.
It's easy enough to ignore.
Swift SVN r1592
This intentionally changes the mangling of variable getters and
setters so that we can have a reproducible mangling that doesn't
depend on things like the variables names, which is important
for resilience. It's not currently important for subscripting,
although equally I see no reason to mangle in the subscript
pattern name.
Swift SVN r1590
exactly how the arguments are emitted. Introduce a new code path
which emits arguments from existing Explosions (possibly of the wrong
resilience level). Use that code path to implement getter/setter
code for MemberRefExpr l-values. This is just a checkpoint for the
latter two parts, but the ApplyExpr path is working correctly in the
new framework, which is worth a commit.
Swift SVN r1589
