When printing a swiftinterface, represent opaque result types using an attribute that refers to
the mangled name of the defining decl for the opaque type. To turn this back into a reference
to the right decl's implicit OpaqueTypeDecl, use type reconstruction. Since type reconstruction
doesn't normally concern itself with non-type decls, set up a lookup table in SourceFiles and
ModuleFiles to let us handle the mapping from mangled name to opaque type decl in type
reconstruction.
(Since we're invoking type reconstruction during type checking, when the module hasn't yet been
fully validated, we need to plumb a LazyResolver into the ASTBuilder in an unsightly way. Maybe
there's a better way to do this... Longer term, at least, this surface design gives space for
doing things more the right way--a more request-ified decl validator ought to be able to naturally
lazily service this request without the LazyResolver reference, and if type reconstruction in
the future learns how to reconstruct non-type decls, then the lookup tables can go away.)
Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
This was partially implemented but the check looked at the lowered
types and not the AST types, and DynamicSelfType is erased at the
top level of a lowered type.
Also use the new mangling for reabstraction thunks with self, to
ensure we don't emit the same symbol with two different lowered
types.
Fixes <https://bugs.swift.org/browse/SR-10309>, <rdar://problem/49703441>.
For now, this means USRs of ParamDecls. Soon, default argument generators
for subscripts will need this too.
Fixes <https://bugs.swift.org/browse/SR-8660>, <rdar://problem/44435221>.
When emitting metadata for a Swift-defined @objc protocol that has
provided a specific Objective-C name (e.g., via @objc(renamed)),
mangle such protocols using their Objective-C names so they can be
found at runtime.
Only do this for metadata, because doing it anywhere else would cause
an ABI break. Fixes rdar://problem/47877748.
Add an IRGen flag to disable this verification, since it doesn't work from within
lldb itself for some reason, and I don't want to investigate it right now.
Swift.UnicodeScalar is a typealias now, and for the TypeDecoder
to work correctly we need to mangle it as a typealias and not as
a struct.
However, we still want to demangle old names that used the
substitution, so don't remove it, instead just skip checking for
a substitution when mangling a typealias.
This does not change the ABI; typealiases are only mangled as
part of debug info.
New(er) grammar:
// same module as conforming type, or non-unique
protocol-conformance-ref ::= protocol 'HP'
// same module as protocol
protocol-conformance-ref ::= protocol 'Hp'
// retroactive
protocol-conformance-ref ::= protocol module
We don't make use of this distinction anywhere yet, but we could in
the future.
Previously, the mangler searched for retroactive conformances in /any/
of a generic type's substitutions, but really we only care about the
ones that affect the generic type's conformance, i.e. those that
affect generic parameters. Refining this results in shorter mangled
names involving instantiations of generic types.
Follow-up work for rdar://problem/46735592
Fix to 510b64fcd5. The mangling operator "HP" has to distinguish
between "protocol" and "protocol module", not between the presence
or absence of protocol-conformance-ref. New grammar:
protocol-conformance-ref ::= protocol
protocol-conformance-ref ::= protocol module 'HP'
rdar://problem/46735592, again
Due to some unfortunate refactoring, protocol-conformance-ref is a
nonterminal in the mangling grammar that doesn't have its own
operator:
```
protocol-conformance-ref ::= protocol module?
```
Both "module" and "protocol" can be an "identifier", which introduces
a mangling collision. Address the mangling collision by using the
operator "HP".
Fixes rdar://problem/46735592.
Context archetypes and opened existential archetypes differ in a number of details, and this simplifies the overlapping storage of the kind-specific fields. This should be NFC; for now, this doesn't change the interface of ArchetypeType, but should allow some refinements of how the special handling of certain archetypes are handled.
GenericParamList::OuterParameters would mirror the nesting structure
of generic DeclContexts. This resulted in redundant code and caused
unnecessary complications for extensions and protocols, whose
GenericParamLists are constructed after parse time.
Instead, lets only use OuterParameters to link together the multiple
parameter lists of a single extension, or parameter lists in SIL
functions.
While declaration mangling now does the right thing for parameter lists,
the function type mangling unfortunately still models the parameter list
as a single tuple node.
Change the runtime's behavior to match the AST mangler, which wraps
a single tuple-typed parameter in a tuple node, so that we can produce
different mangling trees for function types taking multiple arguments
versus a single tuple argument.
Instead of trying to mangle a tuple type.
This change avoids mangling tuple element names in case a field type is a tuple with named elements.
Fixes a "can't demangle" crash in the closure specializer.
This mangling is only used for specializations, so no ABI effect.
rdar://problem/46380088
When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
LibraryEvolution.rst stipulates that adding or removing 'weak',
'unowned' and 'unowned(unsafe)' is a resilient change if the type
is resilient. This means we should not mangle these attributes as
part of the accessor declaration.
The mangling AST cannot represent this, and we were incorrectly
pulling generic arguments from the type alias type. Instead let's
just desugar the parent type when mangling a nominal type.
Fixes <rdar://problem/45900947>.
The `isSpecialized()` check didn’t account for the possibility that a
typealias in a parent of a nominal type could be non-generic when the
parent declaration was generic, leading to incorrect mangling that stated
that they were generic but had no generic arguments.
Fixes SR-8930 / rdar://problem/45216653 and rdar://problem/45813164.
Change the retroactive conformance mangling to use the new
any-protocol-conformance mangling, which maintains more information about
concrete conformances. Specifically, it maintains conformance information
for conditional requirements. It also uses the protocol-conformance-ref
production that will eventually allow symbolic references to protocol
conformance descriptors.
While here, extend the “is retroactive” check during mangling to look for
retroactive conformances in the conditional requirements of a conformance.
The immediate conformance might not be retroactive, but its specialization
might depend on a retroactive conformance. Mangle these as “retroactive”, so
we can correctly reconstruct the exact type.
Introduce complete mangling for references to protocol conformances:
* Mangle requirements of conditional conformances when present.
* Mangle conformance access paths for generic environment-dependent
conformances.
* Abstract protocol conformance references so we can introduce
symbolic references for them.
We were strangely excluding protocols from being symbolically referenced
in the any-generic-type production, which meant that we could not resolve
(e.g.) associated type references to private protocols at runtime. Allow
protocol symbolic references in this position, and cope with it in the
demangler.
Fixes the rest of rdar://problem/44977236.
Extending the mangling of symbolic references to also include indirect
symbolic references. This allows mangled names to refer to context
descriptors (both type and protocol) not in the current source file.
For now, only permit indirect symbolic references within the current module,
because remote mirrors (among other things) is unable to handle relocations.
Co-authored-by: Joe Groff <jgroff@apple.com>
