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.
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
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
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
`@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
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
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.
- Track environments for `PackExpansionExpr` directly
instead of using a locator.
- Split up the querying and creation of the environment
such that the mismatch logic can be done directly in
CSSimplify instead of duplicating it.
- Just store the environment directly instead of
the shape and UUID.
It should be possible to pass values with `any Sendable` as arguments
to `inout` parameters that expect `Any`. This is pretty much the same
as an l-value conversion.
Resolves: https://github.com/swiftlang/swift/issues/79361
Resolves: rdar://144794132
