Pass constraint system down into offering force unwrap fixits so that we can identify the type of the last member chosen for an optional chain. If there's a chain and the last member's return type isn't optional, then it's cleaner to offer to change that last '?' into a '!' to perform the force, rather than parenthesize the whole expression and force the result.
This is a legacy holdover from when tuple types had default
arguments, and also the constraint solver's matching of function
types pre-SE-0110.
Well, move the last live usage to CSDiag, where it can die a slow
painful death over time. The other usages were not doing anything.
Unresolved member calls e.g. `.foo(1, 2)` are unique in a way that
they don't form regular application expressions. So let's teach
`simplifyLocator` how to extract arguments from such calls
based on locators like:
`[UnresolvedMemberExpr -> apply argument -> comparing call argument # to parameter #]`.
This helps to diagnose more failures via diagnostics attached to
constraint system fixes.
This either became dead shortly after the removal of Swift 3
compatibility mode from the constraint solver, or even earlier.
Note that the code completion test change is actually correct
because (Any) -> () is not convertible to () -> () in the
language.
When trying to salvage a failed expression type-check fails, diagnose
"expression too complex" before the general and uninformative "type of
expression is ambiguous without more context".
While inferring avoid associating type variables with closure
parameters, use cache instead and only set types when everything
is properly type-checked, this avoids multiple problems one of
them - leaking type variables outside of constraint system they
belong to.
so that they must result in an optional type.
Add constraint locator path for identifying constraints/variables that are part of the convert type passed into the system.
Most of the use-cases of `gatherConstraints` require filtering
at least based on the constraint kind that caller is interested in,
so instead of returning unrelated results and asking caller to
filter separately, let's add that functionality directly to
`gatherConstraints`.
Since it's possible to find the same constraint through two different
but equivalent type variables, let's use a set to store constraints
instead of a vector to avoid processing the same constraint multiple
times.
This gets adjustAccessLevelForProtocolExtension, a hack of sorts to
begin with, out of ValueDecl's general API, and down to a helper for
isAccessibleFrom and isSetterAccessibleFrom. (The only reason these
two don't go through access scopes is as an optimization.)
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
* Improve label mismatch callback:
- Split "missing label" callback into 3 - missing, extraneous, incorrect (with typo(s));
- Allow label callbacks to indicate if it's a fatal error or not;
* Improve matching of the variadic parameters;
* Improve matching of the parameters with defaults;
* Try to look for an argument with matching label before fallback to
forced claming (if allowed).
Implementation is as follows: In `preCheckExpression` try to
detect if there is `T(literal)` call in the AST, replace it with
implicit `literal as T`, while trying to form type-checked AST,
after constraint solving, restore source information and drop
unnecessary coercion expression.
Resolves: rdar://problem/17088188
Resolves: rdar://problem/39120081
Resolves: rdar://problem/23672697
Resolves: rdar://problem/40379985
Replace the last (and most obscure) use of the poor “use ‘?’ or ‘!’” diagnostic with the
new, more explanatory version that provides separate notes with Fix-Its for coalescing or
force-unwrapping the value.
Finishes rdar://problem/42081852.
While trying to diagnose the problem with previously type-checked
sub-expression, use its type-checked variant as a source of type
information, instead of transferring from its original constraint system,
because if expression was type-checked successfully it would
have all of the required information in AST, and that doesn't
rely on associated constraint system being present.
Resolves: rdar://problem/42056741
Introduce a new fix kind into the constraint solver to cover unwrapping the base
of a member access so we can refer to the a member of the unwrapped base.
Wire this fix kind to the just-added diagnostic that suggests either the
chaining ‘?’ or the force-unwrap ‘!’ via separate, descriptive Fix-Its.
Example:
error: value of optional type 'X?' must be unwrapped to refer to member 'f' of wrapped base type 'X'
let _: Int = x.f()
^
note: chain the optional using '?' to access member 'f' only for non-'nil' base values
let _: Int = x.f()
^
?
note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
let _: Int = x.f()
^
!
Before this, we would sometimes get a Fix-It for just ‘?’ and sometimes get a Fix-It for the
coalescing ‘??’, neither of which is likely to be right.
More work on rdar://problem/42081852.
Improve diagnostics when referencing a member of an optional base, where the
Optional type does not have the member but the wrapped type does. Specifically,
suggest both the chaining ‘?’ and the force-unwrapping ‘!’ Fix-Its via explanatory
notes, e.g.:
error: value of optional type '[Int]?' must be unwrapped to refer to member 'subscript' of wrapped base type '[Int]'
return foo.array[0]
^
note: chain the optional using '?' to access member 'subscript' only for non-'nil' base values
return foo.array[0]
^
?
note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
return foo.array[0]
^
!
More of rdar://problem/42081852.
Since verifier is now in place to make sure that ParenExpr/ForceValueExpr
always preceed LoadExpr there is need to special case against incorrect
ordering in diagnostics.
