We use C++17 for the Swift compiler and IRGen uses the sized
deallocation for releasing memory it creates with over-allocation. That
triggers ASAN warnings due to the mismatched
`operator new`/`operator delete`.
A C struct can be imported as noncopyable, but C doesn't have
destructors, so there is no way to provide user-defined logic to
perform the destruction. Introduce a new swift_attr that applies to
imported noncopyable types and which provides such a "destroy"
operation. It can be used like this:
typedef struct __attribute__((swift_attr("~Copyable")))
__attribute__((swift_attr("destroy:wgpuAdapterInfoFreeMembers")))
WGPUAdapterInfo { /*...*/ } WGPUAdapterInfo;
void wgpuAdapterInfoFreeMembers(WGPUAdapterInfo adapterInfo);
This will bring the WGPUAdapterInfo struct in as a noncopyable type
that will be cleaned up by calling wgpuAdapterInfoFreeMembers once it
is no longer in use.
Implements rdar://156889370.
ASAN identified mismatched `operator new` and `operator delete` on these
types. The reason for this is the sized allocation for the tail packing
involved. Provide the associated `operator delete` that releases the
memory. Note that the `operator delete` is static and does not have the
implicit `this` pointer, and we cannot use the name `this` for the
variable.
The stable/21.x branch is not happy with us setting the object pointer
flag here because it now asserts that this flag is set for at most one
function parameter. We should add a dedicated routine for instance
method parameters. For now, stop setting the flag altogether to unblock
the stdlib build on rebranch.
inside function returning it
A stack overflow would happen when the compiler tried emitting debug
info for a function whose opaque return type was declared inside the
function itself. This fixes the issue by emitting a forward declaration
for the function before emitting it.
rdar://150313956
So far we only supported this for `load` and `call` arguments. Now we use `llvm.assume` for other kind of argument values.
This helps optimizing bounds checking for `Span`.
It looks like the addition of a defaulted parameter to
`llvm::IRBuilderBase::CreateOr` in
https://github.com/llvm/llvm-project/pull/146350 caused it to conflict
with our own version of the method. Sync up their signatures.
While the intent behind this functor was noble, it has grown in complexity
considerably over the years, and it seems to be nothing but a source of
crashes in practice. I don't want to deal with it anymore, so I've decided
to just subsume all usages with LookUpConformanceInModule instead.
We insert end_cow_mutation_addr for lifetime dependent values dependent on mutable addresses.
end_cow_mutation_addr can be simplified to end_cow_mutation after other optimizations like inlining, specialization etc
This PR adds an instruction simplification to transform end_cow_mutation_addr to end_cow_mutation.
This can enable array optimizations which look for end_cow_mutation.
If back-deploying prior to the introduction of name mangling and
runtime support for invertible constraints (~Copyable, ~Escapable),
don't use mangled names to access metadata. The code already existed
for this, but had a carve-out that still used mangled names for
standard library types that have always existed but got generalized to
support non-copyable & non-escapable types.
Tweak that carve-out to not apply to types like Span that come from a
back-deployment library. Fixes crashes when using metadata for Span et
al on older platforms.
Fixes rdar://155639204.
