Rather than using getAllConformances() to emit all conformances for a
nominal type whenever we emit its type metadata, use
getLocalConformances() consistently--on the nominal type and on any
extension--to emit the conformances in the appropriate source files.
Asking isFixedLayout() on the class's StructLayout does not take
missing members or Objective-C sliding into account. Adding a new
bit that carries this information allows removing the hack where
across modules the size of a class was always loaded from metadata.
In practice we hope most classes will be resilient, but its
better to centralize the checking for what resilience means instead
of using different rules in different places.
While most class field accesses go through accessors, a special
case is if you have a final field (or class) in a non-resilient
module. Then, we were allowed to directly access the field.
However, an earlier hack made it so that this access always went
through a field offset global, which is unnecessary in the case
where the class layout is fully known.
One consequence of this is that 'Array.count' would compile down
to a load from a global followed by an indirect load, instead of
a single load from a constant offset.
- Instead of keeping multiple flags in the type descriptor flags,
just keep a single flag indicating the presence of additional
import information after the name.
- That import information consists of a sequence of null-terminated
C strings, terminated by an empty string (i.e. by a double null
terminator), each prefixed with a character describing its purpose.
- In addition to the symbol namespace and related entity name,
include the ABI name if it differs from the user-facing name of the
type, and make the name the user-facing Swift name.
There's a remaining issue here that isn't great: we don't correctly
represent the parent relationship between error types and their codes,
and instead we just use the Clang module as the parent. But I'll
leave that for a later commit.
Summary:
CodeView does not recognize zero as an artificial line location
and so a line location of zero causes unexpected behavior when
stepping through user code. If we find a line location of zero
and our scope has not changed, we use the most recent debug
location. That is expected to be the user code that most likely
relates to the current instruction and is similar to the behavior
in LLDB.
Test Plan:
test/DebugInfo/linetable-codeview.swift
This patch adds SIL-level debug info support for variables whose
static type is rewritten by an optimizer transformation. When a
function is (generic-)specialized or inlined, the static types of
inlined variables my change as they are remapped into the generic
environment of the inlined call site. With this patch all inlined
SILDebugScopes that point to functions with a generic signature are
recursively rewritten to point to clones of the original function with
new unique mangled names. The new mangled names consist of the old
mangled names plus the new substituions, similar (or exactly,
respectively) to how generic specialization is handled.
On libSwiftCore.dylib (x86_64), this yields a 17% increase in unique
source vars and a ~24% increase in variables with a debug location.
rdar://problem/28859432
rdar://problem/34526036
ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
Switch a number of callers of the Type-based lookupQualified() over to
the newer (and preferred) declaration-based lookupQualified(). These are
the easy ones; NFC.
Previously, when a tuple type had non-fixed layout, we would compute
a layout by building the metadata for that tuple type and then
extracting the layout from the VWT. This can be quite expensive
because it involves constructing the exact metadata for types like
arrays and functions despite those types being fixed-layout across
all instantiations. It also tends to cause unnecessary recursive-type
issues, especially with enums where tuples are currently used to model
cases with mutliple payloads. Since we just need a layout, computing
it directly from element layouts instead of constructing metadata for
the formal type lets us take advantage of all the other fast paths for
layout construction, e.g. for fixed types and single-field aggregates.
This is a good improvement overall, but it also serves to alleviate
some of the problems of rdar://40810002 / SR-7876 in a way that
might be suitable for integration to 4.2.
- `swift_getForeignTypeMetadata` is now a request/response function.
- The initialization function is now a completion function, and the
pointer to it has moved into the type descriptor.
- The cache variable is no longer part of the ABI; it's an
implementation detail of the access function.
- The two points above mean that there is no special header on foreign
type metadata and therefore that they can be marked constant when
there isn't something about them that needs to be initialized.
The only foreign-metadata initialization we actually do right now is
of the superclass field of a foreign class, and since that relationship
is a proper DAG, it's not actually possible to have recursive
initialization problems. But this is the right long-term thing to do,
and it removes one of the last two clients of once-based initialization.
The prefab'ed value witness tables for reference storage types are a
premature optimization. Not all scenarios are covered, and those that
are "look suspect" according to John McCall.
As part of this, rename TypeMetadataRecordKind to TypeReferenceKind
and consistently give it three bits of storage.
The better modelling of these type references appears to have been
sufficient to make dynamic conformance checks succeed, which is good
but unexpected.
The option aligns all modules to the page size. This help giving more consistent results when doing performance testing with the swift benchmark suite.
It solves the problem that benchmarks which compile down to identical code give different runtime data because of different alignment of the code within a page.
Summary:
CodeView does not recognize zero as an artificial line location
and so a line location of zero causes unexpected behavior when
stepping through user code. If we find a line location of zero
and our scope has not changed, we use the most recent debug
location. That is expected to be the user code that most likely
relates to the current instruction and is similar to the behavior
in LLDB.
Test Plan:
test/DebugInfo/linetable-codeview.swift
The resilient methods will all be keyed by their dispatch thunks, so for methods of local subclasses, we can use the offsets relative to the dynamic base as identifiers without having to adjust for that dynamic base.
Client code doesn't necessarily know the dispatch table indexes (and in time, there may not even be such a thing), and the dispatch thunk is a stable ABI artifact that can reliably uniquely identify the thing.
- Move the filter checks in SILGen for skipping emitting certain property descriptors into the AbstractStorageDecl::exportsPropertyDescriptor() predicate, to ensure that TBDGen and SILGen are in sync
- Fix the linkage of property descriptors to be based on the getter's linkage rather than the property's, since a property may be internal but have usableFromInline accessors
