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.
When diagnosing ApplyExpr, the existing implementation
tries to resolve the function subexpression independently
in the first place, without considering the argument
information. As a result, such resolved function type
may not produce the best diagnostic message.
This patch adds condideration of the number of arguments
to decide the better function subexpression for diagnostic
purpose.
Resolves: SR-7918, SR-7786, SR-7440, SR-7295, SR-5154.
The diagnostic when a user attempts to pass an argument requiring an implicit conversion (e.g. declared as a subclass, type conforming to protocol, etc.) to an inout parameter seems to be confusing for users—see e.g. SR-8155, SR-8148. This change replaces it with a more specific diagnostic which clearly suggests a solution. It also includes a fix-it suggesting the user change the type of the original variable if it’s a local with a simple type signature.
When there are multiple possible overloads for a call, the partially-
type-checked argument expression might end up with a LoadExpr outside
of the call ParenExpr instead of inside it. Account for this in a one-
off way for the 'rawValue' / 'init(rawValue:)' fix-its.
Yet more https://bugs.swift.org/browse/SR-8150
That is, if a type has a raw value of Int, and the function being
called has overloads for both Int and UInt, we always want to offer a
fix-it that leads to the 'Int' overload, not insert a conversion to
UInt that might be incorrect.
More https://bugs.swift.org/browse/SR-8150.
They were being put outside the call parentheses instead of inside.
We even had tests for this; I just got them wrong.
https://bugs.swift.org/browse/SR-8150
A type checker instance isn’t needed for most of the “override” checking,
so remove the TypeChecker parameters and instead get the ASTContext or
DiagnosticEngine from whatever decl or type is available. Another step
toward reducing dependency on a TypeChecker instance.
• Change name to match names of member diagnostics.
• Explicitly call out that this is a "value of type". This matches the error from non-existent methods and properties.
• Don't call them "subscript members". That term is never used in documentation and "member" doesn't add anything besides confusion.
