When building the runtime we define `SWIFT_RUNTIME`. `swiftCore_EXPORTS`
is only defined when building swiftCore as a shared library. This would
thus allow the ODR violations to appear in a static library form of the
standard library. This was uncovered with the new runtime build system.
Expose a `Task`'s resume context via the `AsyncTaskInfo` struct.
This will be used by lldb, but since this data is not specific to lldb it seems reasonable to include it generally.
This change is part of a fix for a regression that wasn't noticed because lldb has a
fallback to using ASTContexts when type metadata resolution fails.
For any Swift class that directly or indirectly inherits from an ObjC class (such as
`NSObject`, `NSView`, etc), the function `computeUnalignedFieldStartOffset` will fail
to compute the start offset. To compute the start offset, it traverses the parent
classes and uses their sizes. Once the traversal reaches an ObjC class, the
RemoteInspection does not know the size. The fix here is to get the size from the
`TypeInfo` returned by the external `TypeInfoProvider` (which in LLDB is
`LLDBTypeInforProvider`).
Depended on by https://github.com/swiftlang/llvm-project/pull/9320
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
UnsafeContinuations can be stored in variables or properties,
so it's important for RemoteMirror to be able to at least minimally
recognize them.
This just treats an UnsafeContinuation as a refcounted pointer.
Which might be "good enough" for now.
Working towards rdar://110351406
Makes sure that invalid runtime type strings result in errors and not fail silently.
In worst case this could lead to wrong reconstructed metatypes which can result in all kind of memory corruption.
relates to rdar://129861211
I'm working to fully remove this method, but because it's
used and/or implemented in a few places, I'm backing it out
incrementally. This just changes the abstract method so I can
delete the implementors in a subsequent PR without breaking
anything.
without relying on spare bit information in the reflection metadata
(which was added in #40906). As a result, we can remove the
code from #40906.
This is the first step in such removal. It removes the RemoteMirror
code for looking up such metadata. It leaves behind:
* Sufficient stubs for LLDB to continue to build. Once LLDB is updated, these stubs can be removed as well.
* The compiler code to emit such metadata. This allows new binaries to still reflect MPEs on older runtimes. This will need to be kept for a transitional period.
MPE layout code to exclusively use the new code. The key observation: existing
reflection metadata seems to already provide enough information in all cases, so
we can abandon an earlier effort to add spare bitmask data.
Resolves rdar://129281368
No metadata is emitted for the builtin DefaultActorStorage type. Since
its layout is fixed, hardcode its definition in Remote Mirrors.
rdar://128032250
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
Pass in a TypeInfoProvider parameter to computeUnalignedFieldStartOffset
because it calls getClassInstanceTypeInfo which might need the external
type info provider to find clang types.
rdar://128141491
This adds a `getSpareBits` method to all the TypeInfo classes
that returns a suitable bitmask indicating the spare bits available
in values of this type. This gives us a way to recursively explore
the type tree and build up a full spare bit mask for an arbitrary type.
Happily, it appears we actually do have enough information to do this
calculation entirely from first principles, without requiring additional
reflection information. So once this is stable, we should remove my
earlier incomplete effort to publish spare bit mask info in the reflection
data, as that adds unnecessary metadata to every binary.
This doubtless still has plenty of holes, but seems sufficient
to handle a few basic enum types, including the stdlib DecodingError
which was used as an example to work out some key issues.
There are a number of instances in `ReflectionContext.h` where we
are doing `return false` with an `std::optional<...>` where it seems
we really mean to return an empty optional instead.
(The way to do this is either `return {}` or `return std::nullopt`.)
rdar://123504095
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
