- We switch to a model where let properties may be "initialized", but never
reassigned. Specifically, immutable properties in structs/classes may have
an init value specified in their declaration (but can then never be reset
in any init implementation) or not (in which case they must be initialized
exactly once on all paths through every init. This makes a lot more sense
for immutability, defines several problems away, and provides a path to
supporting things like (rdar://16181314)
- We now *never* default initialize an immutable property. Formerly
we would default initialize optional let properties to nil, but this
isn't actually useful, and allows an error of omission with let
properties.
This resolves: <rdar://problem/19035287> let properties should only be initializable, not reassignable
and possibly other radars.
Swift SVN r23779
It returns the argument and specifies that the value is not negative.
It has only an effect if the argument is a load or call.
The effect of this builtin is that for the load/call argument a positive range metadata is created in llvm ir.
I also added a public function _assumeNonNegative(x: Int) -> Int in the stdlib.
To be on the save side, I prefixed it with an underscore. But maybe it makes sense to make it available for all users.
Swift SVN r23582
Dramatically improve DI diagnostics in initializers fixing rdar://18414728.
As one small example of the improvement, where an initializer like this:
class Foo {
var path:String? {
return "boo"
}
let aaaaa:String
init() {
if let p1 = path {
used to produce the error: "error: variable 'self.aaaaa' used before being initialized" on path,
we now produce:
x.swift:9:21: error: use of 'self' in property access 'path' before all stored properties are initialized
if let p1 = path {
^
x.swift:6:9: note: 'self.aaaaa' not initialized
let aaaaa:String
^
which is more useful.
Swift SVN r22238
As one small example of the improvement, where an initializer like this:
class Foo {
var path:String? {
return "boo"
}
let aaaaa:String
init() {
if let p1 = path {
used to produce the error: "error: variable 'self.aaaaa' used before being initialized" on path,
we now produce:
x.swift:9:21: error: use of 'self' in property access 'path' before all stored properties are initialized
if let p1 = path {
^
x.swift:6:9: note: 'self.aaaaa' not initialized
let aaaaa:String
^
which is more useful.
Swift SVN r22223
This raises an error for some cases we don't implement correctly yet, though not ones that require super.init or self.init delegation yet.
Swift SVN r21669
This isn't the theoretically purest way to do it--when we find ourselves reentering TypeLowering, instead of asserting, complain about the type being recursive. There's a nonzero chance this will complain about legitimate cases we just don't implement correctly, but it beats crashing. Recover by returning an address-only TypeLowering, which is sufficient to keep SILGen moving after the failure. <rdar://problem/16423940>
Swift SVN r20789
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
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
This has two changes:
- In the case when we have an invalid source loc, DI will default to emitting diagnostics
at the enclosing function's location. This makes it more robust in general against
implicitly synthesized code.
- For this diagnostic in particular, emit a tailored message, since super.init is a commonly
synthesized thing.
Swift SVN r20104
property in a base class before calling super.init. This is a nice improvement,
and also avoids regressing on QoI when a patch I'm working on finally lands.
Swift SVN r15379
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
