Validation of the input side of FunctionTypeRepr was previously being done in Sema because of expression folding. If we instead push the invariant that the input TypeRepr should always be a TupleTypeRepr into the AST a number of nice cleanups fall out:
- The SIL Parser no longer accepts Swift 2-style type declarations
- Parse is more cleanly able to reject invalid FunctionTypeReprs
- Clients of the AST can be assured the input type is always a TupleType so we can flush Swift 2 hacks
Previously the placement of the OpenExistentialExpr was determined
entirely from the natural argument count of the function.
There was a hack to add any missing OpenExistentialExprs at the top
level, but this didn't work if the method had a Self return value
and there were intermediate expressions, eg, if someMethod has a
Self return, foo(anExistential.someMethod) would generate a
diagnostic about open existentials.
Change ExprRewriter to use a new existential placement algorithm
that instead walks up the expression stack to determine the outermost
function application of an existential base, and insert the
OpenExistentialExpr there.
Progress on <rdar://problem/21289579>.
Swift SVN r29448
Special-casing these as MemberRefExprs created an asymmetry
where unbound archetype instance methods (<T : P> T.f) could
not be represented. Treating class and protocol methods
uniformly also eliminates a handful of special cases around
MemberRefExpr.
SILGen's RValue and call emission peepholes now have to know
about DeclRefExprs that point to protocol methods.
Finally, generalize the diagnostic for partially applied
mutating methods to any partially applied function with an
inout parameter, since this is not supported.
Fixes <rdar://problem/20564672>.
Swift SVN r29298
