Previously even if a type's metadata was optimized away, we would still
emit a field descriptor, which in turn could reference nominal type
descriptors for other types via symbolic references, etc.
Instead of a wholly separate lazyness mechanism for foreign metadata where
the first call to getAddrOfForeignTypeMetadataCandidate() would emit the
metadata, emit it using the lazy metadata mechanism.
This eliminates some code duplication. It also ensures that foreign
metadata is only emitted once per SIL module, and not once per LLVM
module, avoiding duplicate copies that must be ODR'd away in multi-threaded
mode.
This fixes the test case from <rdar://problem/49710077>.
Non-generic classes with resilient ancestry do not have statically-emitted
metadata, so we can now emit an Objective-C resilient class stub instead.
Also, when emitting an Objective-C category, reference the class stub if
the class has resilient ancestry; previously this case would hit an assert.
Note that class stubs always start with a zero word, with the address point
pointing immediately after. This works around a linker issue, where the
linker tries to coalesce categories and gets confused upon encountering a
class stub.
* Teach the importer to import any vector type as SIMDN<Scalar>.
Instead of having a known set of vector types, check to see if the
element type conforms to SIMDScalar; if it does, see if we have a
SIMDN defined with the right number of elements. If both are satisfied,
import the vector type as that Swift type.
By making this change, we gain the ability to import vector types
that aren't defined in terms of the Darwin simd module, which lets
us use C API with vector types on other platforms. It also lets us
import *every* vector type that Swift can represent, rather than the
small subset that are currently hardcoded.
* Increased test coverage for increased SIMD types that we can import.
Includes some minor cleanup from review. Also eliminates the old
simd_sans_simd test, since we can now import all of these types even when the simd module isn't imported.
This is needed for Windows which does not support cross-module data
references without indirection. By lazy initializing the data, we can
indirect through the IAT for the data pointer and fill in the parent
pointer.
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.
This consolidates the various doesClassMetadataRequire*() checks, making
them more managable.
This also adds a forth state, ClassMetadataStrategy::Update. This will be used
when deploying to the new Objective-C runtime. For now it's not plumbed through.
Progress on <rdar://problem/47649465>.
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.
When -enable-anonymous-context-mangled-names is provided, emit mangled
names as part of the metadata of an anonymous context. This will allow
us to match textual mangled names to the metadata.
This is a backward-compatible ABI extension. Part of rdar://problem/38231646/.
Protocol descriptors for resilient protocols relatively-reference
default witness thunks, so when using -num-threads N with N > 1,
we must ensure the default witness thunk is emitted in the same
LLVM module.
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.
We were wastefully emitting an accessor if a field had a type, for
example if my field type was (() -> (X, Array<Y>>) we would force
the emission of a function to construct (() -> (X, Array<Y>)) even
though all we care about is the type metadata for X and Y.
Conversely, we would skip the field type if it contained an
archetype, even if it otherwise contained metadata that we need
to force to emit, for instance something like (T, X) where T is
a generic parameter and X is a nominal type.
A final side effect is we no longer try to emit type metadata for
one-element tuples when emitting enum payload metadata, which is
something I want to assert against.
Start emitting associated conformance requirement descriptors for
inherited protocols, so we have a symbol to reference from resilient
witness tables and mangled names in the future.
On Windows the image format does not support cross-image absolute
data symbol references. One case where we emit these is in class
metadata, because the value witness table always points at the
value witness table for Builtin.NativeObject, defined in the
runtime.
Instead, fill in the value witness table at runtime when doing
singleton metadata initialization.
Another change that will come later is to force use of singleton
metadata initialization on Windows, even if the class is otherwise
completely fixed.
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.
When a (file)private entity occurs inside a generic context, we still need
information about the genericity of the enclosing context to demangle
to metadata. Emit complete context descriptors for parents of anonymous
contexts.
Fixes rdar://problem/46109026.
The current representation of an associated conformance in a witness
tables (e.g., Iterator: IteratorProtocol within a witness table for
Sequence) is a function that the client calls.
Replace this with something more like what we do for associated types:
an associated conformance is either a pointer to the witness table (once
it is known) or a pointer to a mangled name that describes that
conformance. On first access, demangle the mangled name and replace the
entry with the resulting witness table. This will give us a more compact
representation of associated conformances, as well as always caching
them.
For now, the mangled name is a sham: it’s a mangled relative reference to
the existing witness table accessors, not a true mangled name. In time,
we’ll extend the support here to handle proper mangled names.
Part of rdar://problem/38038799.
TargetGenericParamRef is a specialized structure used to describe the
subject of a generic requirement, e.g., the “T.Assoc” in “T.Assoc: P”.
Replace it with a mangled name, for several reasons:
1) Mangled type names are also fairly concise, can often be shared, and
are a well-tested path
2) Mangled type names can express any type, which might be useful in the
future
3) This structure doesn’t accommodate specifically stating where the
conformances come from (to extract associated type witnesses). Neither
can mangled names, but we’d like to do that work in only one place.
This change exposed an existing bug where we improperly calculated the
generic parameter counts for extensions of nested generic types. Fix that
bug here (which broke an execution test).
Even if we have a constant value, we might be emitting a legacy layout
that can be updated in place by newer runtimes. In this case, clients
cannot assume the field offsets are constant, and the globals cannot
be constant either.
Part of <rdar://problem/17528739>.
