The SILGen testsuite consists of valid Swift code covering most language
features. We use these tests to verify that no unknown nodes are in the
file's libSyntax tree. That way we will (hopefully) catch any future
changes or additions to the language which are not implemented in
libSyntax.
We're now double-diagnosing some things that are caught by both
SILGen and static enforcement; we can fix that later, but I want to
unblock this problem first.
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
computed property" errors when SILGen could determine that there was
an inout writeback alias, and have the code instead perform CSE of the
writebacks directly.
This means that we produce more efficient code, that a lot of things
now "just work" the way users would expect, and that the still erroneous
cases now get diagnosed with the "inout arguments are not allowed to
alias each other" error, which people have a hope of understanding.
There is still more to do here in terms of detecting identical cases,
but that was true of the previous diagnostic as well.
Swift SVN r20658
t2.swift:4:11: error: inout arguments are not allowed to alias each other
swap(&x, &x)
^~
t2.swift:4:7: note: previous aliasing argument
swap(&x, &x)
^~
This can (and arguably should) also be handled with a later diagnostic pass, but
handling it in SILGen gives us full range emission capability.
Swift SVN r20469
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
handle cases where the index lowers to exactly identical SILValue's. This is presently
pretty uncommon (except in the moderately common case of a direct reference to a "let Int"),
but is a nice base case.
The diagnostic we now get is:
t.swift:5:23: error: inout writeback through subscript occurs in multiple arguments to call, introducing invalid aliasing
swap(&array[i][j], &array[i][i])
^~~~~~~~ ~
t.swift:5:9: note: concurrent writeback occurred here
swap(&array[i][j], &array[i][i])
^~~~~~~~ ~
based on the fact that "i" lowers to the same SILValue.
Swift SVN r20376
introduced, as these are obvious miscompilations and clearly mystifying to our user base.
This is enough to emit diagnostics like this:
writeback_conflict_diagnostics.swift:58:70: error: inout writeback aliasing conflict detected on computed property 'c_local_struct_property'
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
writeback_conflict_diagnostics.swift:58:33: note: concurrent writeback occurred here
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
which isn't great, but is better than nothing (better wording is totally welcome!).
This doesn't handle subscripts (or many other kinds of logical lvalue) at all yet, so
it doesn't handle the swift WTF case, but this is progress towards that.
Swift SVN r20297
