swift234

Teach the inout aliasing diagnostic that a certainly narrow class of AST expression (which
lower to different SILValue's are actually identical.  These are the expression involved
in turning an integer literal into an expression.  This is totally a hack in that we assume
that all "convertFromIntegerLiteral" are side effect free, but is close enough to be useful
for this diagnostic.  The right answer is to implement real attributes to model this 
(rdar://15587352).

That said, this diagnostic is pretty useful as it is.  For example, the SwiftWTF blog post
(http://swiftwtf.tumblr.com/post/91934970718/xcode-6-beta-3) has two examples.  The first
one passes this diagnostic unscathed because there is no inout aliasing problem: "a" is a
physical lvalue, not a logical one and a[1] doesn't alias a[2].  

However, the second example is now rejected with an error message of:

t.swift:12:18: error: inout writeback through subscript occurs in multiple arguments to call, introducing invalid aliasing
swap(&aa[0][1], &aa[0][2])
                 ^~~~~ ~
t.swift:12:7: note: concurrent writeback occurred here
swap(&aa[0][1], &aa[0][2])
      ^~~~~ ~

This is a violation even though "aa" is physical lvalue, because "aa[0]" is a logical
lvalue and we can now detect that the two instances of "aa[0]" are identical (because
we can tell the two 0's are identical).  I'm still not thrilled with the diagnostic, but
I think this will help stem a common source of problems in practice.

As more lvalues become physical or get auto-CSE'd (either with better SILGen CSE, with 
physical i addressors, etc) this diagnostic will automatically track SILGen.



Swift SVN r20377