@export(interface) makes it so that Embedded Swift will emit a strong
definition of a symbol in its defining module, and use that symbol in
other modules. Extend this notion to non-generic types, where we will
emit a strong definition for the full type metadata, and let it be
referenced from other modules rather than the lazy, shared emission.
Implements rdar://176392354.
Swift has some optimizations in place to treat structs with a single
refcounted field as if it was only the field. This logic was not
correctly taken into account for foreign reference types when a struct
like this was stored in a single element enum like an Optional.
This patch fixes this logic by updating the TypeInfo hierarchy to
correctly emit strong retain/release calls during IRGen for structs with
one fields.
rdar://170990579
C++ classes can have protected destructors, copy constructors, and move
constructors. This pattern prevents that class from being directly
constructed, copied, or moved directly, but permits those operations on
types that inherit from it.
Those protected special members are inaccessible in the base class, but
are indirectly accessible in the derived class, so they shouldn't
prevent that derived class from being imported in Swift.
Such members were previously causing the derived class to be
incorrectly considered as having unknown copyability.
Note that, at the time of this patch, Swift cannot (directly) access any
members inherited from the base class with the protected special member,
because doing so relies on that base class being imported on its own
(which it can't without a public dtor/copy ctor/move ctor).
rdar://167555864
Large trivial types were copied via memcpy instead of doing a field-wise
copy. This is incorrect for types with reference fields where we also
need to bump the corresponding refcounts.
rdar://160315343
functions to compute them directly without a TypeLowering object, and
change a lot of getTypeLowering call sites to just use that.
There is one subtle change here that I think is okay: SILBuilder used to
use different TypeExpansionContexts when inserting into a global:
- getTypeLowering() always used a minimal context when inserting into
a global
- getTypeExpansionContext() always returned a maximal context for the
module scope
The latter seems more correct, as AFAIK global initializers are never
inlinable. If they are, we probably need to configure the builder with
an actual context properly rather than making global assumptions.
This is incremental progress towards computing this for most types
without a TypeLowering, and hopefully eventually removing TL entirely.
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.
If a `[[no_unique_address]]` field has zero size according to Clang, and field has a type that isn't representable in Swift, Swift would previously try to add an opaque field of size 1 for it.
This is wrong and was causing crashes for `std::string` while emitting a padding field:
```
_LIBCPP_NO_UNIQUE_ADDRESS ::std::__compressed_pair_padding<T1> _LIBCPP_CONCAT3(__padding1_, __LINE__, _);
```
rdar://151941799
Swift does not support storing fields in the padding of the previous
fields just yet, so let's not import fields like that from C++.
Represent them as opaque blobs instead.
Fixes#80764
rdar://149072458
Zero sized fields are messing up the offset calculations when we import
C++ fields to Swift. We assume that the size of the field is determined
by the type of the field. This is not true for fields marked with
no_unique_address. Those fields can have 0 size while the
sizeof(decltype(field)) is still 1.
rdar://143907490
In C++, a primary base class that is placed in the beginning of the type's memory layout isn't always the type that is the first in the list of bases – the base types might be laid out in memory in a different order.
This makes sure that IRGen handles base types of C++ structs in the correct order.
This fixes an assertion in asserts-enabled compilers, and an out-of-memory error in asserts-disabled compilers. The issue was happening for both value types and foreign reference types. This change also includes a small refactoring to reuse the logic between the two code paths.
rdar://140848603
In C++, a field of a derived class might be placed into the tail padding of a base class. Swift was not handling this case correctly, causing an asserts-disabled compiler to run out of RAM, and an asserts-enabled compiler to fail with an assertion.
Fixes this IRGen assertion:
```
Assertion failed: (offset >= NextOffset && "adding fields out of order"), function addField, file GenStruct.cpp, line 1509.
```
rdar://138764929
So call the destroy on the closing type instead.
Amends the concepts areFieldsABIAccessible/isABIAccessible to take metadata
accessibility of non-copyable types into account.
rdar://133990500
Instead of adding opaque fields for the base subobjects this patch
introduces a recursive walk to add all the base fields to the generated
Swift struct.
rdar://126754931
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
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.
Doug Gregor
Gabor Horvath
Susana Monteiro
John Hui
Anthony Latsis
swift-ci
John McCall
Egor Zhdan
Alejandro Alonso
Arnold Schwaighofer
Slava Pestov
Gábor Horváth
Alex Lorenz
Tim Kientzle
Erik Eckstein