We should pass foreign references as Direct_Unowned calling convention,
this happened for non-const pointers. Unfortunately, we passed the const
variants as Indirect_In. This resulted in SILGen trying to insert a
non-sensical conversion. This triggered an assertion failure or a
miscompilation depending on how the compiler was compiled.
rdar://149398905
Inlinability doesn’t affect the mangling except in function specializations, which are applied after the fact and should never mangle in information from an ABI-only decl. That means we can simply ban these from `@abi` instead of inferring them.
Also adds some assertions to help double-check that SIL never tries to directly mangle or retrieve inlinability info from an ABI-only decl.
Store specialize witness tables in a separate lookup table in the module. This allows that for a normal conformance there can exist the original _and_ a specialized witness table.
Also, add a boolean property `isSpecialized` to `WitnessTable` which indicates whether the witness table is specialized or not.
These functions already have special code generation that keeps them
in the caller's isolation context, so there is no behavior change here.
Resolves: rdar://145672343
This corrects how we were dealing with dispatch thunks -- mostly be
removing a lot of special casing we did but doesn't seem necessary and
instead we correct and emit all the necessary information int TBD.
This builds on https://github.com/swiftlang/swift/pull/74935 by further refining how we fixed that issue, and adds more regression tests. It also removes a load of special casing of distributed thunks in library evolution mode, which is great.
Resolves and adds regression test for for rdar://145292018
This is also a more proper fix to the previously resolved but in a not-great-way which caused other issues:
- resolves rdar://128284016
- resolves rdar://128310903
Simply omit the 'nocapture' attribute on the parameter.
Fixes rdar://148039510 ([nonescapable] IRGen: lower addressable
params to LLVM: captures(ret: address, provenance))
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.
