if the expression is an argument to `#selector`.
For `#selector` arguments, functions and properties are syntactically distinct
with the getter/setter label, so the solver should not unconditionally prefer
properties to unapplied functions. A better fix for this is to port over the
`#selector` diagnostics from CSApply, and not attempt invalid disjunction choices
based on the selector kind on the valid code path.
Previously we were introducing a type variable
to mark a constructor's parameter list as
`TVO_PrefersSubtypeBinding`. Unfortunately this
relies on representing the parameter list as a
tuple, which will no longer be properly supported
once param flags are removed from tuple types.
Move the logic into CSRanking such that we pick up
and compare the parameter lists when comparing
overload bindings. For now, this still relies on
comparing the parameter lists as tuples, as there's
some subtle tuple subtyping rules that could
potentially affect source compatibility here, but
at least we can explicitly strip the parameter
flags and localise the hack to CSRanking rather
than exposing it as a constraint.
Use this new element to represent the overload type
for a constructor call, and have it store a bit
indicating whether the call is for a short-form
`X(...)` or self-delegating `self.init(...)` call.
Tuple splat/implosion is (still) allowed for patterns (with a warning in Swift 5)
so we need to use `SingleApply` while looking up members to make sure that e.g.
`case test(x: Int, y: Int)` gets the labels preserved when matched with
`case let .test(tuple)` and `Compound` when associated values form a tuple pattern.
- Make sure that `varType` is wrapped into an optional type for `weak`
declarations.
- Verify that `externalPatternType` is an optional type when one-way
constraints are requested.
parameter attributes for closure parameters.
For regular function parameters, these constraints will have already been
generated and solved when computing the backing property wrapper type at
the function declaration. If the solver also generates these constraints
when type checking a function call, it leads to misleading diagnostics
about an argument mismatch that will appear at the function declaration
instead of the call-site.
Instead of passing pattern directly, let's fetch it from the pattern
binding and remove extra argument from `SolutionApplicationTarget::forUninitializedVar`.
- 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
It's possible for `TypeChecker::typeCheckPattern` to produce
either no type or type containing error. That should be detected
early and immediately fail constraint generation.
We used to represent the interface type of variadic parameters directly
with ArraySliceType. This was awfully convenient for the constraint
solver since it could just canonicalize and open [T] to Array<$T>
wherever it saw a variadic parameter. However, this both destroys the
sugaring of T... and locks the representation to Array<T>. In the
interest of generalizing this in the future, introduce
VariadicSequenceType. For now, it canonicalizes to Array<T> just like
the old representation. But, as you can guess, this is a new staging
point for teaching the solver how to munge variadic generic type bindings.
rdar://81628287
* [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
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
Upon encountering an ErrorExpr, we were previously
bailing from the walk. However, for multi-statement
closures, that could result in us missing some
variable references required to connect to the
closure to its enclosing context. Make sure to
continue walking to catch those cases.
SR-14709
rdar://78781677
Typed patterns are represented by a name and a fixed contextual
type, let's not use intermediary type variable and one-way constraint
as its type because that variable would be bound right away to
contextual type. Also setting type of a variable declaration
to a type variable when contextual type is IUO doesn't play well
with overload resolution because it expects an optional type for
declarations with IUO attribute.
Resolves: rdar://80271666
If we are completing e.g. `\.self.#^COMPLETE^#` we use the type of `self` as the base type for the completion. In order to retrieve that, we need to record the type.
Fixes rdar://80271346 [SR-14887]
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]
Having purpose attached to the contextual type element makes it much
easier to diagnose contextual mismatches without involving constraint
system state.
