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
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
SubstitutionMaps are now just a trivial pointer-sized value, so
pass them by value instead.
I did have to move a couple of functors from Type.h to SubstitutionMap.h
to resolve some issues with forward declarations.
Within a dump of a DeclRef (or, more likely, a larger entity that includes one),
the full multiline details of a substitution map are likely to not be hugely
relevant, and just get in the way of understanding the interesting parts of the
dump. Thus, this is a variant that is a single line and just includes the
substitutions; the conformances (or, at least, the protocols involved) can be
inferred from the generic signature combined with those substitutions.
The style is controlled via a enum rather than a boolean, to avoid problems with
trying to pass an indent like `map->dump(out, indent)`, where the integer indent
coerces to a bool, rather than error.
Fixes rdar://problem/40074968.
This is much easier to read when part of a larger dump, where it now occurs in
expressions and specialized conformances.
Part of rdar://problem/40074968.
Introduced during the bring-up of the generics system in July, 2012,
Substitution (and SubstitutionList) has been completely superseded by
SubstitutionMap. R.I.P.
Introduce an operation to check that a given substitution map is non-empty
(i.e., corresponds to a generic signature) and that the generic signature
has type parameters that aren’t bound to concrete types. This is the
appropriate predicate for SIL-and-later to determine whether there
will be any substitutions.
Every SubstitutionMap::toList() invocation would ASTContext-allocate
arrays for all of the conformances, then return a SmallVector of the
underlying substitutions, which both wastes memory *and* puts the onus
on the caller to allocate a copy of that outer SmallVector into the
ASTContext if it's going to be stored anywhere.
Stop the madness by caching an ASTContext-allocated SubstitutionList
within the storage for the SubstitutionMap. This both reduces repeated
allocations and eliminates the potential for errors.
Now that SubstitutionMap is used in so many places, reduce it's header
dependencies by moving SubstitutionMap::Storage into its own separate
implementation header. Use forward declarations of other entities
(GenericSignature, Substitution) instead.
Good for build times and general sanity.
Replace two prominent uses of SubstitutionList, in ConcreteDeclRef and
Witness, with SubstitutionMap. Deal with the myriad places where we
now have substitution maps and need substitution lists (or vice versa)
caused by this change.
Overall, removes ~50 explicit uses of SubstitutionList (of ~400).
Allow substitution maps to be serialized directly (via an ID), writing out
the replacement types and conformances as appropriate. This is a more
efficient form of serialization than the current SubstitutionList approach,
because it maintains uniqueness of substitution maps within a module file,
and is a step toward eliminating SubstitutionList entirely.
Prepare for SubstitutionMaps to be stored in other AST nodes by making
them ASTContext-allocated and uniqued (via a FoldingSet). They are now
cheap to copy and have trivial destructors.
Collapse the out-of-line array of replacement types and the DenseMap used
for conformances into a single field that references out-of-line,
tail-allocated storage for all of the contents of a SubstitutionMap.
The conformances are now represented as a flat array whose indices
line up with the indices of the conformance requirements in the
underlying generic signtature.
Reference this storage via a single shared_ptr, so that copies of
SubstitutionMaps are cheap but we aren't (yet) uniqueing them or
storing them within the ASTContext.
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.
At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
This will allow key paths to resiliently reference public properties from other binaries by referencing a descriptor vended by the originating binary. NFC yet, this just provides printing/parsing/verification of the new component.
The replacement types in a SubstitutionMap correspond with the generic
parameters of its generic signature, so replace the DenseMap storage
with a flat array of Types, one element for each generic parameter.
SubstitutionMap::lookupConformance() would map archetypes out
of context to compute a conformance path. Do the same thing
in SubstitutionMap::lookupSubstitution().
The DenseMap of replacement types in a SubstitutionMap now
always has GenericTypeParamTypes as keys.
This simplifies some code and brings us one step closer to
a more efficient representation of SubstitutionMaps.
When looking for a conformance for an archetype, map it out of context
to compute the conformance access path, then do the actual lookups
based on mapping the starting type back into the context. Eliminate
the parent map and "walk the conformances" functionality.
Substitution maps are effectively tied to a particular generic
signature or environment; keep track of that signature/environment so
that we can (eventually) use it to find conformances.
Make the addSubstitution() and addConformance() methods private,
and declare GenericEnvironment and GenericSignature as friends of
SubstitutionMap.
At some point in the future, we can switch to a more efficient
representation of SubstitutionMap, where instead of storing
multiple hashtables, we store arrays; the keys are pre-determined.
A new SubstitutionMap::getProtocolSubstitutions() method handles
the case where we construct a trivial SubstitutionMap to replace
the protocol Self type with a concrete type.
When substituting one opened existential archetype for another,
use the form of Type::subst() that takes two callbacks instead of
building a SubstitutionMap. SubstitutionMaps are intended to be
used with keys that either come from a GenericSignature or a
GenericEnvironment, so using them to replace opened archetypes
doesn't fit the conceptual model we're going for.
In several places, we construct a SubstitutionMap by taking
generic parameters from one SubstitutionMap up to a certain
depth, with the rest coming from a second SubstitutionMap.
Factor this out into a new utility method, to help with
hiding the internal representation of SubstitutionMap from
clients.
This was meant to be NFC, but it actually fixes a crash in
the devirtualizer, because the old logic there was slightly
wrong, so I added a test for this.
