For context, String, Nil, and Bool already behave this way.
Note: Before it used to construct (call, ... (integer_literal)), and the
call would be made explicit / implicit based on if you did eg: Int(3) or
just 3. This however did not translate to the new world so this PR adds
a IsExplicitConversion bit to NumberLiteralExpr. Some side results of
all this are that some warnings changed a little and some instructions are
emitted in a different order.
Try to fix constraint system in a way where member
reference is going to be defined in terms of its use,
which makes it seem like parameters match arguments
exactly. Such helps to produce solutions and diagnose
failures related to missing members precisely.
These changes would be further extended to diagnose use
of unavailable members and other structural member failures.
Resolves: rdar://problem/34583132
Resolves: rdar://problem/36989788
Resolved: rdar://problem/39586166
Resolves: rdar://problem/40537782
Resolves: rdar://problem/46211109
If someone uses it twice, or on a non-final case, or tries to use it
with a multiple-pattern case, don't bother checking the exhaustiveness
of the switch. (For other violations, the pattern or where-clause is
ignored.)
https://bugs.swift.org/browse/SR-7409
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
- Must be a single pattern
- Must be last in the switch
- Must not have a 'where' clause
- Must specifically be the "any" pattern if using 'case'
We may lift some of these restrictions in the future, but that would
need a new proposal.
The other half of '@unknown' in Sema. Again, the diagnostics here
could be improved; rather than a generic "switch must be exhaustive",
it could say something about unknown case handling known cases.
One interesting detail here: '@unknown' is only supposed to match
/fully/ missing cases. If a case is /partly/ accounted for, not
handling the rest is still an error, even if an unknown case is
present.
This only works with switches over single enum values, not values that
contain an enum with unknown cases. That's coming in a later commit.
(It was easier to get this part working first.)
This is our first statement attribute, made more complicated by the
fact that a 'case'/'default' isn't really a normal statement. I've
chosen /not/ to implement a general statement attribute logic like we
have for types and decls at this time, but I did get the compiler
parsing arbitrary attributes before 'case' and 'default'. As a bonus,
we now treat all cases within functions as being switch-like rather
than enum-like, which is better for recovery when not in a switch.
1. Make sure the actions taken by fixits are reflected in diagnostics messages.
2. Issue missing cases diagnostics at the start of the switch statement instead of its end.
3. Use <#code#> instead of <#Code#> in the stub.
This lets you match `case .foo` when `foo` resolves to any static member, instead of only a `case`, albeit without the exhaustiveness checking and subpattern capabilities of proper cases. While we're here, adjust the type system we set up for unresolved patterns embedded in expressions so that we give better signal in the error messages too.
This reverts commit dc24c2bd34.
Turns out Chris fixed the build but when I was looking at the bots, his fix had
not been tested yet, so I thought the tree was still red and was trying to
revert to green.
Parser now accepts multiple patterns in switch cases that contain variables.
Every pattern must contain the same variable names, but can be in arbitrary
positions. New error for variable that doesn't exist in all patterns.
Sema now checks cases with multiple patterns that each occurence of a variable
name is bound to the same type. New error for unexpected types.
SILGen now shares basic blocks for switch cases that contain multiple
patterns. That BB takes incoming arguments from each applicable pattern match
emission with the specific var decls for the pattern that matched.
Added tests for all three of these, and some simple IDE completion
sanity tests.
This stops emitting unhelpful diagnostics about “<<error type>>” (as in
SR-176) while still complaining about the switch itself and any other
errors in case bodies.
Revert "Make function parameters and refutable patterns always
immutable"
This reverts commit 8f2fbdc93a.
Once we have finally merged master into the Swift 2.2 branch to be, we
should revert this commit to turn the errors back on for Swift 3.0.
All refutable patterns and function parameters marked with 'var'
is now an error.
- Using explicit 'let' keyword on function parameters causes a warning.
- Don't suggest making function parameters mutable
- Remove uses in the standard library
- Update tests
rdar://problem/23378003
Make the following illegal:
switch thing {
case .A(var x):
modify(x0
}
And provide a replacement 'var' -> 'let' fix-it.
rdar://problem/23172698
Swift SVN r32883
- Improve handling of if_expr in a couple of ways: teach constraint simplification
about IfThen/IfElse and teach CSDiags about the case when the cond expr doesn't match
BooleanType. This is rarely necessary, but CSDiags is all about cornercases, and this
does fix a problem in a testcase.
- Be a bit more specific about the constraint failure kind (e.g. say subtype) and when
we have a protocol conformance failure, emit a specific diagnostic about it, instead of
just saying that the types aren't convertible.
Swift SVN r30650
return statements, or a return statement with no operand.
Also, fix a special-case diagnostic about converting a return
expression to (1) only apply to converting the actual return
expression, not an arbitrary sub-expression, and (2) use the
actual operand and return types, not the drilled-down types
that caused the failure.
Swift SVN r30420
<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
- Situations where the type of a return statement's result expression doesn't line up with the function's type annotation.
- Situations where the type of an initializer expression doesn't line up with its declaration's type pattern.
- Situations where we assume a conversion to a built-in protocol must take place, such as in if-statement conditionals.
(Addresses rdar://problem/19224776, rdar://problem/19422107, rdar://problem/19422156, rdar://problem/19547806 and lots of other dupes.)
Swift SVN r24853
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
