The Swift compiler used to generate a direct call to functions taking
rvalue references to trivial types even though they expected an indirect
calling conventions. This PR changes the calling convention on the Swift
side to match C++.
rdar://148585343
A struct or tuple value can have "none" ownership even if its type is not trivial.
This happens when the struct/tuple contains a non-trivial enum, but it's initialized with a trivial enum case (e.g. with `Optional.none`).
```
%1 = enum $Optional<String>, #Optional.none!enumelt
%2 = struct $S (%32) // has ownership "none"
%3 = struct_extract %2, #S.x // should also have ownership "none" and not "guaranteed"
```
So far it got "guaranteed" ownership which is clearly wrong.
Fixes an assertion crash in redundant load elimination.
https://github.com/swiftlang/swift/issues/80430
rdar://148311534
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.
When performing a dynamic cast to an existential type that satisfies
(Metatype)Sendable, it is unsafe to allow isolated conformances of any
kind to satisfy protocol requirements for the existential. Identify
these cases and mark the corresponding cast instructions with a new flag,
`[prohibit_isolated_conformances]` that will be used to indicate to the
runtime that isolated conformances need to be rejected.
Adds assertions in various places where properties that can vary between ABI-only decls and their counterparts—particularly function and parameter attributes—are handled in SILGen, ensuring that we don’t accidentally end up processing ABI-only decls there.
I am doing this in preparation for adding the ability to represent in the SIL
type system that a function is global actor isolated. Since we have isolated
parameters in SIL, we do not need to represent parameter, nonisolated, or
nonisolated caller in the type system. So this should be sufficient for our
purposes.
I am adding this since I need to ensure that we mangle into thunks that convert
execution(caller) functions to `global actor` functions what the global actor
is. Otherwise, we cannot tell the difference in between such a thunk and a thunk
that converts execution(caller) to execution(concurrent).
This is a value operation that can work just fine on lowered types,
so there's no need to carry along a formal type. Make the value/address
duality clearer, and enforce it in the verifier.
