While trying to diagnose problems related to keypath components
don't assume that type of the component is always correct, check
before trying to see if it's bridged type or has members.
Resolves: rdar://problem/33135487
Change the fix-it to move the argument to its correct location in one go. This happens by removing it from one location and inserting it in the other (as opposed to the original implementation which swapped one argument with the preceding one). The commas separating the arguments are adjusted to match the moved argument.
Add new tests for reordering regular arguments, variadic arguments, and function arguments.
Resolves: SR-4715 rdar://problem/31849281
Fixes crasher in diagnostics related to the fact that contextual type
is not always available when trying to diagnose problems related to
calls with trailing closures.
Resolves: rdar://problem/33067102
Relax restriction placed on the function shadowing diagnostics
and allow such diagnostics to be emitted even when argument types
do not match expected parameter types, but use "near match" message
in that case to clarify that shadowing is not exact.
Resolves: rdar://problem/32854314
When trying to diagnose problems related to calls where
function is represented by a member of nominal type let's
attempt to be more cautious while type-checking function
expression without it's arguments, because it could produce
unrelated diagnostics.
Resolves: rdar://problem/32551313, rdar://problem/28456467, rdar://problem/31671195
Currently some contextual errors are discovered too late
which leads to diagnostics of unrelated problems like argument
mismatches, these changes attempt to improve the situation
and try to diagnose contextual errors related to calls
before everything else.
Resolves: SR-5045, rdar://problem/32934129
This makes it a lot easier to diagnose contextual mismatch related
to arguments used by the call without relying on the type of the
function expression which is not always available.
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.
AnyFunctionType::Param carries around information about decomposed
parameters now. Information about default arguments must be computed
separately with swift::computeDefaultMap.
Saying "implicitly non-escaping because it was declared @autoclosure"
does not make sense. Since Swift 3, parameters of function type are
non-escaping by default, whether or not they are @autoclosure.
We would also inhibit the fixit for inserting @escaping if the
@autoclosure attribute was present. Again, a holdover from the
Swift 2 days, when @autoclosure implied @noescape and the special
@autoclosure(escaping) attribute was used to define an escaping
autoclosure.
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.
* The SILBuilder could potentially reference itself during its own
initialization if a valid insertion point was left around and a
new basic block was created. Move basic block creation after the
initializer instead.
* CSDiag was comparing canonical types for equality directly, which
leads to mixed-type comparisons if one side of the comparison is nullptr.
Use isEqual instead.
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.
