Call `swift_clearSensitive` after destroying or taking "sensitive" struct types.
Also, support calling C-functions with "sensitive" parameters or return values. In SIL, sensitive types are address-only and so are sensitive parameters/return values.
Though, (small) sensitive C-structs are passed directly to/from C-functions. We need re-abstract such parameter and return values for C-functions.
* Allow normal function results of @yield_once coroutines
* Address review comments
* Workaround LLVM coroutine codegen problem: it assumes that unwind path never returns.
This is not true to Swift coroutines as unwind path should end with error result.
We've been building up this exponential explosion of task-creation
builtins because it's not currently possible to overload builtins.
As long as all of the operands are scalar, though, it's pretty easy
to peephole optional injections in IRGen, which means we can at
least just use a single builtin in SIL and then break it apart in
IRGen to decide which options to set.
I also eliminated the metadata argument, which can easily be recreated
from the substitutions. I also added proper verification for the builtin,
which required (1) getting `@Sendable` right more consistently and (2)
updating a bunch of tests checking for things that are not actually
valid, like passing a function that returns an Int directly.
When ObjC interop is not enabled, we shouldn't be emitting calls to
`objc_retainAutoreleasedReturnValue()` as that function might not exist.
Call `swift_retain()` instead, to balance the `swift_release()` of the
returned value.
Fixes#47846, #45359.
rdar://23335318
Fix a bug in expandExternalSignatureTypes where it wasn't annotating a function call parameter type with sret when the result was being returned indirectly.
The bug was causing calls to ObjC methods that return their results indirectly to crash.
Additionally, fix the return type for C++ constructors computed in expandExternalSignatureTypes. Previously, the return type was always void even on targets that require constructors to return this (e.g., Apple arm64), which was causing C++ constructor thunks to be emitted needlessly.
Resolves rdar://121618707
We need to only generate references to `_swift_exceptionPersonality`
if we're building for a new enough runtime. The previous code was
good on Darwin, but would have resulted in build problems on Linux.
rdar://120952971
The previous approach was effectively to catch the exception and then
run a trap instruction. That has the unfortunate feature that we end
up with a crash at the catch site, not at the throw site, which leaves
us with very little information about which exception was thrown or
where from.
(Strictly we do have the exception pointer and could obtain exception
information, but it still won't tell us what threw it.)
Instead of that, set a personality function for Swift functions that
call potentially throwing code, and have that personality function
trap the exception during phase 1 (i.e. *before* the original stack
has been unwound).
rdar://120952971
Merge conflict while removing `nocapture` from
`s21move_function_dbginfo20addressOnlyValueTestyyxAA1PRzlF`. Resolution
was to remove nocapture from the expected output in both cases:
```
// CHECK-LABEL: define swiftcc void @"$s21move_function_dbginfo20addressOnlyValueTestyyxAA1PRzlF"(ptr noalias[-nocapture-] %0, ptr %T, ptr %T.P)
```
Conflict cause: 4858cb6225
This is the same as the original change to this file. The conflict seems
to be due to the next line changing, when moving from llvm.dbg.addr to
llvm.dbg.value.
Conflicts:
test/DebugInfo/move_function_dbginfo.swift
The use of 'nocapture' for parameters and return values is incorrect for C++ types, as they can actually capture a pointer into its own value (e.g. std::string in libstdc++)
rdar://115062687
KeyPath's getter/setter/hash/equals functions have their own calling
convention, which receives generic arguments and embedded indices from a
given KeyPath argument buffer.
The convention was previously implemented by:
1. Accepting an argument buffer as an UnsafeRawPointer and casting it to
indices tuple pointer in SIL.
2. Bind generic arguments info from the given argument buffer while emitting
prologue in IRGen by creating a new forwarding thunk.
This 2-phase lowering approach was not ideal, as it blocked KeyPath
projection optimization [^1], and also required having a target arch
specific signature lowering logic in SIL-level [^2].
This patch centralizes the KeyPath accessor calling convention logic to
IRGen, by introducing `@convention(keypath_accessor_XXX)` convention in
SIL and lowering it in IRGen. This change unblocks the KeyPath projection
optimization while capturing subscript indices, and also makes it easier
to support WebAssembly target.
[^1]: https://github.com/apple/swift/pull/28799
[^2]: https://forums.swift.org/t/wasm-support/16087/21
When the differentiating a function containing loops, we allocate a linear map context object on the heap. This context object may store non-trivial objects, such as closures, that need to be released explicitly. Fix the autodiff linear map context allocation builtins to correctly release such objects and not just free the memory they occupy.
Adding a few more updates to places where the ABI Alignment functions
changed. `getABITypeAlignment` was replaced with `getABITypeAlign`,
which returns an `llvm::Align` instead of an unsigned int.
Clang and LLVM added some new builtins.
LLVM added IITDescriptor::AArch64Svcount, which I set to not be
decodable since Swift can't represent those at the moment.
Also added handling for the WASM reference type builtins in the Clang
type converter.
LLVM deprecated, renamed, and removed a bunch of APIs. This patch
contains a lot of the changes needed to deal with that.
The SetVector type changed the template parameters.
APInt updated multiple names, countPopulation became popcount,
getAllOnesValue became getAllOnes, getNullValue became getZero, etc...
Clang type nullability check stopped taking a clang AST context.
The LLVM IRGen Function type stopped exposing basic block list directly,
but gained enough API surface that the translation isn't too bad.
(GenControl.cpp, LLVMMergeFunctions.cpp)
llvm::Optional had a transform function. That was being used in a couple
of places, so I've added a new implementation under STLExtras that
transforms valid optionals, otherwise it returns nullopt.
Fixes https://github.com/apple/swift/issues/66326
This allows us to reneable Windows method tests. Note that Windows still has
a broken convention for non-trivial record with non-trivial destructor but
trivial copy-constructor, so classes in the methods.swift test need an explicit
copy constructor.
Fixes rdar://88391102
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
- Renames ExperimentalPlatformCCallingConvention to
PlatformCCallingConvention.
- Removes non-arm calling convention support as this feature is working
around a clang bug for some arm triples which we hope to see resolved.
- Removes misleading MetaVarName from platform-c-calling-convention
argument.
- Replaces other uses of LLVM::CallingConv::C with
IGM.getOptions().PlatformCCallingConvention().
Adds a new swift-frontend flag to allow users to choose which calling
convention is used to make c function calls. This hidden flag is called
`-experimental-platform-c-calling-convention`.
This behavior is needed to workaround rdar://109431863 (Swift-frontend
produces trapping llvm ir for non-trapping sil). The root cause of this
issue is that IRGen always emits c function calls with llvm's default C
calling convention. However clang may select a different (incompatible)
calling convention for the function, eventually resulting--via
InstCombine and SimplifyCFG--in a trap instead of the function call.
This failure mode is most readily seen with the triple
`armv7em-apple-none-macho` when attempting to call functions taking
struct arguments. Example unoptimized ir below:
```llvm-ir
call void @bar([4 x i32] %17, i32 2), !dbg !109
...
define internal arm_aapcs_vfpcc void @bar(
[4 x i32] %bar.coerce, i32 noundef %x)
```
In the future it would be better to use the clang importer or some other
tool to determine the calling convention for each function instead of
setting the calling convention frontend invocation wide.
Note: I don't know for sure whether or not clang should be explicitly
annotating these functions with a calling convention instead of
aliasing C to mean ARM_AAPCS_VFP for this particular combination of
`-target`, `-mfloat-abi`, and `-mcpu`.
