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.
Original locator carries information about key and value types which
is necessary for diagnostics but cannot be retrieved in its original
state during solution application, so it could be dropped from Double<->CGFloat
constructor locator.
Unfortunately current approach of making a conversion independent of location
doesn't work when conversion is required for multiple arguments to the
same call because solver expects that either there are no Double<->CGFloat
conversions, or one of them has already been applied which is not the case.
The reason why locations weren't preserved in the first place is due to
how a solution is applied to AST - AST is mutated first and then, if there
are any conversions, they are applied to the already mutated version of
original AST. This creates a problem for Double<->CGFloat which depends
on an overload choice of injected call and it's impossible to find it based
on the mutated AST. But it turns out that this is only an issue in two
specific cases - conversions against contextual type and after optional injection.
This situations could be mitigated by dropping parts of the locator which are
unimportant for the Double<->CGFloat conversion - anchor in case of contextual
and `OptionalPayload` element(s) in case of optional injection.
Resolves: https://github.com/apple/swift/issues/59374
The deepest expression is the one that introduced the ambiguity into
the chain, so depth and index should be deciding factors and number of
overloads - a tie-breaker, while choosing what to diagnose.
Resolves: rdar://94360230
Previously for-in target was actually an expression target, which means
certain type-checking behavior. These changes make it a standalone target
with custom behavior which would allow solver to introduce implicit
`makeIterator` and `next` calls and move some logic from SILGen.
Fixes an oversight where `inout` -> C pointer conversion wasn't covered
by implementation of new pointer conversion semantics proposed by SE-0324.
Resolves: rdar://92583588
Accessing members on the protocol could result in existential opening and subsequence
result erasure, which requires explicit coercion if there is any loss of generic requirements.
A call to `.callAsFunction` could be injected after initializer if the type is
callable, `getCalleeLocator` should recognize that situation and return
appropriate locator otherwise if `callAsFunction` has e.g. a result builder
attached to one of its parameters the solver wouldn't be able to find it.
Resolves: rdar://92914226
The solver used to check availability attribute on the declaration
itself, a better approach is to go through `AvailableAttr::isUnavailable`
because that also covers unavailable extensions.
Resolves: rdar://92364955
The main function is different from other function resolutions. It isn't
being called from a synchronous or asynchronous context, but defines
whether the program starts in a synchronous or async context. As a
result, we should not prefer one over the other, so the scoring
mechanism shouldn't involve the async/sync score when resolving the main
function.
This patch adds a constraint solver flag to ignore async/sync context
mismatches so that we do not favor one over the other, but otherwise use
the normal resolution behavior.
