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
The central thrust of this patch is to get these metadata initializations
off of `swift_once` and onto the metadata-request system where we can
properly detect and resolve dependencies. We do this by first introducing
runtime support for resolving metadata requests for "in-place"
initializations (committed previously) and then teaching IRGen to actually
generate code to use them (this patch).
A non-trivial amount of this patch is just renaming and refactoring some of
existing infrastructure that was being used for in-place initializations to
try to avoid unnecessary confusion.
The remaining cases that are still using `swift_once` resolution of
metadata initialization are:
- non-generic classes that can't statically fill their superclass or
have resilient internal layout
- foreign type metadata
Classes require more work because I'd like to switch at least the
resilient-superclass case over to using a pattern much more like what
we do with generic class instantiation. That is, I'd like in-place
initialization to be reserved for classes that actually don't need
relocation.
Foreign metadata should also be updated to the request/dependency scheme
before we declare ABI stability. I'm not sure why foreign metadata
would ever require a type to be resolved, but let's assume it's possible.
Fixes part of SR-7876.
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
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
When mangling a specialized use of a typealias in a protocol, we end up
with a "bound generic protocol" mangling, with the one substitution
replacing Self with some other type. Handle de-mangling and
re-mangling of such names.
Fixes rdar://problem/41549126.
The mangling of generic typealiases was using the underlying type’s generic
arguments rather than the generic arguments for the typealias itself.
Directly encode the generic arguments from the substitution map instead.
Also address some related issues with remangling generic typealiases.
Fixes rdar://problem/41444286.
Protocol name mangling didn’t always go through a path that allowed the use
of standard substitutions. Enable standard substitutions for protocol name
manglings where they make sense.
Removes ~277k from the standard library binary size.
LLVM r334283 changed StringRef::split(char) to be implemented using
StringRef::split(StringRef), which is not defined inline. Because Swift
uses StringRef without linking LLVM's libSupport.a, we can only use
functions that are defined inline in the headers. Swift currently only
builds LLVM for the host, so we cannot link libSupport.a without building
it for every target, which would be a big change. Instead, this changes
a few places in Swift to avoid using those split and rsplit functions.
rdar://problem/41029268
Support demangling for types nested within some simple extension contexts.
Still does not support nested types within constrained extensions that
involve same-type constraints among generic parameters, nor
deeply-nested types in extensions. However, it fixes
rdar://problem/40071688.
Previously we could only handle symbolic references at the
top level, but this is insufficient; for example, you can
have a nested type X.Y where X is defined in the current
translation unit and Y is defined in an extension of X in
a different translation unit. In this case, X.Y mangles as
a tree where the child contains a symbolic reference to X.
Handle this by adding a new form of Demangle::mangleNode()
which takes a callback for resolving symbolic references.
Fixes <rdar://problem/39613190>.
Carve out the C0 control code space as symbolic reference introducers—U+0001 through U+0017 as relative symbolic references, and U+0018 through U+001F as absolute symbolic references (if we ever need them).
Witness tables for conformances that require runtime instantiation
should not be public, because it is an error to directly reference
such a symbol from outside the module.
Use a different mangling for witness table patterns and give them
non-public linkage.
Emit enum copy/destroy methods only when codegen demands them; they previously got emitted immediately when TypeInfo is instantiated, which led to many functions getting emitted that were never used. Also, make it so that the symbol name includes the full type of the enum instance the outlined functions operate on, so it's more obvious what they'e being used for and they can be ODRed across translation units.
