rdar://163631865
Under certain circumstances the same symbol can be used for different implementations of the forwarders.
The forwarders themselves are already emitted with "internal" LLVM linkage, but some particularities in
the mapping from SILLinkage to LLVM linkage caused async function pointers to partial apply forwarders
to be emitted with linkonce_odr instead, which caused the wrong forwarder to be called at runtime, causing
unexpected behavior and crashes.
This sanitizer adds MTE (memory tagging extension) checks to stack
variable accesses. Enablement simply requires setting an attribute on
function definitions, and the instrumentation is added by LLVM.
The corresponding swift-driver change is at:
https://github.com/swiftlang/swift-driver/pull/2016.
rdar://161721201
`irgen::addGenericRequirements` will later filter out Copyable
and Escapable requirements, so this field's count isn't accurate
if it's using the pre-filtered number.
This should in theory only affect the metadata emission for keypaths,
specifically, the caller `IRGenModule::getAddrOfKeyPathPattern`.
Before this change, we were sometimes using introductory platform version as the starting version where
a symbol is considered belonging to the original binary. However, this is insufficient
because backdeploying to a platform version prior to a symbol's introductory version can happen. When it
happens, we should expect the moved symbol to be found in the moved-from library, not the moved-to one. Expecting
the symbol to be found in the moved-to library can lead to crasher.
Resolves: rdar://159408187
When performing multi-threaded IRGen, all of the link libraries used
for autolinking went (only) into the first object file. If the object
files were then placed in a static archive, the autolinking would only
kick in if clients that link the static library reference something in
the first object file. This causes link failures.
Make sure that we put the autolink information into each of the object
files we create when doing multi-threaded IRGen.
Fixes the rest of rdar://162400654.
With multi-threaded IRGen, the global variables associated with "once"
initialization tokens were not getting colocated with their actual
global variables, which caused the initialization code to get split
across different files. This issue manifest as autolinking errors in
some projects.
Fixes rdar://162400654.
Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
This fixes a regression introduced by e3c8f423bc,
but the root cause was actually a subtle invariant violation
in IRGen.
FulfillmentMap's use of canonical types as keys assumes that
canonical type equality is sufficient for checking if two types
"are the same". However, this is not true when those types
contain type parameters, because two distinct type parameters
might belong to the same equivalence class.
Thus, when we take the type's context substitution map, and
apply it to each type parameter in our given list of
requirements, the substitution operation could output a
different but equivalent type parameter.
As a workaround for this problem, try to preserve the old
behavior of subst() in this specific case.
Fixes rdar://160649141.
It hoists `destroy_value` instructions for non-lexical values.
```
%1 = some_ownedValue
...
last_use(%1)
... // other instructions
destroy_value %1
```
->
```
%1 = some_ownedValue
...
last_use(%1)
destroy_value %1 // <- moved after the last use
... // other instructions
```
In contrast to non-mandatory optimization passes, this is the only pass which hoists destroys over deinit-barriers.
This ensures consistent behavior in -Onone and optimized builds.
Allow external declaration of global variables via `@_extern(c)`. Such
variables need to have types represented in C (of course), have only
storage (no accessors), and cannot have initializers. At the SIL
level, we use the SIL asmname attribute to get the appropriate C name.
While here, slightly shore up the `@_extern(c)` checking, which should
fix issue #70776 / rdar://153515764.
This is necessary because we need to model its stack-allocation
behavior, although I'm not yet doing that in this patch because
StackNesting first needs to be taught to not try to move the
deallocation.
I'm not convinced that `async let` *should* be doing a stack allocation,
but it undoubtedly *is* doing a stack allocation, and until we have an
alternative to that, we will need to model it properly.
