Instead of checking for unavailability attributes directly in the solver, use `AvailableAttr::isUnavailable` which checks the enclosing extension too, if necessary.
Resolves rdar://92364955
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
We intended to introduce AST conversions that strip concurrency
attributes off of types associated with `@preconcurrency` decls.
But for VarDecl references, we stripped it too early, leading to
things like a MemberVarDecl that doesn't have `@Sendable` in its
result type, but the VarDecl it refers to does have it.
That caused crashes in SIL where types didn't match up. This patch
fixes things by delaying the stripping until the right point.
resolves rdar://98018067
Implicit conversion used to erase path for contextual type conversions
but it does so no longer, this means that invalid partial application
check needs to know about existence of implicit conversions that are
not reflected in the AST until solution is applied.
Resolves: rdar://99282932
Previously locator for value-to-value conversion would just drop
all the contextual information if the conversion occurred while
converting expression to a contextual type. This is incorrect for
i.e. `return` statements and other targets because because they
are solved separately and using the same locator would result in
a clash when solutions are merged.
An extraneous argument doesn't have a corresponding parameter so the
information object for such an argument is not safe to produce.
Resolves: https://github.com/apple/swift/issues/60436
Resolves: rdar://98304482
We had two notions of canonical types, one is the structural property
where it doesn't contain sugared types, the other one where it does
not contain reducible type parameters with respect to a generic
signature.
Rename the second one to a 'reduced type'.
The outermost wrapper is the one at index `0` in the wrapper list
but it's easy for humans to make a reverse assumption since outermost
is the back of the list. Let's add a dedicated method to reduce error
probability of the property wrapper APIs.
If the type for such declaration could be completely inferred it
would be used during solution application. This is used to infer
types for result builder components.
Previously we relied on `TupleTypeElt::getType`
returning an `InOutType` to fail the tuple type
matching logic. Instead, add logic to reject any
inout arguments up-front with a more specific
diagnostic.
Also, while we're here, strip the `_const`
parameter flag, as it's not something that needs
to be considered for tuple construction.
Remove a redundant bit of diagnostic logic now
that we better diagnose cases where an uncallable
variable is in an overload set for a mismatched
apply. Tweak another bit of diagnostic logic to
only apply to a single arg/param case, as that
seems to be what it's meant for.
In ambiguity scenarios solutions are not applied back to the constraint
system, so it might not always have contextual type information when it
was recorded e.g. for a multi-statement closure.
Resolves: rdar://97396399
This was already enabled as part of `-enable-implicit-dynamic` but this
new flag allows turning on opaque type erasure all by itself whether or
not `dynamic` is added explicitly.
rdar://97375478
Drop `TupleType` element which is only used for diagnostics and
cannot be re-created by `ExprRewriter` during solution application.
Resolves: rdar://97389698
When computing type relations of code completion items with respect to the context they are used in, we add a `ConstraintKind::Conversion` constraint with an empty constraint locator. This currently crashes in `hasPreconcurrencyCallee`, but actually having a null anchor doesn’t produce any issues.
When `&` is misplaced it creates r-value -> l-value mismatch
in the code which is just a consequence and shouldn't be diagnosed.
Resolves: rdar://96631324
To make this test work, fix an issue in `ConstraintSystem::salvage` where a
threshold breach during solving went unnoticed due to exiting on ambiguity
before reaching the `isTooComplex` check. Address this by moving the
`isTooComplex` check to before we start processing solutions, and stick another
one in `findBestSolution` for short-circuiting while we're here.
