Update error messages to mention the invalid character.
Improve the diagnostic of floating point exponents.
Add tests for error messages when parsing floating point exponents.
Update existing tests for new error messages.
Rephrased error message to indicate which character is unexpected.
Provide error message variations when parsing binary, octal, decimal (default), and hexadecimal integer literals.
Look for unexpected digits in binary and octal integer literals.
Look for unexpected letters in hex integer literals.
Resolves: SR-5236 rdar://problem/32858684
We want the type of a KeyPathExpr to be the specific *KeyPath<T, U> subclass appropriate for the literal, with upcasts to a more general contextual type, since we rely on that invariant elsewhere to extract the base and projected value types. Fixes SR-5008 | rdar://problem/32395076.
Calls involving single trailing closure arguments require special
handling because we don't have as much contextual information
about function/argument types as in with regular calls, which means
that diagnosing such situations only by `visitApplyExpr`
yields subpar results.
Resolves: SR-4836.
Previously we would erroneously flag a `var` as not being mutated if the only mutations were through WritableKeyPaths. Fixes SR-5214 | rdar://problem/32599483.
Conditional and forced downcasts enter a constraint that almost
always succeeds; only when applying the solution do we evaluate
the feasability of the cast and determine if it always succeeds,
always fails, or conditionally succeeds. This changes how the
resulting AST is represented and can also emit diagnostics.
If the conditional cast is at this stage determined to always
succeed, we treat it as an unconditional cast, going through
ExprRewriter::coerceToType() to build the AST for the coercion.
However conditional cast constraints don't enter the same
restrictions into the solution as unconditional casts do, so
coerceToType() would fall over if casting a Swift type to a CF
type by first bridging the Swift type to Objective-C.
Get around this by checking for this case explicitly when
lowering a CoerceExpr.
It feels like there's a more fundamental issue here with how
casts are modeled in the constraint solver, but I'm not going
to try understanding that now.
Fixes <rdar://problem/32227571>.
Add an explicit argument label to the subscript declarations used in the
tests so that x[keyPath:] refers to the subscript rather than the
keypath.
Update test output accordingly.
When this score kind was added, the marker for the last score kind was
not updated. As a result, increasing the score for SK_KeyPathSubscript
was not actually having an effect.
Add tests that include a type with subscripts that also take the key
paths as their argument with an identical argument label ("keyPath").
These tests show that we're actually falling back on the keypath
application in many cases despite the score kind specific to keypath
application. I'll open a couple new JIRAs to investigate this
behavior.
The update to SK_LastScoreKind results in fixing a crash in these tests
that happens as a result of an assumption in CSRanking.cpp that if we're
comparing two solutions we end up with decls for overloads to compare,
which isn't the case here due to the keypath application.
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.
And make an attempt to use the constraint system's contextualType to bind type information; this makes things better but doesn't seem to be a complete solution for contextually typing key paths.
It's particularly likely someone will try to type `\(foo)`, which looks like a string interpolation segment, outside of a string literal, so give that case a special diagnostic. Fixes rdar://problem/32315365.
It looks like the compiler is having troubles with the pattern when the
non-mutaing operator is defined on the protocol, and delegates to the
mutating version, that is provided by the concrete type. Adding similar
definitions of non-mutating operators to concrete types significantly
speeds up the typechecking of complex expressions, like the one in
the ByteSwap benchmark.
This is a bit more robust and user-friendly than hoping more brittle recovery in SILGen or IRGen for unsupported components kicks in. rdar://problem/32200714
```swift
func foo(f: Void) -> ()) {}
```
This compiler currently suggests we change this to:
```swift
func foo(f: (Void) -> ()) {}
```
That's `(()) -> ()`, almost certainly not what someone wants in Swift
4. We should suggest changing that to:
```swift
func foo(f: () -> ()) {}
```
Additionally,
```swift
func foo(f: (Void) -> ()) {}
```
Should trigger a warning that the `(Void)` input type is `(())`, and you
can't supply `()` to it in Swift 4, and suggest a fix-it change it to:
```swift
func foo(f: () -> ()) {}
```
rdar://problem/32143617
We had an inconsistency in the handling of ConstraintKind::Equal in that
we would take
$T1 Equal $T2
where $T2 was previously bound to a type, and bind the RValue type of
$T2's type to $T1. That does not allow for us to later attempt to bind
the LValue type of that type to $T1 (as might happen in simplifying an
OptionalObject constraint).
Instead, if $T1 can be bound to an LValue and $T2 is not an LValue,
we'll defer simplifying the Equal constraint until after $T1 is bound
through some other type variable binding or constraint simplification.
Fixes rdar://problem/31724272.
The delcared type was incorrect here as opposed to the type checker
incorrectly diagnosing a problem. Fix the test and add another test
without a subscript operation to ensure that it works.
We can't reliably decide in the parser if a type was forgotten or a
wrong type was meant to be a type (e.g. `let x: class MyClass`).
This patch applies a heuristic that the parameter was most likely
forgotten if the next character is a closing bracket or a semantic
separator.
This catches the most common cases of function parameters and variable
declarations that are immediately initialised.
This fixes SR-4785.
This introduces a few unfortunate things because the syntax is awkward.
In particular, the period and following token in \.[a], \.? and \.! are
token sequences that don't appear anywhere else in Swift, and so need
special handling. This is somewhat compounded by \foo.bar.baz possibly
being \(foo).bar.baz or \(foo.bar).baz (parens around the type), and,
furthermore, needing to distinguish \Foo?.bar from \Foo.?bar.
rdar://problem/31724243
(in Swift 4 mode)
There are a lot of other things that overload ranking does *not* take
into account, and I intend to file a more general bug about that, but
this should resolve some of the most egregious ambiguities with Swift
3's import rules (SE-0005, particularly "omit needless words" and
adding default arguments).
Finishes rdar://problem/25607552.
We would misreport a cast from G<T> to G<Int> or vice versa
as always failing, because we were checking for an exact
subtype relationship instead of archetype binding.
Fixes <https://bugs.swift.org/browse/SR-3609>.
If the -enable-experimental-subclass-existentials staging flag
is on, resolveType() now allows protocol compositions to contain
class types. It also diagnoses if a composition has more than one
superclass requirement.
Also, change diagnostics that talked about 'protocol composition'
to 'protocol-constrained type'.
Since such types can now contain a superclass constraint, it's not
correct to call them protocol composition.
"Protocol-constrained type" isn't quite accurate either because
'Any' has no protocols, and 'AnyObject' will have no protocols but
a general class constraint; but those are edge cases which won't
come up in these diagnostics.
