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>
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
