This commit adds a new type DynamicLookupInfo that provides information
about how a dynamic member lookup found a particular Decl. This is
needed to correctly handle KeyPath dynamic member lookups, but for now
just plumb it through everywhere.
When we formed a mangled name key to look up opaque return type decls during
interface parsing, we were accidentally including the `Global` demangle node
inside the `OpaqueReturnTypeOf` node, which ended up including the `$s` prefix
in the mangling. Other type reconstruction clients like lldb which provided
well-formed mangling trees did not include the Global node, causing the prefix
to get left off and lookups to fail. Fix Sema to remove the Global node before
looking up the opaque type, and have type reconstruction consistently apply the
prefix to the lookup key.
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 is done by disallowing nodes with children to also have index or text payloads.
In some cases those payloads were not needed anyway, because the information can be derived later.
In other cases the fix was to insert an additional child node with the index/text payload.
Also, implement single or double children as "inline" children, which avoids needing a separate node vector for children.
All this reduces the needed size for node trees by over 2x.
For some reason, findDeclContext() finds the special ClangImporter
module from inside lldb, and then we were skipping the logic in
findForeignTypeDecl(). So check for the foreign type case first.
MetadataLookup gives special treatment to imported Objective-C classes,
since there's no nominal type descriptor and metadata is obtained
directly by calling into the Objective-C runtime.
Remote reflection also gives special treatment to imported Objective-C
classes; they don't have field descriptors.
However, the ASTDemangler needs to treat them like ordinary classes,
in particular it wants to preserve the generic arguments here so that
we can round-trip debug info.
Translate the metadata for the generic requirements of an extension context
into a demangle tree that is associated with the demangling of an extension.
Teach the ASTDemangler how to handle class layout constraints as well.
With this, RemoteAST can resolve types nested within most constrained
extensions.
Debug info uses a special mangling where type aliases can be
represented without being desugared; attempt to reconstruct
the TypeAliasType in this case.
It's clever how it leverages the type checker to check generic arguments,
but calling checkGenericArguments() would have been simpler, and it doesn't
work for interface types anyway, so we would fail to demangle those.
Let's just cut this all out for now and build a BoundGenericType directly.
When an enum is imported as an error, the imported type itself becomes
a nested type 'Code' of its wrapper type, so you get a type like
'MyError.Code'. However in the mangling grammar the type is a
child of a module and not another type.
This was tripping up TypeDecoder, which would check parent types for
validity and throw out the demangling since it looked invalid.
However since this case really is valid, just skip the whole parent
type mess when the type is imported and non-generic.
