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.
Rather than only setting the isolated-by-preconcurrency bit during
constraint application, track the closures it will be set for as part
of the constraint system and solution. Then, use that bit when
performing "strict concurrency context" checks and type adjustments,
so we don't treat an inferred-to-by-`@Sendable`-by-preconcurrency
closure in the solver as if it weren't related to preconcurrency.
Fixes the spurious warning from
https://github.com/apple/swift/issues/59910.
Rather than re-using `DiagnosticBehavior` to describe how a fix should
act, introduce `FixBehavior` to cover the differences between (e.g.)
always-as-awarning and downgrade-to-warning. While here, split the
`isWarning` predicate into two different predicates:
* `canApplySolution`: Whether we can still apply a solution when it
contains this particular fix.
* `affectsSolutionScore`: Whether
These two predicates are currently tied together, because that's the
existing behavior, but we don't necessarily want them to stay that way.
Pavel Yaskevich
Kavon Farvardin
Luciano Almeida
Slava Pestov
Amritpan Kaur
Pavel Yaskevich
Hamish Knight
Jonathan Penn
Alex Hoppen
Anthony Latsis
Doug Gregor