Update CSDiag.cpp to use the constraint system's type map instead of
directly reading types from expressions.
As with past commits, the type map is not really enabled yet since we
still write types directly into expressions in the constraint solver.
Covers some common situations when switching from literal types e.g.
string or int to more Swift Way of raw representable enum of choices.
Resolves: rdar://problem/32431165, rdar://problem/31977537, rdar://problem/32432253
If the contextual closure type expects no parameters but N
parameters where used and all of the them are anonymous, let's
suggest removing them.
Resolves: rdar://problem/32432145
Situations where there is a contextual RawRepresentable type is
used incorrectly would produce `<Type>(rawValue: )` fix-it only
in cases where neither or both sides of the expression are optional.
Let's fix that by adding a fix-it for optional to contextual raw
value type conversion.
Resolves: rdar://problem/32431736
This conversion just existed to aid migration from Identifier to
DeclBaseName and is no longer needed. It will technically not even be
correct once special names are introduced.
Push the getName method from ValueDecl down to only those types that are
guaranteed to have a name that is backed by an identifier and that will
not be special.
Adjust the definition of some diagnostics that are already called with
DeclBaseNames so that the implicit conversion from DeclBaseName to
Identifier is no longer needed.
Adjust the call side of diagnostics which don't have to deal with
special names to pass an Identifier to the diagnostic.
More updates to read and write types from a side table in the constraint
solver and only write back into expressions when we've finished type
checking an expression.
We still write directly into expressions, and will continue to do so
until all of the code has been updated.
Instead of validating sub-expressions included in the closure's result
`diagnoseAmbiguousMultiStatementClosure` was only checking parent expression
by mistake.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
The old TVO_MustBeMaterializable is now equivalent to
!TVO_CanBindToLValue && !TVO_CanBindToInOut.
I tried to update all usages of createTypeVariable() to
pass TVO_CanBindToInOut unless they explicitly passed
TVO_MustBeMaterializable before.
However, in reality TVO_CanBindToInOut is the rare case;
we can remove this flag gradually over time to fix
crashes and diagnostics.
Before trying to replace every other "," with ":" to help convert
from array to dictionary, let's first check if it's appropriate e.g.
the number of commas matches the number of elements and number of
elements in the array is even which constitutes key/value pairs.
Resolves: SR-4952.
If there are parameters missing in the closure declaration and
all of the present ones are anonymous let's emit a fix it suggesting
missing parameters.
Resolves: rdar://problem/32301091
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.
In `FailureDiagnosis::visitSubscriptExpr` if there is only a single
candidate available, verify that the problem is actually related
to the contextual mismatch by type-checking whole subscript without
contextual info, if that returns a type - it's contextual, otherwise
diagnose as incorrect argument type problem.
Resolves: rdar://problem/31977679
Properly diagnose cases of function/subscript argument tuple
structuring/destructuring related by not limited to SE-0110.
Resolves: rdar://problem/31973368
Add `FailureDiagnostics::visitKeyPathExpr` to try and diagnose contextual
value type problems related to Smart KeyPath feature. If problems with
contextual value type can't be diagnosed let's walk components and see
if there are any structural problems with expression itself e.g. unknown
members and incorrect types in the path.
Resolves: rdar://problem/32101765
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
```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
`FailureDiagnosis::visitUnresolvedMemberExpr` tries to use the same logic
as `diagnoseSingleCandidateFailures` so instead of doing that let's remove
some of the special handling and use `diagnoseSingleCandidateFailures`
directly instead, which improves label diagnostics and handles more erroneous
cases as well.
Resolves: rdar://problem/31898542
Swift 3 supported limited argument destructuring when it comes to
declaring (trailing) closures. Such behavior has been changed by
SE-0110. This patch aims to provide better error message as well
as fix-it (if structure of the expected and actual arguments matches)
to make the migration easier and disambiguate some of the common
mistakes.
Resolves: SR-4738, SR-4745, rdar://problem/31892961.
While diagnosing index expression associated with subscript call
`validateContextualType` didn't look through TupleType to identify
potential nullability of the contextual type related to generic
parameters.
Resolves: rdar://problem/31724211
Previously situations like `self.foo(...)` wouldn't be considered as viable
for diagnosing the instance method on type calls, because the base wasn't
TypeExpr, which only accounts for e.g. `X.foo`, instead of validating base
expression itself this patch checks if the _type_ of base expression is
Metatype which is less restrictive.
Resolves: SR-4692.
Any ambiguity inside of a call with a trailing closure
call was going down the code path that would tell you to
add an argument label... but the ambiguity might not be
with the call that has the trailing closure itself, and
instead something inside.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
Some APIs that expected a String now expect a Substring and vice
versa. To ease the transition, emit fix-its on conversion errors
between these types that the migrator can pick up.
When converting from Substring -> String, suggest wrapping in
`String.init`.
When converting from String -> Substring, suggest appending the
void subscript `[]`. (This isn't implemented yet so this is
hidden behind a flag).
This can possibly be generalized later when converting between
some sequence and its subsequence, such as Array and ArraySlice,
for example.
rdar://problem/31665649
rdar://problem/31666638
