If a constrained extension has fewer conformance requirements
than the nominal type declaration, because some of the type
parameters of the nominal type are fixed to concrete types by
the extension, we would run into trouble because interface
type substitution does not correctly handle this case.
Applying an identity substitution map to an interface type
does not look up concrete types in the output generic
signature, so we get back a type parameter that is not valid.
getReducedType() has a hack to deal with this. I'd like to
get rid of the hack and fix interface type substitution to
do this correctly, but until then, this will do.
Fixes https://github.com/swiftlang/swift/issues/76479
Unless there is some meaningful code on the same line as an await call (e.g.
other parts of an expression), there should be no additional line entries
associated with that line on the continuation funclet.
This patch changes codegen to avoid emitting debug location for the "prologue" code
at the start of a funclet, instead of simply copying the debug location of the
split point.
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
A change to the way we determined whether a protocol conformance is
"dependent" for marker protocols caused an ABI break for
Sendable-refining protocols built with pre-6.0 Swift compilers. The
fix for this issue (https://github.com/swiftlang/swift/pull/75769)
gated the change on deployment target.
The deployment target change fixed the original problem, then caused a
related issue when a project mixes deployment targets (pre-6.0 and
6.0+) with non-resilient protocols. Exempt non-resilient protocols from
this change so we get consistent behavior.
Fixes rdar://134953989.
Mangling this information for future directions like component lifetimes
becomes complex and the current mangling scheme isn't scalable anyway.
Deleting this support for now.
On Windows/AArch64, a different register is used between when an
arugment is both inreg and sret (X0 or X1) and when it is just sret
(X8) as the following comment indicates:
46fe36a429/llvm/lib/Target/AArch64/AArch64CallingConvention.td (L42)
```
// In AAPCS, an SRet is passed in X8, not X0 like a normal pointer parameter.
// However, on windows, in some circumstances, the SRet is passed in X0 or X1
// instead. The presence of the inreg attribute indicates that SRet is
// passed in the alternative register (X0 or X1), not X8:
// - X0 for non-instance methods.
// - X1 for instance methods.
// The "sret" attribute identifies indirect returns.
// The "inreg" attribute identifies non-aggregate types.
// The position of the "sret" attribute identifies instance/non-instance
// methods.
// "sret" on argument 0 means non-instance methods.
// "sret" on argument 1 means instance methods.
CCIfInReg<CCIfType<[i64],
CCIfSRet<CCIfType<[i64], CCAssignToReg<[X0, X1]>>>>>,
CCIfSRet<CCIfType<[i64], CCAssignToReg<[X8]>>>,
```
So missing/dropping inreg can cause a codegen bug.
This is a partial fix for #74866
