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.
Emit a warning for optionals that are implicitly converted to Any, and
add fixits giving options to:
- Add '??' with a default value after
- Force-unwrap the optional with '!'
- Explicitly cast to 'as Any' to silence the warning
This covers diagnostics aspect of SE-0140.
rdar://problem/28196843
From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
almost always the case that the user didn't know what the rules are between
single expression and multistatement closures, and they often don't know how to
fix the problem.
Address this by doing some heroics when we detect this situation. We now go dive
into the closure body, type check the explicit returns within it, and can usually
divine the right answer. When we do that, generate a fixit hint that generates a
modification to the existing signature, or synthesizes the entire signature from
scratch. This addresses:
<rdar://problem/22123191> QoI: multi-line closure with failure to infer result type should add a fixit
Previously:
error: generic parameter 'T' could not be inferred
now:
error: unable to infer closure return type in current context
There is still more to do, but this fixes:
<rdar://problem/23570873> QoI: Poor error calling map without being able to infer "U" (closure result inference)
TypeCheckPattern was able to take the path checking if `Optional.None`
should be renamed to lowercase `Optional.none` and if this wasn't
necessary still failed but without generating a diagnostic.
Now it always provides a diagnostic when failing.
This fixes SR-2057.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
This reverts commit 073f427942,
i.e. it reapplies 35ba809fd0 with a
test fix to expect an extra note in one place.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
Producing single argument mismatches involving generics causes some
gross looking error messages if the generic mismatches get put into the
same closeness bucket as non-generic mismatches.
E.g. `var v71 = true + 1.0` used to produce `error: cannot convert
value of type 'Bool' to expected argument type 'Double’`, but would now
end up with `binary operator '+' cannot be applied to operands of type
'Bool' and 'Double’` `overloads for '+' exist with these partially
matching parameter lists: (Double, Double), (T, T.Stride), (T.Stride,
T)`.
Resolve this by adding CC_OneGenericArgumentNearMismatch and
CC_OneGenericArgumentMismatch, that are similar but ever so slightly
not as close as a mismatch involving non-generic functions. This gets
back the original error message in cases like the above, because there
is only one declaration of `+` which partially matches and is
non-generic, and the generic partial matches are now farther away.
But now single arg mismatches and nearness work for single-archetype
generic functions, as in the additions to the SR-69 test at the end of
deduction.swift.
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
Rearrange diagnoseGeneralConversionFailure to diagnose structural problems
even if we have some UnresolvedTypes floating around, then reject constraint
failures with UnresolvedTypes in them even harder. This keeps us giving
good errors about failures where we have a structural problem (with buried
irrelevant details) while not complaining about cases that are actually
ambiguous.
The end result of this is that we produce a lot better error messages in the
case of failed archetype inference. This also highlights the poor job we do
handling multi-stmt closureexprs...
This time, the issue is that TypeNullifier skips bodies of
multi-statement closures. However, ExprRewriter will type
happily pass them on to typeCheckClosureBody(). This could
trigger assertions. Fix this by skipping type checking of
multi-statement closures when diagnosing.
There seems to be a minor QoI regression in some test cases
that already looked pretty dodgy and/or had FIXMEs. However
I think its worth fixing a crash.
We weren't actually successfully mutating ParentType,
so fix that, and also ensure we set ParentType together
with the rest of the state.
Discovered while writing resilient enum tests.
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
Make the following patterns illegal:
if var x = ... {
...
}
guard var x = ... else {
...
}
while var x = ... {
...
}
And provide a replacement fixit 'var' -> 'let'.
rdar://problem/23172698
Swift SVN r32855
Don't allow a pattern like:
for var x in sequence {
...
}
and provide a removal fix-it for the 'var' keyword.
Additionally, for the following code:
for let x in sequence {
...
}
Provide a removal fix-it since the 'let' specifier is now
redundant.
rdar://problem/23172698
Swift SVN r32818
When diagnosing failure to typecheck a binary '~=' expression that was
synthesized when typechecking an expression pattern, offer a message
that describes the failure more helpfully.
<rdar://problem/21995744> QoI: Binary operator '~=' cannot be applied to operands of type 'String' and 'String?'
Swift SVN r31286
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
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
- 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
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
It doesn't make sense to try to limit them in most cases, because there may be protocol conformances we don't know about statically in the dynamic program. Relax casts that always succeed or fail to be a warning instead of an error.
Swift SVN r23298
