init()'s implicitly evaluate the initial values for properties, and we aren't modeling
that correctly in the AST. This prevented the closure checker from noticing these
accesses, leading to SILGen crashing later. In the absence of proper AST modeling of
this, add special case handling for them.
Swift SVN r29508
The case where this comes up is when people name their app and framework
targets the same thing, or when they've renamed their test target module
in an attempt to avoid issues with NSClassFromString and differing
runtime names. We currently do various wrong things when this happens,
so just emit an error instead.
I left a hole for our overlays, which use '@exported import <the-current-module>'
to get at their Clang modules. The previous commit means this can be
replaced by -import-underlying-module, but that doesn't help our tests,
which use -enable-source-import for their overlays. Which we should stop doing.
rdar://problem/21254367
Swift SVN r29440
This makes it clearer that expressions like "foo.myType.init()" are creating new objects, instead of invoking a weird-looking method. The last part of rdar://problem/21375845.
Swift SVN r29375
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
Instead of forcing full application of '{super,self}.init' in the parser, and installing the RebindSelf semantic expr node early, make these constraints to Sema-time checks, and parse '<expr>.init' as a regular postfix production. This is a better separation of concerns, and also opens the door to supporting 'metatype.init()' in more general expression contexts (though that part still needs some follow-up sema work).
Swift SVN r29343
If P is a protocol, calling static methods or constructors
via values of type P.Protocol makes no sense, so let's prohibit
this.
Fixes <rdar://problem/21176676>.
Swift SVN r29338
Special-casing these as MemberRefExprs created an asymmetry
where unbound archetype instance methods (<T : P> T.f) could
not be represented. Treating class and protocol methods
uniformly also eliminates a handful of special cases around
MemberRefExpr.
SILGen's RValue and call emission peepholes now have to know
about DeclRefExprs that point to protocol methods.
Finally, generalize the diagnostic for partially applied
mutating methods to any partially applied function with an
inout parameter, since this is not supported.
Fixes <rdar://problem/20564672>.
Swift SVN r29298
result in slightly more descriptive diagnostics in some cases. (Specifically,
for diagnostics involving binary operators.)
(rdar://problem/21080030)
Swift SVN r29020
that make vardecls and subscripts immutable. This makes the indirect cases
a lot more specific ("this is a get-only property" instead of "this is
immutable") and allows us to consolidate a bunch of code:
2 files changed, 45 insertions(+), 119 deletions(-)
Swift SVN r28954
which tell you what the problem is, not just that you have one.
- Enhance diagnostics to be more specific about function calls producing
rvalues.
Swift SVN r28939
We no do not require "self." for closures capturing self in static/class methods.
While we do actually capture the metatype more than we should (rdar://21030087),
this doesn't matter to the developer, since this capture cannot cause a cycle
in the reference graph that they should have to reason about.
Swift SVN r28804
This sets the location of the implicit closure decls (like $0) to being the location
of the { in a ClosureExpr, instead of the location of the first use. The capture tracker
uses source location information of the decl and the DeclRefExpr to determine if the
referenced value was captured too early, which is what is causing this incorrect error.
Swift SVN r28802
Properly implementing a class whose methods capture variables
defined in the outer scope requires adding the captures as
hidden vars in the class and initializers, and seems
non-trivial.
Just diagnose this case for now instead of crashing.
Fixes <rdar://problem/20853958>.
Swift SVN r28481
<rdar://problem/15975935> warning that you can use 'let' not 'var'
<rdar://problem/18876585> Compiler should warn me if I set a parameter as 'var' but never modify it
<rdar://problem/17224539> QoI: warn about unused variables
This uses a simple pass in MiscDiagnostics that walks the body of an
AbstractFunctionDecl. This means that it doesn't warn about unused properties (etc),
but it captures a vast majority of the cases.
It also does not warn about unused parameters (as a policy decision) because it is too noisy,
there are a variety of other refinements that could be done as well, thoughts welcome.
Swift SVN r28412
Local functions may reference each other as long as they don't transitively capture any vars or other non-function local decls before their declaration.
Swift SVN r28394
checking checked cast via bridging. It prevented bridging upcasts using
'as!' from typechecking; we should emit an 'as!'->'as' warning instead.
Also, use ExplicitConversion constraint instead of Conversion when
determining whether a checked cast can be carried out unconditionally.
This matches the constraint used after applying the 'as!'->'as' fixit.
(Also, fix the error that was responsible for breaking
the expr/cast/bridged.swift test.)
<rdar://problem/19813772>
Swift SVN r28034
checking checked cast via bridging. It prevented bridging upcasts using
'as!' from typechecking; we should emit an 'as!'->'as' warning instead.
Also, use ExplicitConversion constraint instead of Conversion when
determining whether a checked cast can be carried out unconditionally.
This matches the constraint used after applying the 'as!'->'as' fixit.
<rdar://problem/19813772>
Swift SVN r28028
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
- <rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
- <rdar://problem/16927246> provide a fixit to change "let" to "var" if needing to mutate a variable
We now refer to an inout argument as such, e.g.:
t.swift:7:9: error: cannot pass 'let' value 'a' as inout argument
swap(&a, &b)
^
we also produce a note with a fixit to rewrite let->var in trivial cases where mutation is
being assed for, e.g.:
t.swift:3:3: note: change 'let' to 'var' to make it mutable
let a = 42
^~~
var
The note is produced by both Sema and DI.
Swift SVN r27774
We now produce diagnostics like:
- cannot pass 'let' value 'a' to mutating unary operator '++'
- cannot pass get-only property 'b' to mutating unary operator '++'
- cannot pass immutable value of type 'Int64' to mutating unary operator '++'
Swift SVN r27772
If you want to make the parameter and argument label the same in
places where you don't get the argument label for free (i.e., the
first parameter of a function or a parameter of a subscript),
double-up the identifier:
func translate(dx dx: Int, dy: Int) { }
Make this a warning with Fix-Its to ease migration. Part of
rdar://problem/17218256.
Swift SVN r27715
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
The type checker (and various other parts of the front end) jump
through many hoops to try to cope with the lack of a proper
declaration for an inferred type witness, causing various annoying
bugs. Additionally, we were creating implicit declarations for
derived/synthesized witnesses, leading to inconsistent AST
representations. This ch
Note that we'll now end up printing the inferred type aliases for type
witnesses, which represents a reversal of the decision that closed
rdar://problem/15168378. This result is more consistent.
Now with a simpler accessibility computation.
Swift SVN r27512
The type checker (and various other parts of the front end) jump
through many hoops to try to cope with the lack of a proper
declaration for an inferred type witness, causing various annoying
bugs. Additionally, we were creating implicit declarations for
derived/synthesized witnesses, leading to inconsistent AST
representations. This ch
Note that we'll now end up printing the inferred type aliases for type
witnesses, which represents a reversal of the decision that closed
rdar://problem/15168378. This result is more consistent.
Swift SVN r27487
for a member element reference. This improves error recovery and fixes cases where we'd
reject invalid code in unspaced situations (like "(.x)") this fixes rdar://20251513.
Swift SVN r26406
is invalid and produces a ParseError, recovery by producing an AST with an ErrorExpr in it
instead of dropping the initializer on the floor. This silences downstream errors about
"must have an initializer" sorts of stuff.
Swift SVN r26405
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
This location is used when deciding whether a capture has already been
initialized, and without it the compiler decides that the reference to
a name from the capture list should be rejected.
rdar://problem/19776255&20153574
Swift SVN r26103
In r22669, we expanded our parsing of T?? by using operator splitting. This works
great when the ?? is lexed as a postfix operator, but does the wrong thing when the ??
is lexed as an infix and there is whitespace around it. For that, we don't want to
process it as a type. This was reported in a number of places including on stack
overflow:
http://stackoverflow.com/questions/28430496/nil-coalescing-to-provide-default-values-in-swift-1-2
Swift SVN r25228
This is required to correctly use the mock SDK when the SDK overlay is
built and tested separately. (Otherwise, the mock SDK might not get
used, because the overlay SDK options would expand from the
%-substitution, appear first on the command line, and shadow the mock
SDK in the search path).
Swift SVN r25185
