The code to copy the refcounts from the object to a new side table wasn't quite right on 32-bit. Fix it to copy the PureSwiftDealloc field, and if the object is immortal, mark the side table's refcount as immortal too.
rdar://121943608
We run the builder, then use a small program that converts the JSON output into C code that generates the data. Compile that into a bundle, then load it as the prespecializations library. Then scan all the entries in the table and compare them with what the runtime builds dynamically.
Don't delete the OS declaration of `exit` because the concurrency shims aren't always imported, and so the shim declaration might not always be available.
Don't override the OS declaration of `exit` in the concurrency shims since we can't just delete the OS one. Instead, set up internal shims just for building Concurrency that forward declares `exit`.
This entails passing a linker flags to Apple linkers when the standard
library is not meant for inclusion in such cache.
For this to have effect on every library, propagate link flags when
building _Concurrency and Observation.
This is needed for Apple internal configurations.
Addresses rdar://120653968
Allow the use of typed throws for the main functions of `@main` types,
and thread the thrown error through to a new entry point in the library,
`_errorInMainTyped`, which is generic in the thrown error type.
Fixes rdar://121603043.
These triples don't need additional adjustments in the standard library and complement existing embedded triples for i686 and x86_64 CPU architectures.
This allows us to build swift-format with dynamic linking against the
toolchain build of the swift-syntax and swift-argument-parser packages.
Wire up the swift-markdown build and hoist the swift-format build prior
to sourcekit-lsp. This sets us up for supporting swift-format based
formatting in the LSP.
This PR changes the deprecation annotation of `String.init(validatingUTF8: [CChar])` to match that of `String.init(validatingUTF8: UnsafePointer<CChar>)`. Both have been given new, undeprecated, renamed replacements (`validatingCString:`).
Resolves rdar://121674502.
We were doing a linear scan of the table contents as a stopgap. Stop doing that, and compute the proper key for the lookup, matching the one used in the builder.
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.
Allow `AsyncSequence.flatMap` to be defined with "incorrect" availability,
meaning that the function can refer to the `Failure` associated type
in its where clause even though the function is back-deployed to
before the `Failure` associated type was introduced.
We believe this is safe, and that this notion can be generalized to any
use of an associated type in a same-type constraint of a function
(yes, it sounds weird), but for now introduce a narrower hack to see
how things work in practice and whether it addresses all of the
source-compatibility concerns we've uncovered.
Use an optional isolated parameter to this new `next(_:)` overload to
keep it on the same actor as the caller, and pass `#isolation` when
desugaring the async for..in loop. This keeps async iteration loops on
the same actor, allowing non-Sendable values to be used with many
async sequences.
`AsyncFlatMapSequence` is somewhat troublesome for typed throws,
because it can produce errors from two different sources: the `Base`
async sequence and the `SegmentOfResult` async sequence. However, we
need to pick one `Failure` type for the `AsyncFlatMapSequence`, and
there is no surface-language equivalent to the `errorUnion` operation
described in SE-0413.
So, we do something a little bit sneaky. We effectively require that
`SegmentOfResult.Failure` either be equivalent to `Base.Failure` or be
`Never`, such so that when the async sequence retruned by the closure
throws, it throws the same thing as the base sequence. Therefore, the
`Failure` type is defined to be `Base.Failure`.
This property isn't enforced at the type level, but instead in the
`AsyncSequence.flatMap` signatures: we replace the one signature that
returned `AsyncFlatMapSequence` with three overloads that differ only
in their generic requirements, adding:
1. `where SegmentOfResult.Failure == Failure`
2. `where SegmentOfResult.Failure == Never`
3. `where SegmentOfResult.Failure == Never, Failure == Never` (a
tiebreaker between the two above)
For cases where `SegmentOfResult.Failure` is neither `Never` nor
`Failure`, overloading will choose the `flatMap` function that returns
an `AsyncThrowingFlatMapSequence`. This can mean that existing code
will choose a different overload and get a different type, but other
than the type identity changing, the resulting sequence will behave
the same way.
