This meant we weren't producing sema diagnostics for the case, and it didn’t
get full syntactic/semantic highlighting or indentation.
enum CasesWithMissingElement {
case a(Int, String),
case b(Int, String),
}
Resolves rdar://problem/61476844
We used to take all the captures of a local function and treat them all
as read and write usages of vars from an outer scope. Instead, let's
refactor the analysis to walk into local functions.
We had a similar check in TypeCheckStmt but it did not account for the
possibility of the 'throw' being contained inside a 'do'/'catch' inside
a 'defer'. Remove it and just diagnose everything in one place.
Fixes <rdar://problem/57360567>.
Improve diagnostics for labeled block without 'do'.
Parse and diagnose { identifier ':' '{' } as a labeled 'do' statement.
https://bugs.swift.org/browse/SR-3867
Instead of recording `TreatRValueAsLValue` fix directly inside
`matchTypes`, let's move towards recording it specifically for
each possible case in `repairFailures` which makes it a lot
easier to determine what other fixes could be applied (if any).
* Fixes SR-11261
* Improving diagnostics for multi-case declaration that uses a keyword
* Only doing pattern matching if token is not a keywork or if is a possible identifier
* Using BacktrackingScope to fix expected pattern
* Updating NameLoc with the token consumed.
* Updating Name with the consumed token
Instead, check them and their error handling right away.
In addition to fixing the crash in the radar, this also causes
us to emit unused variable warnings in functions containing
local functions.
Eventually, TC.definedFunctions should go away altogether.
Fixes <rdar://problem/53956342>.
Adds proper diagnostics when using unresolved labels on break statements inside loops. In case of simple typos, also provides suggestions and fixits. Right now, the misleading "error: 'break' is only allowed inside a loop, if, do, or switch" is emitted in 4.2 and master.
Resolves SR-9677.
- moving WARNING definition from DiagnosticsCommon.def to DiagnosticsSema.def
- improving WARNING message to better align with guidelines described in docs/Diagnostics.md as suggested by @xwu.
- adapting expected warning message in tests.
When checking for uses of "disabled" variables within the "else"
statement of a "guard", keep track of the disabled variables from
outer scopes. This is a pattern used everywhere else in the parser,
but got missed here. Fixes SR-7567 / rdar://problem/39868144.
* [Diagnostics] SR-7445 Improve diagnostics for assignment failures
* modified messages for assignments to function calls,
modified messages for assignments to methods.
removed comment for resolved radar.
* removed extra line and braces
* added tests for assignment_lhs_is_apply_expression
eliminated redundant literal check which is always invoked before call
reverted 'cannot assign to value' for literal assignments in subexpressions
* Complemented assigning to literal tests & reverted to 'cannot asign to value' for methods (was 'cannot assign to member')
* removed extra tabs
* eliminated one more accidental spacing
* Update CSDiag.cpp
* added highlighting, fixed & rechecked tests
* added highlighting for complex expressions involving assigning to literals
Resolves: [SR-7445](https://bugs.swift.org/browse/SR-7445)
Record the initializer type as soon as we have a solution, before
it is applied, and get the type from the constriant system instead
of from the final type checked expression.
Note that the coerceToMaterializable() was unnecessary, since we
always coerce the value to an rvalue type with coerceToType().
Eventually coerceToMaterializable() should go away.
This is mostly NFC, except using the result of simplifyType() rather
than the type of the final expression changes some diagnostics where it
appears we were previously losing sugar.
Also this accidentally fixes a crasher. Unfortunately the underlying
issue is still there (applying a solution has bugs with opened
existentials "leaking" out) -- this merely masks the problem by
getting the initializer type directly from the constriant system.
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 used to cause SILGen to capture and subsequently load `self` as a
constant. Then, when the super call was SILGen’d, it assumed that
`self` would be loaded Boxed. Diagnose before hitting SILGen so we
don’t have to pollute Lowering with code that handles `self` in this
odd position.
String literal expressions, as well as the magic literals #file and
tuple value that is then fed into one or two call expressions. For
string literals, that tuple value was implicitly splatted, breaking
AST invariants.
Instead, keep string literals and these magic literals that produce a
string as a single expression node, but store the declarations that
will be used to transform the raw literal into the complete
literal. SILGen will form the appropriate calls. This representation
is far simpler---the AST no longer has a bunch of implicit nodes---and
doesn't break AST invariants.
- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
- “protocol<>” is now “swift.Any”
- “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ 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.
along with recent policy changes:
- For expression types that are not specifically handled, make sure to
produce a general "unused value" warning, catching a bunch of unused
values in the testsuite.
- For unused operator results, diagnose them as uses of the operator
instead of "calls".
- For calls, mutter the type of the result for greater specificity.
- For initializers, mutter the type of the initialized value.
- Look through OpenExistentialExpr's so we can handle protocol member
references propertly.
- Look through several other expressions so we handle @discardableResult
better.
It is a common point of confusion that code like:
switch value {
case .Foo, .Bar where someNumber != 100:
Only applies the where clause to the second pattern, not every pattern in the case.
Resolve this by warning about the ambiguity, providing two notes (with fixits) that
resolve the issue in different ways:
t.swift:25:17: warning: 'where' only applies to the second pattern match in this case
case .Foo, .Bar where someNumber != 100:
~~~~ ^ ~~~~~~~~~~~~~~~~~
t.swift:25:12: note: disambiguate by adding a line break between them if this is desired
case .Foo, .Bar where someNumber != 100:
^
t.swift:25:6: note: duplicate the 'where' on both patterns to check both patterns
case .Foo, .Bar where someNumber != 100:
^~~~
where someNumber != 100
