By default avoid imploding params that have parameter
flags, but carve out exceptions for ownership flags,
which can be thunked, and `@_nonEphemeral` which can
be freely dropped without issue.
Remove the canonicalVararg parameter and
CanParamArrayRef wrapper. Almost none of the
callers want canonicalVararg, and the one that
does calls `getCanonicalType` on the result
anyway.
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
