This initialization pattern can only be used if there is a backward deployment
layout (IRGen calls this ClassMetadataStrategy::FixedOrUpdate) or if we are
running on a newer Objective-C runtime that supports class metadata update
hooks (IRGen calls this ClassMetadataStrategy::Update).
If neither condition holds, we must trap here to avoid undefined behavior.
The swift side signature for `swift_swiftValueConformsTo` is:
`func swift_swiftValueConformsTo<T>(_: T.self) -> Bool`
This translates to:
`bool swift_swiftValueConformsTo(const Metadata *, const Metadata *)`
The elided parameter would be passed invalid values.. Running this on
Windows with optimizations triggered an optimization where the parameter
happened to be null as `rdx` is the second parameter rather than the 4th
parameter.
This is done by disallowing nodes with children to also have index or text payloads.
In some cases those payloads were not needed anyway, because the information can be derived later.
In other cases the fix was to insert an additional child node with the index/text payload.
Also, implement single or double children as "inline" children, which avoids needing a separate node vector for children.
All this reduces the needed size for node trees by over 2x.
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.
Note that I've called out a couple of suspicious places where we
are requesting abstract metadata for superclasses but probably
need to be requesting something more complete.
MetadataLookup gives special treatment to imported Objective-C classes,
since there's no nominal type descriptor and metadata is obtained
directly by calling into the Objective-C runtime.
Remote reflection also gives special treatment to imported Objective-C
classes; they don't have field descriptors.
However, the ASTDemangler needs to treat them like ordinary classes,
in particular it wants to preserve the generic arguments here so that
we can round-trip debug info.
If we nest a type inside a local context inside a generic type,
we have to look through the local context(s) to find the outer
generic type when stripping off generic arguments.
We don't support nominal types inside generic local context
right now, but this can happen with type aliases.
The part of the tag stored in the payload can currently be up to
8 bytes in size (though only the 'low' 4 bytes can be non-zero).
On little-endian machines this doesn't matter, we can always just
store up to 4 bytes and zero the remaining payload bytes. On big-
endian systems however we may need to store more than 4 bytes.
The store implementation now mirrors the runtime code that fetches
the tag on big-endian systems which already treats the payload tag
as an 8 byte integer.
This is a spot fix but longer term we might want to consider
refactoring this code to reduce the number of differences between
big- and little-endian implementations. For example, we could
centralise some of the copying logic and/or make the payload tag
a 4 byte field on all platforms.
Debug info uses a special mangling where type aliases can be
represented without being desugared; attempt to reconstruct
the TypeAliasType in this case.
Once upon a time we tried to use this to limit the visibility of
symbols in the Swift runtime in a way that didn't really make sense.
Dave Z removed it last year in 91823273d2.
No functionality change.
This fixes the Windows platform, where the aligned allocation path is
not malloc-compatible. It won't have any observable difference on
Darwin or Linux, aside from manually allocated memory on Linux now
being consistently 16-byte aligned (heap objects will still be 8-byte
aligned on Linux).
It is unfortunate that we can't guarantee Swift-allocated memory via
Unsafe*Pointer is malloc compatible on Windows. It would have been
nice for that to be a cross platform guarantee since it's normal to
allocate in C and deallocate in Swift or vice-versa. Now we have to
tell developers to always use _aligned_malloc/_aligned_free when
transitioning between Swift/C if they expect their code to work on
Windows.
Even though this fix isn't required today on Darwin/Linux, it makes
good sense to guarantee that the allocation/deallocation paths are
consistent.
This is done by specifying a constant that stdlib can use to round up
alignment, _swift_MinAllocationAlignment. The runtime asserts that
this constant is greater than MALLOC_ALIGN_MASK for all platforms.
This way, manually allocated buffers will always use the aligned
allocation path. If users specify an alignment less than m
round up so users don't need
to pass the same alignment to deallocate the buffer). This constant
does not need to be ABI.
Alternatives are:
1. Require users of Unsafe*Pointer to specify the same alignment
during deallocation. This is obviously madness.
2. Introduce new runtime entry points:
swift_alignedAlloc/swift_alignedDealloc, introduce corresponding
new builtins, and have Unsafe*Pointer always call those. This would
make the runtime API a little more obvious but would introduce
complexity in other areas of the compiler and it doesn't have any
other significant benefit. Less than 16-byte alignment of manually
allocated buffers on Linux is a non-goal.
The mapping of the return value of the `FlsAlloc` was flipped resulting
in the failure of the TLS key creation. The test suite would fail to
generate the TLS key resulting in failures.
We were creating a local Demangler instance, demangling a type name
using it, and then returning one of the resulting nodes to the caller.
Fixes rdar://problem/46817009.
Anonymous context descriptors were being treated as non-generic by
IRGen, which lead to problems for (file)private types within generic
types. Emit generic parameters and requirements for anonymous contexts
as well.
The runtime was mostly prepared for this, and the ABI already
accounted for it, so the runtime change is minor---it only affected
building a demangle tree from metadata.
Fixes rdar://problem/46853806.
The Name field of a type descriptor is not the appropriate
way to compare types for uniquing. Instead, use TypeContextIdentity.
Fixes rdar://problem/46685973.
This is essentially a long-belated follow-up to Arnold's #12606.
The key observation here is that the enum-tag-single-payload witnesses
are strictly more powerful than the XI witnesses: you can simulate
the XI witnesses by using an extra case count that's <= the XI count.
Of course the result is less efficient than the XI witnesses, but
that's less important than overall code size, and we can work on
fast-paths for that.
The extra inhabitant count is stored in a 32-bit field (always present)
following the ValueWitnessFlags, which now occupy a fixed 32 bits.
This inflates non-XI VWTs on 32-bit targets by a word, but the net effect
on XI VWTs is to shrink them by two words, which is likely to be the
more important change. Also, being able to access the XI count directly
should be a nice win.
This can be used by compiler-generated code as a size optimization for metadata access, using a
mangled name instead of possibly many open-coded metadata calls. It can also allow reflection
libraries outside of the standard library to turn type reference strings into in-process metadata
pointers in a robust way. rdar://problem/46451849
While declaration mangling now does the right thing for parameter lists,
the function type mangling unfortunately still models the parameter list
as a single tuple node.
Change the runtime's behavior to match the AST mangler, which wraps
a single tuple-typed parameter in a tuple node, so that we can produce
different mangling trees for function types taking multiple arguments
versus a single tuple argument.
* cmake: Propagate SWIFT_DARWIN_ENABLE_STABLE_ABI_BIT to overlay builds.
* runtime: Clear the correct bit in getROData()
* test/IRGen/objc_class_export.swift: Allow either is-Swift bit.
* test/stdlib/SwiftObjectNSObject.swift: Allow either name for SwiftObject.
Currently ignored, but this will allow future compilers to pass down source location information for cast
failure runtime errors without backward deployment constraints.
The SDK directory is now confusing as the Windows target also has a SDK
overlay. In order to make this more uniform, move the SDK directory to
Darwin which covers the fact that this covers the XNU family of OSes.
The Windows directory contains the SDK overlay for the Windows target.
