Previously, the extra data pattern structs for struct and enums were not
packed.
On 32 bit, this resulted in an extra data pattern struct which was 4
bytes too large whenever there was an odd number of fields in the
struct. The result was writing past the end of the allocated struct.
That bug only caused occasional crashes because (1) for the most part
there was additional space beyond the end of the allocation intended for
the struct metadata in the bump allocator and (2) while half of the
trailing flags field would be overwritten, because those bits of the
trailing flags being nonzero did not have an observable effect since
those bits of the trailing flags field are not yet used.
Here, the structs are marked packed, resulting in the appropriate size
for the extra data pattern structs on 32 bit platforms.
rdar://problem/68997282
By default, emitTypeMetadataRef does a blocking request for complete
metadata, which is the right thing to do for most purposes in IRGen.
Unfortunately, it's actively dangerous in code that can be called
during metadata completion, like an associated conformance accessor,
because it can cause artificial dependency cycles that the runtime
isn't equipped to detect, much less solve.
This is a partial fix for rdar://69901318, which also exposes a bad
metadata access path that seems to be causing an artificial problem.
Previously, the trailing flags field of runtime instantiated generic
metadata for types which had prespecialization enabled were not zeroed.
Consequently, the field always contained garbage. Often, metadata was
instantiated on new (and so, zeroed) pages, so the garbage happened to
be zero as is appropriate. However, when the metadata was instantiated
on pages which had previously been dirtied, the garbage value would
sometimes indicate that the metadata was canonical statically
specialized. When that occurred, swift_checkMetadataState would
incorrectly return a metadata state of complete, despite the fact that
the metadata might not in fact be complete. As a result, the runtime
was trafficking in incomplete metadata as if it were complete, resulting
in various crashes that would arise from for example missing a witness
table or a value witness table.
Here the problem is corrected. The trailing flags field of structs and
enums that have the field is set to 0.
For structs, this is accomplished by modifying the extra data pattern to
exist not only when there is fixed type info for the type but also when
the type is being prespecialized. Specifically, the extra data for a
struct is, rather than an i32 array of field offsets, a struct
consisting of none, one, or both of the following: (1) the array of
field offsets, (2) the trailing flags.
Similarly, enums now have an extra data pattern which consists of none,
one, or both of the following: (1) the payload size, (2) the trailing
flags. Enum metadata extra data setting was previously achieved by
customizing the metadata allocation function; that customization is now
eliminated, being replaced with the shared runtime code for copying
extra data into place, a modest code size savings.
rdar://problem/61465515
Regardless of any flags, the stdlib will have its generic metadata
prespecialized.
Temporarily reintroduced the flag to enable the feature flag while
preserving the flag to disable it and changed the default back to off
for the moment.
Temporarily disable metadata prespecialization on platforms other than
MacOS, iOS, tvOS, watchOS, or Linux. At the moment, tests are failing
on Windows with linker errors such as
demangleToMetadata-558ea9.o : error LNK2001: unresolved external symbol $ss5Int64VN
demangleToMetadata-558ea9.o : error LNK2001: unresolved external symbol $sSSSHsWP
Once the issue leading to those linker errors has been resolved, the
feature will be enabled on Windows.
Previously, -Xfrontend -prespecialize-generic-metadata had to be passed
in order for generic metadata to be prespecialized. Now it is
prespecialized unless -Xfrontend
-disable-generic-metadata-prespecialization is passed.
