its fields are initialized. Before:
t.swift:18:24: error: variable 'self.B' captured by a closure before being initialized
after:
t.swift:19:24: error: 'self' captured by a closure before all members were initialized
self.A.withCString { cString -> () in
^
t.swift:14:7: note: 'self.B' not initialized
var B: Int
^
This drives home the fact that 'self' is being captured here, not the individual
properties.
Diagnostic categories are entirely unused and arguably useless as
implemented, as they merely denote the sub-component of the
compiler.
As far as categorizing warnings are concerned, I'm abandoning the
effort for now, as the utility is marginal and Swift and the Swift
compiler are probalby not ready for these to be nailed down. For the
sake of cleanliness, the CATEGORY field is also stripped from
WARNINGS.
If there's a need for automatic identifying of compiler sub-components
for diagnstics in the future, there are better ways to do this.
NFC
There's no longer a direct use of the variable's address when we invoke the closure, but we have a handy mark_function_escape instruction to mark the use without requiring merging analysis of the box and its contents. This also gives us a slightly more accurate error message when a variable is prematurely captured, noting the variable was captured by a closure instead of just generically used.
Designated initializers in NSManagedObject subclasses, or other
classes with @requires_stored_property_inits cannot assign to
stored properties before doing a super.init() delegation.
Assignments after are OK.
DI did the wrong thing by creating a bitmap with only one bit,
but proceeding down the usual designated initializer path.
Now, handle [derivedselfonly] more like a convenience initializer,
with no stored property access allowed prior to delegation.
Also clean up duplicated diagnostics between designated and
convenience initializers, and make convenience initializers
diagnose method calls or property accesses on self in the same
manner as designated initializers.
Fixes <rdar://problem/22110837>.
Swift SVN r32858
The problem was an uninitialized memory access. Callers were passing
the address of a local variable to isInitializedAtUse(), but this
function only stored to the pointer conditionally. Serendipitously
(or not), in the debug build the initial value was always zero.
Swift SVN r32599
Since a delegation consumes the self value, there's no self value available
in a catch block. Previously we would crash at runtime.
The diagnostics suck right now, so this is mostly for testing and
completeness.
Fixes <rdar://problem/22946400>.
Swift SVN r32583
This removes the partially-correct ABI check in Sema and diagnoses
unsupported conversions in SILGen instead. The new check is more
accurate and correctly diagnoses conversions of DeclRef's to
ABI-incompatible @convention(c) types.
This also fixes two cases where we used to crash but could instead
emit a trivial cast:
- Conversions between ABI-compatible (but not identical)
@convention(c) types
- Conversions of a DeclRef to an ABI-compatible (but not identical)
@convention(c) type
Fixes <rdar://problem/22470105>.
Swift SVN r32163
chain to another self.init, hopefully resolving confusion about what
has to be done here.
This fixes <rdar://problem/21295093> Swift protocol cannot implement default initializer
Swift SVN r29571
explicit to nudge people in the right direction of how to use it.
Fixes <rdar://problem/21355414> Error on forgetting to return on a guard
Swift SVN r29552
We now produce:
t.swift:1:15: error: negative integer '-9223372036854775808' overflows when stored into unsigned type 'UInt'
var x: UInt = -0x8000_0000_0000_0000
^
Swift SVN r27797
missing piece now is Sema support for detecting invalid exits
out of defer bodies. That said, SILGen will also detect it,
and produce an error if sema misses something, e.g.:
t.swift:11:23: error: defer statement is not allowed to be exited
while false { defer { break } }
^
t.swift:12:9: error: defer statement is not allowed to be exited
defer { return }
^
we should still diagnose these in Sema for better QoI of course.
This wraps up: <rdar://problem/17302850> Add a defer keyword to swift
Swift SVN r27760
On that testcase, we now generate:
t.swift:8:22: error: integer literal '123456' overflows when stored into 'UInt8'
case tooFarByFar = 123456
^
t.swift:7:8: error: integer literal '256' overflows when stored into 'UInt8'
case twoHundredFiftySix
^
instead of spitting out some warnings with no source loc (which Xcode eats).
This patch:
- Propagates source locations for literals when synthesizing code in various places,
so we get the right diagnostic at the right spot.
- Improves the constant folding SIL Pass to print the value overflowing, which is
necessary for cases with an implicit value (like 256 above), and is general goodness
for the QoI of the diagnostic anyway.
Swift SVN r27756
This falls out of the rework I did of 'self' in initializers. We now correctly
dealloc_ref the allocated object on the failure path of a convenience init.
Swift SVN r27752
...and similar for NSDictionary and NSSet.
For APIs that don't have a reason to distinguish "empty" and "absent" cases,
we encourage standardizing on "empty" and marking the result as non-optional
(or in Objective-C, __nonnull). However, there are system APIs whose
implementations currently do return nil rather than an empty collection
instance. In these cases, we recommend /changing/ the API to return the
appropriate "empty" value instead.
However, this can cause problems for backwards-deployment: while the API is
truly non-optional on system vN, a program may encounter a nil return value
if run on system vN-1. Objective-C can generally deal with this (especially
if the only thing you do is ask for the count or try to iterate over the
collection) but Swift can't. Therefore, we've decided to "play nice" and
accept nil return values for the collection types (NSArray, NSDictionary,
and NSSet) and implicitly treat them as "empty" values if they are the
result of an imported function or method.
Note that the current implementation has a hole regarding subscript getters,
since we still make an AST-level thunk for these in the Clang importer.
We can probably get rid of those these days, but I didn't want to touch
them at this point. It seems unlikely that there will be a subscript that
(a) is for a collection type, and (b) mistakenly returned nil in the past
rather than an empty collection.
There's another hole where an ObjC client calls one of these mistakenly-nil-
returning methods and then immediately hands the result off by calling a
Swift method. However, we have to draw the line somewhere.
(We're actually going to do this for strings as well; coming soon.)
rdar://problem/19734621
Swift SVN r26479
This patch also introduces some SILGen infrastructure for
dividing the function into "ordinary" and "postmatter"
sections, with error-handling-like stuff going into the
final section. Currently, this is largely undermined by
SILBuilder, but I'm going to fix that in a follow-up.
Swift SVN r26422
in a failable initializer. Previously, it would always just say "properties of a class
instance must be initialized before returning nil".
Now, in designated inits, it adds to that message with notes for each member that is not
initialized but must be. It also adds a note saying that super.init() must be called if
that is the problem.
In convenience inits, it says:
"failable convenience initializer must delegate to self.init() before returning nil"
For example, in:
class B : A {
var x : Int
override init?() { return nil }
We now produce:
t.swift:13:15: error: all stored properties of a class instance must be initialized before returning nil from an initializer
t.swift:11:7: note: 'self.x' not initialized
t.swift:13:15: note: super.init must be called before returning nil
I don't see any radars about this, but someone was confused on the dev forums:
https://devforums.apple.com/message/1113604#1113604
Swift SVN r26166
... now that we have an exquisitely shaved yak.
This provides a simple and uniform model for "let" constants: they are always either
immediately initialized in their declaration, or they are initialized dynamically
exactly once before any use.
This is a simple generalization of our current model for initializers, but enables
the use of let constants in more cases in local context, e.g. patterns like this:
let x : SomeThing
if condition {
x = foo()
} else {
x = bar()
}
use(x)
Previously this would have to be declared a "var" for no good reason: the value is
only ever initialized, never actually mutated.
The implementation of this is reasonably straight-forward now that the infrastructure
is in place: Sema treats 'let' constants as "settable" if they lack an initializer
(either in the declaration or in a non-PBD binding). This exposes them as an lvalue
at the AST level. SILGen then lowers these things to an alloc_stack, and DI enforces
the "initialization only" requirement that it already enforces for uninitialized 'let'
properties in structs/classes.
Swift SVN r23916
