When linking with `gold`, we can end up with two separate sections
for each of the reflection sections; this happens because `swiftrt.o`
declares them with `SHF_GNU_RETAIN` set (to stop them from vanishing
when section GC is enabled), but if the compiler is set to allow the
reflection information to be stripped then *it* will generate them
*without* `SHF_GNU_RETAIN`.
The other Linux linkers will coalesce the two sections and leave the
`SHF_GNU_RETAIN` flag set, but `gold` does not, and adds both of them
separately to the output.
The upshot is that we want `ReflectionContext` to look for both the
retained and non-retained sections and read the data from both of
them.
rdar://123504095
We'd crash on a call to getKind(). Ignore them instead by returning false from isMetadataSourceReady. If this causes getClosureContextInfo to fail to make forward progress, then it will in turn fail and return nullptr to its caller.
rdar://126866747
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
This PR implements first set of changes required to support autodiff for coroutines. It mostly targeted to `_modify` accessors in standard library (and beyond), but overall implementation is quite generic.
There are some specifics of implementation and known limitations:
- Only `@yield_once` coroutines are naturally supported
- VJP is a coroutine itself: it yields the results *and* returns a pullback closure as a normal return. This allows us to capture values produced in resume part of a coroutine (this is required for defers and other cleanups / commits)
- Pullback is a coroutine, we assume that coroutine cannot abort and therefore we execute the original coroutine in reverse from return via yield and then back to the entry
- It seems there is no semantically sane way to support `_read` coroutines (as we will need to "accept" adjoints via yields), therefore only coroutines with inout yields are supported (`_modify` accessors). Pullbacks of such coroutines take adjoint buffer as input argument, yield this buffer (to accumulate adjoint values in the caller) and finally return the adjoints indirectly.
- Coroutines (as opposed to normal functions) are not first-class values: there is no AST type for them, one cannot e.g. store them into tuples, etc. So, everywhere where AST type is required, we have to hack around.
- As there is no AST type for coroutines, there is no way one could register custom derivative for coroutines. So far only compiler-produced derivatives are supported
- There are lots of common things wrt normal function apply's, but still there are subtle but important differences. I tried to organize the code to enable code reuse, still it was not always possible, so some code duplication could be seen
- The order of how pullback closures are produced in VJP is a bit different: for normal apply's VJP produces both value and pullback closure via a single nested VJP apply. This is not so anymore with coroutine VJP's: yielded values are produced at `begin_apply` site and pullback closure is available only from `end_apply`, so we need to track the order in which pullbacks are produced (and arrange consumption of the values accordingly – effectively delay them)
- On the way some complementary changes were required in e.g. mangler / demangler
This patch covers the generation of derivatives up to SIL level, however, it is not enough as codegen of `partial_apply` of a coroutine is completely broken. The fix for this will be submitted separately as it is not directly autodiff-related.
---------
Co-authored-by: Andrew Savonichev <andrew.savonichev@gmail.com>
Co-authored-by: Richard Wei <rxwei@apple.com>
Extend TypeDecoder with support for inverse requirements, passing them
along to the type builder. Then implement support for inverse
requirements within the AST demangler, which addresses the round-trip
demangling failures we've been seeing.
The runtime and remote inspection facilities still need metadata to
deal with inverse requirements.
Fixes rdar://124564447.
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
