This attribute was introduced in
7eca38ce76d5d1915f4ab7e665964062c0b37697 (llvm-project).
Match it using a wildcard regex, since it is not relevant to these
tests.
This is intended to reduce future conflicts with rebranch.
Add specific deployment target versions to some tests that need to test
10.x-specific behaviours and are currently depending on the default
deployment target.
Certain tests were only checking either the stable or unstable ABI
depending on the platform the test was running. In those cases I doubled
up the checks so that we would test both cases on platforms that
supported it. This might use a bit of extra time on targets that only
support the stable ABI, but it seemed worth it for the additional
coverage in CI.
Clang does not accept `-x objective-c` with WebAssembly target and it
crashes with "Objective-C support is unimplemented for object file
format" for now. `-enable-objc-interop` can work without the objc
runtime support (which is indicated by `objc_interop` feature), so this
adds a new `objc_codegen` feature to require Objective-C support only
at compile-time.
rdar://105837040
* WIP: Store layout string in type metadata
* WIP: More cases working
* WIP: Layout strings almost working
* Add layout string pointer to struct metadata
* Fetch bytecode layout strings from metadata in runtime
* More efficient bytecode layout
* Add support for interpreted generics in layout strings
* Layout string instantiation, take and more
* Remove duplicate information from layout strings
* Include size of previous object in next objects offset to reduce number of increments at runtime
* Add support for existentials
* Build type layout strings with StructBuilder to support target sizes and metadata pointers
* Add support for resilient types
* Properly cache layout strings in compiler
* Generic resilient types working
* Non-generic resilient types working
* Instantiate resilient type in layout when possible
* Fix a few issues around alignment and signing
* Disable generics, fix static alignment
* Fix MultiPayloadEnum size when no extra tag is necessary
* Fixes after rebase
* Cleanup
* Fix most tests
* Fix objcImplementattion and non-Darwin builds
* Fix BytecodeLayouts on non-Darwin
* Fix Linux build
* Fix sizes in linux tests
* Sign layout string pointers
* Use nullptr instead of debug value
In preparation for moving to llvm's opaque pointer representation
replace getPointerElementType and CreateCall/CreateLoad/Store uses that
dependent on the address operand's pointer element type.
This means an `Address` carries the element type and we use
`FunctionPointer` in more places or read the function type off the
`llvm::Function`.
When building the label for the IAT synthetic, we need to pre-decorate
the symbol before we apply the synthetic symbol prefix lest we end up
placing the user-label prefix over the synthetic symbol rather than the
actual symbol. This is required to correctly resolve symbols when
building the standard library for x86.
Adjust the test to accommodate environments which do indirect imports,
which use the singleton strategy, relying on the runtime initialization
of fields which are imported.
The correct usage of "-SAME" is after the check-prefix, not in the
middle. I've updated the constants to what is emitted today.
Now with verified 32-bit fixes.
This indicates that the "self" argument to the current function is always dynamically of the exact
static base class type, allowing metadata accesses in IRGen to use the local self metadata to answer
metadata requests for the class type. Set this attribute on allocating entry points of designated
inits, which is one of the most common places where we emit redundant metadata accesses.
Recent Swift uses 2 as the is-Swift bit when running on newer versions, and 1 on older versions. Since it's difficult or impossible to know what we'll be running on at build time, make the selection at runtime.
Field offset vectors are always filled out with either zero or the static layout's offset, depending on the metadata initialization strategy. This change means that the static layout's offset will only be non-zero for properties with a statically-known layout. Existing runtimes doing dynamic class layout assign class properties a zero offset if the field offset vector entry is zero and the property is zero-sized. So this effectively brings the compiler into accord with the runtime (for all newly-compiled Swift code, which will eventually be all Swift code because the current public releases of Swift 5 are not yet considered ABI-stable) and guarantees a zero value for the offset everywhere.
Since the runtime will agree with the compiler about the zero value of the offset, the compiler can continue to emit such offset variables as constant. The exception to this rule is if the class has non-fragile ObjC ancestry, in which case the ObjC runtime (which is not aware of this special rule for empty fields) will attempt to slide it along with everything else.
Fixes rdar://48031465, in which the `FixedClassMetadataBuilder` for a class with a legacy-fixed layout was writing a non-zero offset for an empty field into the field offset vector, causing the runtime to not apply the special case and thus to compute a non-zero offset, which it then attempted to copy into the global field offset variable, which the compiler had emitted as a true-constant zero.
In our initial approach for resolving metadata dependency cycles with classes, non-transitively complete superclass metadata was fetched by the subclass's metadata completion function and passed to `swift_initClassMetadata`. That could mean generating quite a lot of code in the completion function, and so we fairly recently changed it so that `swift_initClassMetadata` instead fetched the superclass metadata via a demangling. Unfortunately, the metadata demangler only fetches _abstract_ metadata by default, and class metadata cannot be considered even non-transitively complete when its superclass reference not at that stage. If the superclass metadata is being completed on one thread, and a subclass is being completed on another, and the subclass installs the incomplete superclass metadata in its superclass field and attempts to register the subclass with the Objective-C runtime, the runtime may crash reading the incompletely-initialized superclass.
The proper fix is to make `swift_initClassMetadata` fetch non-transitively complete metadata for the superclass, delaying completion if that metadata is unavailable. Unfortunately, that can't actually be implemented on top of `swift_initClassMetadata` because that function has no means of reporting an unsatisfied dependency to its caller, and we can no longer simply change its signature without worrying about a small of internal code that might still be using it. We cannot simply perform a blocking metadata request in `swift_initClassMetadata` because it is deeply problematic to block within a metadata completion function. The solution is therefore to add a `swift_initClassMetadata2` which has the ability to report unsatisfied dependencies. That was done in #22386; this patch builds on that by teaching the compiler to generate code to actually use it. It is therefore not safe to use this patch if you might be running on an OS that only provides the old runtime function, but that should be a temporary Apple-internal problem.
Fixes rdar://47549859.
Update the IRGen tests for Windows IRGen. This is an improvement over
what we have currently, but is not sufficient to get all the IRGen tests
passing yet.
We want to be able to define classes with a fixed storage layout,
but a resilient (opaque) vtable. If the class is also generic,
we still have to load field offsets from the metadata if they
are dependent.
So put the field offsets after the generic arguments and before
the vtable.
This is an ABI break for @_fixed_layout classes, which are
defined by the stdlib.
IRGen always just emits a simple implementation that immediately
calls swift_relocateClassMetadata(); so allow the function to be
null in this case to save on code size.
Rather than rely on the metadata initialization function to compute and
fill in the superclass, use the mangled superclass name to construct the
superclass metadata.
Previously we would emit class metadata for classes with resilient
ancestry, and relocate it at runtime once the correct size was known.
However most of the fields were blank, so it makes more sense to
construct the metadata from scratch, and store the few bits that we
do need in a true-const pattern where we can use relative pointers.
They were, already, but remove the isConstant parameter to
getAddrOfTypeMetadataPattern(), and just assert that its true for
patterns in defineTypeMetadata() instead.
Also, metadata patterns are i8*, not i8**. In fact they don't contain any
absolute pointers at all.
Should be NFC other than the LLVM type change.
Similar to the non-resilient case, except we also emit a 'relocation
function'. The class descriptor now contains this relocation function
if the class has resilient ancestry, and the relocation function
calls the runtime's swift_relocateClassMetadata() entry point.
The metadata completion function calls swift_initClassMetadata() and
does layout, just like the non-resilient case.
Fixes <rdar://problem/40810002>.
Now that we don't need the superclass before calling
swift_relocateClassMetadata(), it seems simpler to set it
here instead of doing it in various places in IRGen.
Using the superclass metadata here no longer makes sense with two-phase
init, in case the superclass metadata depends on the class being
instantiated.
It would also be nice to rework the resilient class metadata 'pattern'
to be its own data structure that's true const, instead of just the
prefix of a real class metadata, but for now let's keep the existing
crappy design.
If a class has generic ancestry or resiliently-sized fields, but is
itself not generic and does not have resilient ancestry, we must
perform runtime metadata initialization, but we can initialize
the metadata in-place.
As with generic classes or classes with resilient ancestry, we
copy generic requirements and field offset vectors from the
superclass. We also calculate the layout of the class's direct
fields at runtime.
Unlike the fully resilient case, we don't copy vtable entries
from the superclass, or install the direct class's vtable
entries from the type context descriptor. Instead, we statically
emit the vtable as with fixed-size class metadata.
Both the in-place and resilient case call the same runtime
entry point to initialize class metadata; the new HasStaticVTable
flag in ClassLayoutFlags is used to select between the two
behaviors concerning the vtable.
