There was a bunch of logic to lazily populate replacement types
corresponding to reducible generic parameters. This didn't seem
to have a clear purpose so let's remove it.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
There are a lot of problems caused by our highly-abstract substitution
subsystem. Most of them would be solved by a more semantic / holistic
understanding of the active transformation, but that's difficult to do
because we just pass around function_refs. The first step in fixing
that is to pass around a better currency type. For now, it can just
hold the function_refs (and the SubstOptions).
I've set it up so that the places that just apply SubstitutionMaps
are constructing the IFS in a standard way; that should make it easy
to change those places in the future.
I had a fix a bunch of bugs in this, which isn't very surprising.
I changed remapSubstitutionMap to preserve the non-canonical signature
of the substitutions because otherwise it messes up printing
open_pack_element pretty badly --- we end up printing a sugared shape
class but a desugared generic signature. I'd rather not eagerly
canonicalize everything there because the sugar is quite nice.
Still, I don't feel great about this approach, and this is the
second time I've found myself doing something a little gross in order
to preserve sugar for printing this instruction.
Canonicalizing the replacement types is important for test stability,
and I think it's good downstream.
The most interesting part of this is that I implemented a rule which
handles tuple types becoming scalar as part of the substitution of
tuple_pack_element_addr. We talked about having this rule in the
formal type system, and I thought we were going to do it, but it
looks like we haven't actually implemented that yet. I added it to
SIL substitution because (1) I anticipate we'll be doing this
eventually in the formal type system, and that will have consequences
for SIL, and (2) we don't actually have a way to parse these singleton
tuple types, and I didn't want expanding singleton packs into tuples
to become this weird untestable corner case. I did have to poke a
hole in this rule to preserve types that were singleton tuples before
substitution, since apparently AutoDiff makes a lot of those.
I think adding a type_refine_addr that statically asserts a type
match is the right way to go in the long term for rewriting
singleton tuple_pack_element_addr, but I'm a little sick of adding
SIL instructions, so we just rewrite to unchecked_addr_cast for now.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
ProtocolConformanceRef already has an invalid state. Drop all of the
uses of Optional<ProtocolConformanceRef> and just use
ProtocolConformanceRef::forInvalid() to represent it. Mechanically
translate all of the callers and callsites to use this new
representation.
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
We've fixed a number of bugs recently where callers did not expect
to get a null Type out of subst(). This occurs particularly often
in SourceKit, where the input AST is often invalid and the types
resulting from substitution are mostly used for display.
Let's fix all these potential problems in one fell swoop by changing
subst() to always return a Type, possibly one containing ErrorTypes.
Only a couple of places depended on the old behavior, and they were
easy enough to change from checking for a null Type to checking if
the result responds with true to hasError().
Also while we're at it, simplify a few call sites of subst().
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.
