In order to fit with the new IUO model where
functions with IUO results have the disjunction
formed when matching result types, we need to
update this logic to form applicable fn
constraints for the implicit `x[dynamicMember:]`
subscript call.
This is done using a new ImplicitDynamicMemberSubscript
locator path element to allow easy identification of
what the right callee and argument list should be.
A contextual purpose for a sequence expression associated with
`for-in` statement, that decays into a `ConformsTo` constraint
to a `Sequence` or `AsyncSequence` protocol.
Note that CTP_ForEachSequence is almost identical to CTP_ForEachStmt
but the meaning of latter is overloaded, so to avoid breaking solution
targets I have decided to add a new purpose for now.
If we encounter a placeholder type here, propagate
it to the type variable, as we don't know whether
it should be optional or non-optional, and we
would have already recorded a fix for it.
SR-15219
rdar://83352038
for unapplied references when the choice is a function declaration.
This will allow the solver to prune those overload choices when it
has already found a solultion with a property (all else equal in the
score). This is already done as an ambiguity tie-breaker in solution
ranking, but adding this bit to the score will prune a lot of search
space within the solver.
Warnings cannot lead to failures or ambiguity so let's remove
them from consideration when attempting to diagnose ambiguity
potentially caused by the same fix appearing in different
solutions.
Resolves: rdar://81228501
elements when the anchor is an unapplied decl reference in
simplifyLocator.
In this case, there's nothing to extract, so simply remove the path
element and continue on.
- Explicitly limit favoring logic to only handle
unary args, this seems to have always been the
case, but needs to be handled explicitly now that
argument lists aren't exprs
- Update the ConstraintLocator simplification to
handle argument lists
- Store a mapping of locators to argument lists
in the constraint system
- Abstract more logic into a getArgumentLocator
method which retrieves an argument-to-param locator
from an argument anchor expr
Just for convenicence.
* Replace `llvm::isa_and_nonnull` with imported `isa_and_nonnull`
* Repalce some `EXPR && isa<T>(EXPR)` with `isa_and_nonnull<T>(EXPR)`
* [ConstraintSystem] NFC: Rename `openOpaqueTypeRec` and make `openOpaqueType` private for individual types
* [ConstraintSystem] Require a contextual purpose for `openOpaqueType(Type, ...)`
Some of the contexts require special handling e.g. return type of a function
can only open directly declared opaque result type(s), this would be
implemented in a follow-up commit.
* [ConstraintSystem] Open only directly declared opaque types related to return statements
Re-establish a check which would only open opaque types directly
declared in the return type of a function/accessor declaration,
otherwise constraint system would end up with type variables it
has no context for if the type had generic parameters.
Resolves: rdar://81531010
wrapped parameters and wrapped properties.
This fixes a bug where @autoclosure was not propagated from the wrapper's
init(wrappedValue:) to a wrapped argument.
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
Remove the default argument for the `memberType`
parameter and enforce that GenericFunctionType is
not passed. Also add a defaulted overload for the
property case, as they should never have a
GenericFunctionType interface type.
If solutions either have no fixes at all or all of the are warnings,
let's use `diagnoseAmbiguity` to diagnose such cases as-if there are
no fixes at all.
Resolves: rdar://79657350
AutoClosureExprs created by the constraint system used to be constructed
with the decl context of the constraint system itself. This meant that
autoclosures in expressions nested in closures would initially be
parented onto any enclosing functions rather than the deepest closure
context. When we ran capture analysis and lookup from inside of the body
of these nascent values, we would fail to find declarations brought into
scope by those parent closures. This is especially relevant when
pre-typechecked code is involved since captures for those declarations
will be forced before their bodies have been recontextualized. See
issue #34230 for why we need to force things so early.
The attached test case demonstrates both bugs: The former a bogus lookup
through the parent context that would incorrectly reject this otherwise
well-formed code. The latter is a crash in SILGen when the capture
computation would fail to note $0.
Use the decl context of the solution application target, which is always
going to be the deepest user-written closure expression available to us,
and therefore the deepest scope that can introduce capturable variables.
rdar://79248469
This commit essentially consistes of the following steps:
- Add a new code completion key path component that represents the code completion token inside a key path. Previously, the key path would have an invalid component at the end if it contained a code completion token.
- When type checking the key path, model the code completion token’s result type by a new type variable that is unrelated to the previous components (because the code completion token might resolve to anything).
- Since the code completion token is now properly modelled in the constraint system, we can use the solver based code completion implementation and inspect any solution determined by the constraint solver. The base type for code completion is now the result type of the key path component that preceeds the code completion component.
This resolves bugs where code completion was not working correctly if the key path’s type had a generic base or result type. It’s also nice to have moved another completion type over to the solver-based implementation.
Resolves rdar://78779234 [SR-14685] and rdar://78779335 [SR-14703]
Currently ambiguity notes attached to a candidate only mention
expected type and its position. To improve clarify of such notes
it's useful to print argument type as well since it's not always
clear what it is at the first glance at the code.
Resolves: SR-14634
Resolves: rdar://78224323
Abstract away the TupleExpr gunk and expose
`getLHS` and `getRHS` accessors. This is in
preparation for completely expunging the use
of TupleExpr as an argument list.
