rdar://109790722
Layout strings are not guaranteed to be properly aligned, so we can't directly read from and write to it, but have to use memcpy instead.
* [IRGen] Fix layout string generation for pre-specialized metadata
rdar://108012057
Pre-specialized metadata has to be specifically handled by using the bound generic type instead of the unbound one. All the necessary information is already being passed down as BoundGenericTypeCharacteristics, we just need to apply them when present.
* Add tests and a few fixes
* Fixes after rebase
* Attempt to fix Windows linker issue in test
If something fails while trying to generate a name for an ObjC class,
we fall back to a generated name based on the metadata pointer. This
ensures that we won't crash, and if the name turns up in the debugger
or somewhere it should be obvious that something went wrong.
rdar://107718586
* [IRGen] Make pointers to accessor functions in layout strings relative
rdar://106319336
Pointers embedded in static layout strings should always be relative, so layout strings can reside in read-only memory.
* Properly handle reference storage ownership
* Pass layout tag and metadata / type layout ppointers separately
* Layout string instantiation fully working
* Fix cases where hasLayoutString flag was not set when it should have
* Update include/swift/ABI/Metadata.h
Replace them with swift_cxx_newObject/swift_cxx_deleteObject to avoid calling overridden global operators. Overridden global operators can sometimes fail when called from places the authors didn't expect.
The particular uses being changed here are:
1. Creation of new SingletonMetadataCacheEntry objects.
2. Allocation of the _globalIvarOffsets array in initGenericObjCClass.
3. Creation/destruction of SwiftTLSContext objects.
rdar://106238547
We don't have any language or runtime support for noncopyable types as generic
or dynamic types yet, and existing reflection code almost certainly assumes it
can copy the values it's working with, and will trap or corrupt state if it does
so with noncopyable types. But a class can have noncopyable fields while the
type itself is copyable, and existing code assumes that it can use `Mirror` or
other reflection mechanisms to safely traverse the contents of an arbitrary
class.
Allow this sort of code to continue working, while still preparing for forward
compatibility with future runtimes that do support noncopyable generics, by
emitting the type references for fields using a function that probes the
address of a new symbol in the Swift runtime. The symbol will either be missing
or defined with an absolute address of zero in current or previous runtime
versions, but can be changed to a non-null address in the future.
While we can't assume that pointer equality implies semantic equality
with witness table packs, it still makes sense to unique their storage
opportunistically.
* [IRGen] Add layout strings for generic and resilient types
rdar://105837048
* Add some corner cases
* Add flag to enable generic instantiation and some fixes
* Fix resilient types
* Fix metadata accessor function pointers in combined layout strings
Both return the pack immediately if its already heap allocated, by
checking the least significant bit of the pack pointer.
Then,
- swift_allocateMetadataPack() uniques the metadata pack by the
pointer equality of elements.
- swift_allocateWitnessTablePack() does not unique the pack.
Both return a pack pointer with the least significant bit set,
indicating heap allocation.
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
Replace the `assert(false)` with `swift_unreachable`.
This is more robust in release builds where the `assert(false)` is a no-op and would result in a wrong fall-though to the next switch case.
Fixes a warning in release builds.
@differentiable function is actually a triple (function, jvp, vjp). Previously normal thick function value witness table was used. As a result, for example, only function was copied, but none of differential components.
This was the cause of uninitialized memory accesses and subsequent segfaults.
Should fix now unavailable TF-1122
Swift vtables can contain NULL entries. This happens when the compiler is able to prove that a method is never called.
When ptrauth is enabled, those NULL entries are still signed. However, there's an inconsistency in the runtime. Most places where we copy a vtable with swift_ptrauth_copy_code_or_data, we accept an unsigned NULL value. But when fixing up a dynamic ObjC subclass with swift_objc_classCopyFixupHandler, we don't.
Since the compiler seems to always sign these NULL values, this still works, except in the case where a signed NULL value coincidentally has a ptrauth signature of all zeroes. When that happens, the code to accept an unsigned NULL value sees this NULL with an all-zero signature as an unsigned NULL, and copies it verbatim. Then we really do have an unsigned NULL in the destination.
If that class is then dynamically subclassed, we'll call swift_objc_classCopyFixupHandler which does not accept unsigned NULL values, and fail ptrauth.
Adjust swift_objc_classCopyFixupHandler to accept unsigned NULL like the rest. These entries should never be called, and any attempt to call them will crash regardless, so it makes little difference.
rdar://92800322
We shouldn't include <windows.h> implicitly from .cpp files, but should
do it directly so that we know it's there.
Also, if we're including <windows.h>, do it at the top of the file.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
We shouldn't include <windows.h> implicitly from .cpp files, but should
do it directly so that we know it's there.
Also, if we're including <windows.h>, do it at the top of the file.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
Tidy up the metadata definitions.
* Generalize a number of metadata kinds for out-of-process clients
* Introduce conveniences to make runtime lookups easier
* Introduce TargetExistentialTypeExpression to TrailingObjects stops complaining about OverloadTokens being ambiguous
Note that there is no impact on the layout of the metadata - the changes here are all ABI-compatible.
I wrote out this whole analysis of why different existential types
might have the same logical content, and then I turned around and
immediately uniqued existential shapes purely by logical content
rather than the (generalized) formal type. Oh well. At least it's
not too late to make ABI changes like this.
We now store a reference to a mangling of the generalized formal
type directly in the shape. This type alone is sufficient to unique
the shape:
- By the nature of the generalization algorithm, every type parameter
in the generalization signature should be mentioned in the
generalized formal type in a deterministic order.
- By the nature of the generalization algorithm, every other
requirement in the generalization signature should be implied
by the positions in which generalization type parameters appear
(e.g. because the formal type is C<T> & P, where C constrains
its type parameter for well-formedness).
- The requirement signature and type expression are extracted from
the existential type.
As a result, we no longer rely on computing a unique hash at
compile time.
Storing this separately from the requirement signature potentially
allows runtimes with general shape support to work with future
extensions to existential types even if they cannot demangle the
generalized formal type.
Storing the generalized formal type also allows us to easily and
reliably extract the formal type of the existential. Otherwise,
it's quite a heroic endeavor to match requirements back up with
primary associated types. Doing so would also only allows us to
extract *some* matching formal type, not necessarily the *right*
formal type. So there's some good synergy here.
Apply a blanket pass of including `new` for the placement new allocation
and namespacing the call to the global placement new allocator. This
should repair the Android ARMv7 builds.
