A follow-up PR adds a flag to control an inline namespace that allows
symbols in libDemangling to be distinguished between the runtime and
the compiler. These dependencies ensure that the flag is plumbed
through for inclusions of Demangling headers that aren't already
covered by existing `target_link_libraries`.
Pointer data in some remote reflection targets may required relocation, or may not be
fully resolvable, such as when we're dumping info from a single image on disk that
references other dynamic libraries. Add a `RemoteAbsolutePointer` type that can hold a
symbol, offset, or combination of both, and add APIs to `MemoryReader` and `MetadataReader`
for reading pointers that can get unresolved relocation info from an image, or apply
relocations to pointer information. MetadataReader can use the symbol name information to
fill in demanglings of symbolic-reference-bearing mangled names by using the information
from the symbol name to fill in the name even though the context descriptors are not
available.
For now, this is NFC (MemoryReader::resolvePointer just forwards the pointer data), but
lays the groundwork for implementation of relocation in ObjectMemoryReader.
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
The getDynamicTypeAndAddressForExistential() function takes the
address of an existential value; so when looking at an Error,
this is the address of the reference, not the address of the
instance.
lldb needs to look at Error instances too, so add a new entry
point named getDynamicTypeAndAddressForError() which avoids the
extra dereference.
This will be tested on the lldb side.
LLDB calls getDynamicTypeAndAddressForExistential() on an existential
value without knowing if its a class existential or opaque existential.
Class existentials return the address of the instance itself here,
whereas opaque existentials always returned the address of the
payload value.
This meant the caller could not usefully operate on the payload value
if it was of class type, because there was no way of knowing if the
extra dereference had occurred or not.
Now, always load the reference if the wrapped type is a class, even
if the existential is opaque.
Will be tested on the lldb side with another change I'm working on.
An Error existential value can directly store a
reference to an NSError instance without wrapping
it in an Error container.
When "projecting" such an existential, the dynamic type
is the NSError's isa pointer, and the payload is the
address of the instance itself.
Debug info uses a special mangling where type aliases can be
represented without being desugared; attempt to reconstruct
the TypeAliasType in this case.
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
Right now we expect that every class and protocol has a field
descriptor that tells us if the entity is @objc or not.
For imported types, the descriptor will not exist if we did not
directly emit a field whose concrete type contains the imported
type. For example, in lldb, we might have a generic type whose
runtime substituted type includes an imported type.
In this case, TypeLowering would fail to produce a layout because
it did not find a field descriptor for the imported type.
A better approach is to have the TypeDecoder call a different
factory method for imported types, and handle them specially in
TypeLowering, bypassing the field type metadata altogether.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
Add `@autoclosure` to parameter flags associated with
function type metadata, which makes it possible to correctly
round-trip mangled name <-> metadata of function types which
have parameters marked as `@autoclosure`.
Resolves: rdar://problem/45489901
- 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.
Clang-importer-synthesized declarations get an extra tag character included in their mangling, which was not being preserved in type context descriptors. This caused runtime lookup for these synthesized types to fail. Fix this by adding the tag information to type context descriptors and teaching the runtime to match it up when fetching metadata by mangled name. Fixes rdar://problem/40878715.
This reverts commit 30ea6ec66c.
LLDB is smarter than I expected it to be. One of the failing tests
"metatype" is very short and does not import any modules
whatsoever. It turns out that swift_runtime->GetMetadataPromise()
creates a RemoteAST with the Scratch AST context. LLDB does not
pre-import any modules for the scratch AST context.
Using the scratch context is actually the behavior we'd want for all
kinds of dynamic type resolution, since we need to handle the
worst-case dynamic type (a tuple of existentials that each originate
from different modules that don't import each other) gracefully.
So what I'm going to try next is revert the RemoteAST change and try
to get the dynamic type resolution in this case to use the scratch AST
context instead of the per-module AST context.
I'm still going to add a flag to RemoteAST to indicate wether
importing other modules should be allowed or not and set that
according to whether this is a module context or the scratch context.
LLDB uses RemoteAST for its per-module SwiftASTContext. Importing
external modules here could permanently damage this context, for
example when a Clang import fails because of missing header search
options. To avoid this situation, restrict RemoteAST's access to only
the module's transitive closure of imports.
Triggering this situation needs two independent Swift compilation
units. An accompanying testcase (Swift/RemoteASTImport.test) has been
added to LLDB.
rdar://problem/40950542
When running Swift from within LLDB, we need to bypass resilience since LLDB
does not support resilience yet. However, the bypass was done too early as
part of the module loader, which had the effect of disabling resilience
altogether.
We still want resilience at the SIL level so that function types lower the
same with debugger support turned on and off. Only IRGen needs to bypass
resilience, so that LLDB can calculate fragile layouts of types. Also, the
DebuggerSupport flag is not always set in the ASTContexts created by LLDB.
So replace it with a new flag that only controls this behavior and nothing
else, and make it part of IRGenOptions to make it totally clear that it only
impacts IRGen.
Together with the paired LLDB change, fixes <rdar://problem/38719739>
and <rdar://problem/38483762>.
