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.
- 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)`
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
- Increase impact of a generic pointer-to-pointer mismatch fix to
match that of a contextual type failure. This allows more specific
fixes to take precedence.
- De-prioritize generic argument mismatch fix when both types are
pointers. This allows pointer-to-pointer conversion produce a
more specific fix.
- De-prioritize fixes that involve `Builtin.RawPointer` or `OpaquePointer`
in parameter positions. This helps to produce better diagnostics
for argument mismatches during pointer initialization e.g.
`UnsafeRawPointer(<pointer>)`.
Instead of infer all of the flags only for anonymous parameters,
let's infer inout/variadic for all type-less parameters - anonymous
and named. This allows to correctly form internal parameter type and
reduce amount of inference in the body (e.g. `BindParam` could be
simplified inline).
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
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
Many clients of the conformance lookup operations would prefer to get
an invalid conformance (== there is no conformance) rather than a
missing conformance. Parameterize the conformance lookup operations so
that most callers won't see missing conformances, by filtering them
out at the end. Opt-in those callers that do want to see missing
conformances so they can be diagnosed.
Unfulfilled params get arguments synthesized for them which are added
to the end of the argument list. Later logic to detect out-of-order
arguments and produce relabelling fixes didn't account for them though.
This improves several diagnostics for mislabelled call arguments in the
existing tests.
implicit conversions if the type does not conform and the current score
is equal to the best score.
Implicit conversions will always increase the score, so if the current
score is equal to the best score and an implicit conversion is needed to
satisfy a conformance requirement, the solver would end up pruning that
path later on anyway. It's better to fail early.
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.
If one of the sides in a application result conversion is a hole
it could only mean that the fix has been recorded earlier (at the
point where hole was introduced) and failure at function result
position could be safely ignored.
Resolves: rdar://79757320
If lookup failed to find a member for a pattern match, let's bind
type variable representing such member to a hole right away, otherwise
there is a risk of missing other potential hole locations in pattern
function type (arguments + result type) because pattern matching
doesn't use 'applicable function' constraint.
Resolves: rdar://65667992
Treat actors as being semantically `final` throughout the type checker.
This allows, for example, a non-`required` initializer to satisfy a
protocol requirement.
We're leaving the ABI open for actor inheritance should we need it.
Addresses rdar://78269551.
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]
Let's look through all optionals associated with contextual
type to make it possible to infer parameter/result type of
the closure faster e.g.:
```swift
func test(_: ((Int) -> Void)?) {
...
}
test { $0 + ... }
```
In this case dropping optionality from contextual type
`((Int) -> Void)?` allows `resolveClosure` to infer type
of `$0` directly (via `getContextualParamAt`) instead of
having to use type variable inference mechanism.
