This is a follow up patch that allows for external DescriptorFinders to
provide MultiPayloadEnumDescriptors (this is done to support embedded
Swift debugging, which encodes the equivalent of Swift metadata as
DWARF).
This includes runtime support for instantiating transferring param/result in
function types. This is especially important since that is how we instantiate
function types like: typealias Fn = (transferring X) -> ().
rdar://123118061
This change is analogous to the TypeInfo cache in TypeLowering, which does the
exact same thing. In LLDB the ExternalTypeInfoProvider may gain new information
throughout the life of a process, and more importantly, it may return
context-dependent results.
rdar://122432501
Implement computeUnalignedFieldStartOffset as an alternative way to
finding out the start of the fields that belong to the instance when
reading the field's start from binary is not possible (for example,
embedded Swift doesn't emit any reflection metadata on the binary).
Not quite NFC because apparently the representation bleeds into what's
accepted in some situations where we're supposed to be warning about
conflicts and then making an arbitrary choice. But what we're doing
is nonsense, so we definitely need to break behavior here.
This is setting up for isolated(any) and isolated(caller). I tried
to keep that out of the patch as much as possible, though.
This library uses GenericMetadataBuilder with a ReaderWriter that can read data and resolve pointers from MachO files, and emit a JSON representation of a dylib containing the built metadata.
We use LLVM's binary file readers to parse the MachO files and resolve fixups so we can follow pointers. This code is somewhat MachO specific, but could be generalized to other formats that LLVM supports.
rdar://116592577
- Remove `std::` from `std::size_t` where we're importing `stddef.h`
instead of `cstddef`.
- Add an inclusion of `<cstdlib>` where needed because libc++ has
cleaned up some of their transitive inclusions.
Currently, TypeRefBuilder knows how to parse type descriptors from
reflection metadata. We aim to store the same information that lives
in type descriptors externally, as an effort to support embedded Swift
debugging. In order to take advantage of all of the existing type
information parsing code that exists today in remote mirrors, add an
interface for external lookup of type descriptors, and replace all the
usages of type descriptors with their generic counterpart (this patch
only adds support for builtin descriptors, but follow up patches will
add support for other descriptor types).
In C++20, the compiler will synthesize a version of the operator
with its arguments reversed to ease commutativity. This reversed
version is ambiguous with the hand-written operator when the
argument is const but `this` isn't.
The more awkward setup with pushGenericParams()/popGenericParams()
is required so that when demangling requirements and field types
we get the correct pack-ness for each type parameter. The pack-ness
is encoded as part of the generic signature, and not as part of
the type parameter mangling itself.
Fixes the ASTDemangler issue from rdar://problem/115459973.
This patch fixes the location of the llvm remote inspection headers for
MSVC header lookup. MSVC appears to search in the directory of the
current header before returning to the specified header search
directories. When building SwiftRemoteMirror, the file contains a
reference to `swift/RemoteInspection/ReflectionContext.h`. Under
RelfectionContext.h, there is an include of "llvm/BinaryFormat/COFF.h".
Because there is an `llvm` and `llvm-c` directory inside of
`swift/RemoteInspection/`, and `ReflectionContext.h` is in that
directory, MSVC is expanding the `COFF.h` inside of the
RemoteInspection headers instead of the copy in LLVM itself, resulting
in eventually finding usages of `countPopulation` instead of using the
new `llvm::popcount` API, ultimately resulting in a build failure.
The fix is to ensure that the `llvm` header directory does not live
immediately next to the headers in RemoteInspection, but instead offset
them by one. The LLVM headers copied into RemoteInspection are supposed
to be used when compiling the runtime libraries, so I chose the name
"RuntimeHeaders".
Separately track text and data segments for ownsAddress. We were previously tracking one range per image, encompassing the range from the start of the image through the end of the data segment. This ends up including a lot of unwanted address space if the two aren't adjacent, as is the case for libraries in the shared cache on Darwin.
This makes metadataIsActor a lot more reliable, as it was previously identifying a lot of garbage as actor metadata due to the supposed descriptor pointer falling in this range.
rdar://113417637
We don't want to directly include headers from the LLVM project, since they may change. Copy them locally and refer to them there instead.
rdar://112982181
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
ReflectionContext::allocationMetadataPointer() was reading the
metadata pointer from a wrong offset because of the out-of-sync struct
layouts and dump-generic-metadata was not working correctly.
This change resync's the layouts and adds a static_assert to verify
that the offsets match between GenericMetadataCacheEntry and
GenericCacheEntry.
Handle the top node directly in `createBoundGenericType`
so that we can be sure to always include it regardless
of whether it has direct generic type params or not.
The helper function can now focus only on handling
parents (where we must only include ones that actually
contain generic type params). This separates the two
different cases and makes it a little easier to follow.
I refactored `reconstructParentsOfBoundGenericType` to
be iterative rather than recursive, though I'm not sure that
really matters.
The recursive structure made it a little awkward to correctly
distinguish between the root node (which has to be included
regardless of whether it has direct generic params)
and the parent nodes (which must only be included if they
have direct params).
So I rewrote this to do a simple two-pass iteration:
* The first pass walks the parent list collecting candidates
* The second pass walks the list backwards, assigning generic params
We then just stack the start node onto the end of the
list regardless of whether it has generic params.
