When calling a C++ function that takes a reference to a pointer to a foreign reference type, Swift would previously pass a pointer to the foreign reference type as an argument (instead of a reference to a pointer), which resulted in invalid memory accesses.
This was observed when using `std::vector<ImmortalRef*>::push_back`.
rdar://150791778
Fixes an assertion failure in the rebranch `llvm::APInt` ctor on 32-bit
Windows. We were hitting the assertion because `uint64_t(-2)` does not
fit into 32 bits when treated as unsigned.
These assertions were enabled by default
https://github.com/llvm/llvm-project/pull/114539.
An `IRGenFunction` may not have a debug scope--for example, a dispatch
thunk--but creating an `AritificalLocation` requires one. Only create
an `ArtificalLocation` here if the `IRGenFunction` has one.
Unfortunately, I don't have an isolated test case. Fixes a compiler
crash.
If debug info generation is enabled, set debug location to the
coroutine call instruction to make sure there are no issues with invalid
debug information in LTO.
This happens because in LTO, if a call to a function doesn't contain a
debug location, we see the warning:
inlinable function call in a function with debug info must have a
!dbg location
ld: warning: Invalid debug info found, debug info will be stripped
Which then strips the debug info from the entire .o file linked into the
dylib.
Simply omit the 'nocapture' attribute on the parameter.
Fixes rdar://148039510 ([nonescapable] IRGen: lower addressable
params to LLVM: captures(ret: address, provenance))
* [SUA][IRGen] Add stub for swift_coroFrameAlloc that weakly links against the runtime function
This commit modifies IRGen to emit a stub function `__swift_coroFrameAllocStub` instead of the
newly introduced swift-rt function `swift_coroFrameAlloc`. The stub checks whether the runtime has the symbol
`swift_coroFrameAlloc` and dispatches to it if it exists, uses `malloc` otherwise. This ensures the
ability to back deploy the feature to older OS targets.
rdar://145239850
Calls to the allocation functions use the same convention regardless of
which function, so if the functino being called is malloc and free,
provide a thunk with the appropriate convention.
rdar://147872231
When an async typed throwing function had a result type that combined multiple fields into a single register, we created invalid IR, that could lead to compiler crashes or in some cases even miscompiles. With this fix we are mapping the result to the native representation before mapping it to the combined result type.
When it's available, use an open-coded allocator function that returns
an alloca without popping if the allocator is nullptr and otherwise
calls swift_coro_alloc. When it's not available, use the malloc
allocator in the synchronous context.
When TMO is enabled, change IRGen to pass the newly introduced runtime function `swift_coroFrameAlloc` (and pass an additional argument — the hash value) instead of `malloc` when it inserts calls to `coro_id_retcon_once`.
The hashValue is computed based on the current function name (computed in `getDiscriminatorForString`)
rdar://141235957
rdar://144719032
When converting the combined result back to the actual types when directly returning typed errors, in case
the error or result value was a single value smaller then pointer size and the combined value was larger,
the value was converted to the combined type instead of the actual type, making it a no-op, which caused
undefined behavior when writing the value to the coerced alloca.
`[[fallthrough]]` must be followed by a `case` label. The current use in
IRGen did not follow this requirement. Adjust the logic to match the
requirement. This fixes a few diagnostics that MSVC emitted for this
error.
