This allows a library to "fix" an initializer that should have been
failable or non-failable by gating the change on the user's version of
Swift. Failability (and whether or not the initializer throws) is
something that doesn't change the "overload signature", so normally
the compiler would call this an invalid redeclaration. But since only
one version can be active at a time based on the client context, there
won't be a problem in practice.
https://bugs.swift.org/browse/SR-4171 / rdar://problem/30470854
I realized in the process of doing this that methods may also have
mismatched 'throws', and we should allow that as well. Next commit.
If a convenience initializer in a subclass delegated to an inherited initializer from its base, we would end up type-checking the reference to the base class constructor as returning the base type, leading to type mismatches in the result AST and downstream crashes. We can wrap up the synthesized OtherConstructorRefExpr in a CovariantFunctionConversionExpr, which will trick the type checker into propagating the covariant result that gets rebound to `self` on return, avoiding this problem. (For now, I'm avoiding making the constructor decl formally have a Self return type, since that exposes a bunch of downstream breakage in code paths that only expect FuncDecls to be covariant, and also affects the mangling of constructors, causing a bunch of test case thrash we really don't want to inflict on the 3.1 branch.)
Value type initializers must initialize stored properties directly
if they do not delegate to another initializer via self.init().
Since direct stored property access is not permitted for resilient
value types from outside their resilience domain, this means that
such initializers are prohibited in two cases:
- If the initializer is defined in an extension from outside the
value type's resilience domain
- If the initializer is public and @_inlineable, since it might get
inlined outside the value type's resilience domain
Right now, such initializers cannot *assign* to self either;
I filed <https://bugs.swift.org/browse/SR-3686> to track the issue.
Swift does not currently support user-defined factory inits. With
import as member, we're seeing many C functions now imported as
initializers, which gives users the false hope that they can define
their own factory inits as conveinence inits in extensions of CF
types. We issue an explicit error now, rather than crashing later.
With the previous resolveTypeInContext() patch, a few compiler
crashers regressed with this problem, presumably because we were now
performing lookups in more contexts than before.
This is a class of problems where we would attempt a recursive
validation:
1) Generic signature validation begins for type T
2) Name lookup in type context finds a non-type declaration D nested in T
3) Generic signature validation begins for D
4) The outer generic context of D is T, but T doesn't have a generic
signature yet
The right way to break such cycles is to implement the iterative
decl checker design. However when the recursion is via name lookup,
we can try to avoid the problem in the first place by not validating
non-type declarations if the client requested a type-only lookup.
Note that there is a small semantic change here, where programs that
were previously rejected as invalid because of name clashes are
now valid. It is arguable if we want to allow stuff like this or not:
class A {
func A(a: A) {}
}
or
class Case {}
enum Foo {
case Case(Case)
}
However at the very least, the new behavior is better because it
gives us an opportunity to add a diagnostic in the right place
later. The old diagnostics were not very good, for example the
second example just yields "use of undeclared type 'Case'".
In other examples, the undeclared type diagnostic would come up
multiple times, or we would generate a cryptic "type 'A' used within
its own definition".
As far as I understand, this should not change behavior of any existing
valid code.
<stdin>:1:16: error: nil cannot initialize specified type 'Int'
var foo: Int = nil
^
<stdin>:1:10: note: add '?' to form the optional type 'Int?'
var foo: Int = nil
^
?
Migrate the check for whether a given type is representable in
Objective-C, which is currently used to verify when @objc can be
inferred or verify that an explicitly-written @objc is well-formed,
from Sema into a set of queries on the Type within the AST library, so
it can be used in other parts of the compiler.
As part of this refactoring, clean up and improve a number of aspects
of this code:
* Unify the "trivially representable" and "representable" code paths
into a single code path that covers these cases. Clarify the
different levels of "representable" we have in both the code and
in comments.
* Distinguish between representation in C vs. representation in
Objective-C. While we aren't using this now, I'm anticipating it
being useful to allow exporting C interfaces via @_cdecl (or
similar).
* Eliminate the special cases for bridging String/Array/Dictionary/Set
with their Foundation counterparts; we now consult
_ObjectiveCBridgeable conformances exclusively to get this
information.
* Cache foreign-representation information on the ASTContext in a
manner that will let us more easily get the right answer across
different contexts while providing more sharing than the TypeChecker
version.
Annoyingly, this only seemed to fix a small class of error where we
were permitting Unsafe(Mutable)Pointer<T> to be representable in
Objective-C when T was representable but not trivially representable,
e.g., T=String or T=AnyObject.Type.
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
Put in some rudimentary logic for finding circular references within
the iterative type checker and diagnosing those cycles. The
"rudimentary" part is because we're performing linear searches within
a stack rather than keeping a proper dependency graph, which is
inefficient and could display longer cycles than are actually
present. Additionally, the diagnostic is not specialized to the actual
query, so we get a generic "circular reference" diagnostic. OTOH, we
show all of the declarations involved in the cycle, which at least
lets the user figure out where the cycle occurred.
Enable the iterative type checker for resolving the type of a global
typealiases.
Swift SVN r32572
of providing contextual diagnostics (e.g. producing the warning in
Constraints/dynamic_lookup.swift). This drops a specific diagnostic about
force casting the result of as! which was added in the Swift 1.2 timeframe
to explain the change in cast semantics. Now that as! has been around for
a long time, it is more confusing than helpful.
Swift SVN r31887
- Enhance the branch new argument label overload diagnostic to just
print the argument labels that are the problem, instead of printing
the types inferred at the argument context. This can lead to confusion
particularly when an argument label is missing. For example before:
error: argument labels '(Int)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
after:
error: argument labels '(_:)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
Second, fix <rdar://problem/22451001> QoI: incorrect diagnostic when argument to print has the wrong type
by specifically diagnosing the problem when you pass in an argument to a nullary function. Before:
error: cannot convert value of type 'Int' to expected argument type '()'
after:
error: argument passed to call that takes no arguments
print(r22451001(5))
^
Swift SVN r31795
forced conversion to "_ -> T" if it will refine the type otherwise found by
doing a non-contextual type check. This allows us to diagnose calls to
non-function values with more specificity, e.g. adding another case were we
recommend "do" when using bare braces.
Swift SVN r31726
use that contextual type to guide typechecking of the callee. This allows us to
propagate that type through generic constraints effectively, making us produce
much more useful diagnostics within closures taking methods like "map" (for
example).
This fixes:
<rdar://problem/20491794> QoI closures: Error message does not tell me what the problem is
Specifically, running the testcase:
enum Color { case Unknown(description: String) }
let xs: (Int, Color) = [1,2].map({ ($0, .Unknown("")) })
produces: error: cannot convert call result type '[_]' to expected type '(Int, Color)'
Changing that to:
let xs: [(Int, Color)] = [1,2].map({ ($0, .Unknown("")) })
produces: error: missing argument label 'description:' in call
... with a fixit to introduce the label.
This also fixes most of 22333090, but we're only using this machinery for CallExprs
so far, not for operators yet.
Swift SVN r31484
Two fixes here:
1) Actually check if the ApplyExpr's base is self, instead of assuming
that anything other than a super call is a constructor call on self, to
avoid flagging UnresolvedConstructorExprs formed from Metatype.init()
calls as delegations.
2) Sometimes this is called after parts of the body has been type checked,
here we had the opposite problem, a ConstructorRefCallExpr of a
constructor on self wasn't detected as such.
Fixes <rdar://problem/21914985>.
Swift SVN r30852
The exact message is mostly immaterial at this point, but without the
change we end up recursively validating the property, marking it invalid,
and then never actually emitting a diagnostic, leaving SILGen and
Serialization to go ahead and fail.
rdar://problem/20913392
Swift SVN r30830
Adjust our placement of RebindSelfInConstructorExpr to fall outside of
a force-value expression (!), allowing, e.g.,
self.init(somethingThatCanFail: x)!
and
super.init(somehtingThatCanFail: x)!
Start suggesting '!' when chaining/delegating to a failable
initializer from a non-failable one, in addition to suggesting that
the enclosing initializer become failable.
Note that DI cannot handle this yet, so this is only the Sema part of
rdar://problem/18497407.
Swift SVN r30219
Enhance fixItRemove() to be a bit more careful about what whitespace it leaves around: if the thing it is removing has leading and trailing whitespace already, this nukes an extra space to avoid leaving double spaces or incorrectly indented results.
This includes an extra fix for looking off the start of a buffer, which extractText doesn't and can't handle.
This fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29449
if the thing it is removing has leading and trailing whitespace already, this nukes
an extra space to avoid leaving double spaces or incorrectly indented results. This
fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29419
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
The diagnostic we were producing was confusing the user into thinking that
you couldn't have a delegating init on a struct. Improve the diagnostic and
add a fixit hint.
Swift SVN r27872
Introduce basic validation for throwing @objc initializers, e.g., a
failable @objc initializer cannot also be throwing. However,
Objective-C selector computation is broken.
Swift SVN r27292
Previously, we attempted to infer @objc-ness based on conformance, but
doing so is fraught with ordering dependencies, and just doesn't work
in the general case. Among other crimes, this allowed us to
retroactively mark a non-@objc method from an imported module as
@objc... even though nobody would ever then emit the @objc entry
points for it.
Fixes the rest of rdar://problem/18383574.
Swift SVN r24831
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
- 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
This makes sure we get the same checking for initializer delegation in
structs/enums as we do for classes, fixing rdar://problem/18458622.
Swift SVN r23128
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 is useful when making an Objective-C class conform to a Swift
protocol. Note that we can only implement this safely for non-@objc
protocols, where we have a witnes function that can perform the
checked unwrapping.
Swift SVN r21782
