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
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
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.
After we call into typeCheckExpression() we need to cache the
resulting types in the constraint system type map because we later
call into code that reads the types out of the type map.
Fixes rdar://problem/30376186 as well as a couple crashers.
