If the argument type is an array and it's passed to an imported declaration
that accepts a raw pointer, the solver should use an "array-to-c-pointer"
conversion instead of the one for pointers.
Resolves: rdar://158629300
(cherry picked from commit 29b04f4a63)
Follow-up for https://github.com/swiftlang/swift/pull/82326.
The optional injection is only viable is the wrapped type is
not yet resolved, otherwise it's safe to wrap the optional.
(cherry picked from commit 4804f2131b)
We need to be very careful while matching types to test whether a
fix is applicable or not to avoid adding extraneous fixes and failing
the path early. This is a temporary workaround, the real fix would
be to let `matchTypes` to propagate `TMF_ApplyingFixes` down.
Resolves: rdar://154010220
Resolves: https://github.com/swiftlang/swift/issues/82397
(cherry picked from commit 7ecb1fd1db)
If we have a tuple with unresolved pack expansion on one side
and an optional type on the other, prevent `matchTypes` from
wrapping optional into a one-element tuple because the matching
should be handled as part of the optional injection.
Resolves: rdar://152940244
(cherry picked from commit 6cfbafd968)
Escaping solver-allocated types into a nested allocation arena is
problematic since we can e.g lazily compute the `ContextSubMap` for a
`NominalOrBoundGenericNominalType`, which is then destroyed when we
exit the nested arena. Ensure we don't pass any types with type
variables or placeholders to `typesSatisfyConstraint`.
rdar://152763265
Fixes a crash on invalid. The previous logic was causing a label
mismatch constraint fix to be recorded for an unlabeled trailing closure
argument matching a variadic paramater after a late recovery argument
claim in `matchCallArgumentsImpl`, because the recovery claiming skips
arguments matching defaulted parameters, but not variadic ones. We may
want to reconsider that last part, but currently it regresses the
quality of some diagnostics, and this is a targeted fix.
The previous behavior is fine because the diagnosis routine associate
with the constraint fix (`diagnoseArgumentLabelError`) skips unlabeled
trailing closures when tallying labeling issues — *unless* there are no
other issues and the tally is zero, which we assert it is not.
Fixes rdar://152313388.
(cherry picked from commit f2e1420a90)
- Mismatch in tuple element position should reference whole tuple
with a note for mismatch position;
- Situations where optional object type is not a class but matched
against `AnyObject` have a tailored fix.
(cherry picked from commit 7305275dbd)
Attempting to propagate generic argument failures up is not always
reliable, `matchDeepEqualityTypes` should avoid using `TMF_ApplyingFix`
while dealing with optionals and instead let `repairFailures` decide
whether to use generic arguments mismatch fix to a more general one.
(cherry picked from commit 27c28d4d64)
If generic arguments mismatch ends up being recorded on the result
of the chain or `try` expression it means that there is a contextual
conversion mismatch.
For optional conversions the solver currently generates a disjunction
with two choices - bind and optional-to-optional conversion which is
anchored on the contextual expression. If we can get a fix recorded
there that would result in a better diagnostic. It's only possible
for optional-to-optional choice because it doesn't bind the
variable immediately, so we need to downgrade direct fixes to prevent
`bind` choice from considered better.
(cherry picked from commit 65e83a8bb1)
Since we have `repairViaOptionalUnwrap`, let's use that to fix
argument/parameter mismatches instead of doing ad-hoc matching.
(cherry picked from commit b12d844fcc)
The problem detection logic currently expects `generic argument #<N>`
location to always be associated with two generic types, but that
is not always the case, this locator element is sometimes used for
i.e. optional object types and pointer `Pointee` type when types
appear in argument positions. This needs to be handled specifically.
Resolves: rdar://82971941
(cherry picked from commit ded6158cc3)
Without contextual information it won't be possible to bind a missing
member to a concrete type later, so let's bind them eagerly and propagate
placeholders outward.
Resolves: rdar://152021264
Resolves: https://github.com/swiftlang/swift/issues/81770
(cherry picked from commit 10186d664b)
If key or value of a literal collection expression doesn't conform
to protocol(s) expected by the contextual existential type, let's
diagnose that via a tailed collection mismatch fix instead of a
generic conformance one.
Resolves: rdar://103045274
(cherry picked from commit d83ec7b3a5)
`@autoclosure` is associated with a parameter, we use argument mismatch fix
to diagnose missing explicit calls as well as any mismatches in that position.
Resolves: rdar://110527062
(cherry picked from commit b3e9cf3424)
If the argument has an extra `?` or `!`, let's not attempt to force
optional (because it's use is already invalid) and re-introduce
the constraint with unwrapped type instead. This would help to diagnose
the invalid chaining as well as any argument to parameter mismatches.
Resolves: rdar://126080504
(cherry picked from commit ef2fa4a1b6)
When a generic function has potentially Escapable outputs, those outputs
declare lifetime dependencies, which have no effect when substitution
leads to those types becoming `Escapable` in a concrete context.
This means that type substitution should canonically eliminate lifetime
dependencies targeting Escapable parameters or returns, and that
type checking should allow a function value with potentially-Escapable
lifetime dependencies to bind to a function type without those dependencies
when the target of the dependencies is Escapable.
Fixes rdar://147533059.
An "abstract" ProtocolConformanceRef is a conformance of a type
parameter or archetype to a given protocol. Previously, we would only
store the protocol requirement itself---but not track the actual
conforming type, requiring clients of ProtocolConformanceRef to keep
track of this information separately.
Record the conforming type as part of an abstract ProtocolConformanceRef,
so that clients will be able to recover it later. This is handled by a uniqued
AbstractConformance structure, so that ProtocolConformanceRef itself stays one
pointer.
There remain a small number of places where we create an abstract
ProtocolConformanceRef with a null type. We'll want to chip away at
those and establish some stronger invariants on the abstract conformance
in the future.
`assignFixedType` now accepts `bool` as a third parameter but
not all call sites were updated to reflect that, some of them
are still passing `ConstraintLocator *` which implicitly gets
converted to a `bool`.
Previously key path type didn't have any requirements on their
root and value types but now that they do, we need a dedicated
place to perform an assignment and open/record all of the requirements.
The two GatherKinds no longer share any implementation, so there's
no point keeping the logic together. Doing this also allows removing
the acceptConstraintFn from gatherAllConstraints(), which further
simplifies depthFirstSearch().
To pave the way for the new experimental feature which will operate on '@const' attribute and expand the scope of what's currently handled by '_const' without breaking compatibility, for now.
Within the constraint system, introduce a new kind of conformance constraint,
a "nonisolated conforms-to" constraint, which can only be satisfied by
nonisolated conformances. Introduce this constraint instead of the normal
conforms-to constraint whenever the subject type is a type parameter that
has either a `Sendable` or `SendableMetatype` constraint, i.e., when the type
or its values can escape the current isolation domain.
