optional evaluation context that produced the optional.
<rdar://problem/20377684> Oscillating fixit for optional chain calling method that returns non-optional
Swift SVN r28212
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
generic parameter 'T' is not used in function signature
func f8<T> (x: Int) {}
This commit takes Jordan't comments on r28181 into account:
- it produces a shorter error message
- it does not change the compiler_crashers_fixed test and add a new expected error instead
Swift SVN r28194
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
There is no way to infer the generic parameter 'T' if it is not used in function signature
func f8<T> (x: Int) {}
^
Swift SVN r28181
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
a list of their elements, instead of abusing TupleExpr/ParenExpr
to hold them.
This is a more correct representation of what is going on in the
code and produces slightly better diagnostics in obscure cases.
However, the real reason to fix this is that the ParenExpr's that
were being formed were not being installed into the "semantic"
view of the collection expr, not getting type checked correctly,
and led to nonsensical ParenExprs. These non-sensical ParenExprs
blocked turning on AST verification of other ones.
With this fixed, we can finally add AST verification that
IdentityExpr's have sensible types.
Swift SVN r27850
We now produce tailored diagnostics for assignment operators that are passed a non-mutable LHS,
e.g.:
t.swift:14:3: error: cannot pass 'let' value 'x' to mutating binary operator '/='
x /= 19
~ ^
t.swift:13:1: note: change 'let' to 'var' to make it mutable
let x = 42
^~~
var
Swift SVN r27780
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
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
Fixes a crash when the user uses such a type. (Which is probably a
mistake--they probably meant to make the whole closure optional--but
that's another issue.)
rdar://problem/20163908
Swift SVN r26274
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
necessary. Wrap forced optional fixit in parens if necessary.
<rdar://problem/20029786> Swift compiler sometimes suggests changing "as!" to "as?!"
Swift SVN r26189
- Strength reduce isAtStartOfBindingName() to just check for
identifier or _ and inline into its two callers.
- Rename Token::isIdentifierOrNone to isIdentifierOrUnderscore.
- Teach InVarOrLetPattern about matching patterns, so that the
parser knows when it is parsing an expression as a matching
pattern but is not yet inside a let/var pattern.
- Use newfound knowledge of matching patterns to refine handling
of unexpected let/var when parsing an expression, but not in a
pattern context, slightly improving QoI in invalid cases.
Swift SVN r26172
This was because the ambiguity between c-style and foreach loops wasn't being
properly handled. Use the canParsePattern() logic to handle this in full
generality.
Since that logic was unused, dust it off and clean it up a bit. Similarly,
remove some old vestigates of default argument parsing in tuples and
old-syntax array handling.
Swift SVN r26164
duplicated by the InVarOrLetPattern state in the Parser object. Beef
InVarOrLetPattern up so that we can remove it.
NFC except that we now reject pointless let patterns in foreach loops,
similar to how we reject var patterns inside of let patterns.
Swift SVN r26163
???'s stacked on top of each other in patterns. This wraps up:
<rdar://problem/19382878> Introduce new x? pattern
please kick the tires and let me know if you see any problems.
Swift SVN r26002
a let/var pattern. Now any identifier in one of these is a variable binding,
not sometimes a value references (depending on contextual syntax).
This isn't expected to have a widespread effect on existing real world code:
- No impact on the stdlib.
- It does fix two validation crash tests, but possibly because the original issue is hidden by a different diagnostic path in the compiler.
- This needed two tests to be tweaked to undistribute "let".
On the positive side, this means that "case let x?:" now works properly, woo.
Swift SVN r26000
In an existential context, allow 'case Enum.Case:' by implicitly introducing a cast pattern, treating it as 'case Enum.Case as Enum:'. This will be important for the error handling design, where we want ErrorType-conforming enums to be pattern-matchable out of an ErrorType existential using 'catch' patterns.
Swift SVN r25968
UnsafeMutablePointer<Void>, don't bind $T1 to Void. This fixes an
unintentional dependency on the order in which constraints are visited
by the solver.
Fix some resulting underconstrained expressions in the stdlib.
<rdar://problem/19835413> Reference to value from array changed
Swift SVN r25921
when it is the favored constraint of a disjunction.
This allows 'ns ?? "str" as String as String' to typecheck where ns is
an NSString. This does not regress the relevant test for 17962491.
<rdar://problem/20029786> Swift compiler sometimes suggests changing "as!" to "as?!"
Swift SVN r25910
If '{' is encountered immediately after 'if', assume that the condition
is missing. Apply the same treatment to while, do-while, for-in, and
switch. This way we're not trying to re-parse, backtrack, repurpose
misparsed closure bodies, etc. in those cases. Users who want to write a
condition that starts with '{' can wrap it in parens.
Addressing feedback re <rdar://problem/18940198>.
Swift SVN r25747
Update the locator when matching optional types in parallel fashion.
This causes the simplifyLocator() call to fail to simplify the locator
completely, and avoids the bogus diagnostic.
<rdar://problem/19836341> Incorrect fixit for NSString? to String? conversions
Swift SVN r25596
If appending 'as T' to an expression in a fixit, also suggest
parentheses around the resulting expression if it would otherwise be
parsed incorrectly.
Swift SVN r25168
