A follow-up to #85180.
First, make the guarantee that our Swift-native implementation of
integer-to-ASCII conversion always fills the _suffix_ of the given
mutable span.
(Some minor swift-format corrections interspersed.)
Then, use that guarantee to work in 64-bit (or rather, for most bases,
56-bit) chunks for larger integers.
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
Refactoring to allow override on the hard coded image
paths in crash logs. To allow cross platform
offline symbolication.
Co-authored-by: Carl Peto <carlpeto@Carls-MacBook-Pro.local>
Co-authored-by: Alastair Houghton <alastair@alastairs-place.net>
This replaces #87114, aligning the `BorrowingSequence` protocols and
related types to the Swift Evolution proposal, and without included
reparenting of `Sequence`.
Due to unfortunate structure packing rules in C, `struct pe_symbol` ends up
being 20 bytes instead of 18. The upshot is that when presented with a PE-COFF
binary that contains symbols (noting that this is actually a spec violation),
the backtracer will crash.
Unfortunately we often generate such binaries. We shouldn’t crash, though, and
the fix is to get the correct size for `struct pe_symbol`.
rdar://171711254
The new library, swiftEmbeddedPlatformPOSIX, implements all of the
_swift_XYZ functions needed to support Embedded Swift as shims on top
of a POSIX system that provides posix_memalign, free, putchar, and so
on. This offers an easier way to bridge between the prior ad hoc
requirements of Embedded Swift and the newer platform abstraction
layer.
Part of rdar://164057124
Embedded Swift depends on a number of functions from the platform,
including posix_memalign, free, and arc4random_buf. While these
dependencies are documented, they aren't documented in a manner that
makes them easy to implement. Additionally, most of these are C
library functions that may or may not be available, and can have
requirements that are more stringent than Embedded Swift actually
requires.
Try to address both problems at once by introducing a new header,
`swift/EmbeddedPlatform.h`, that provides a new set of C declarations
for functions that need to be provided by a platform. For
each function, we provide documentation on what it does, what Embedded
Swift facilities will end up using it (e.g.,
`_swift_generateRandomHashSeed` is needed for seeding the hash
functions used for `Set` and `Dictionary`, among other things), and
some guidance on how to implement it---including those cases where
directly calling an existing C standard library or POSIX function will
suffice.
There is a new CMake option, SWIFT_USE_SWIFT_EMBEDDED_PLATFORM, that
enables the use of these entrypoints in the Embedded Swift runtime. It
is currently disabled, because enabling it would break existing
clients of Embedded Swift. We're looking for a way to stage this in.
Addresses rdar://164057124.
Now that `SwiftStdlib` availability has an empty expansion during embedded
builds, it's no longer necessary to guard `@backDeployed` attributes since they
are automatically removed by the empty expansion.
Declarations in the standard libraries are should generally not be availability
gated at all since all Swift declarations and runtime code are statically
inlined into the built executable. Specifying empty availability macros during
the embedded build suppresses superfluous warnings about unneeded availability
checks and also just generally cleans up unnecessary annotations on
declarations.
The inlinable certainly wont hurt on these "forwarding" methods, though
I was not able to confirm a noticable difference at least using this
benchmark.
Since adding those is definitely good anyway, I didn't dig much further,
let's just add them.
Assisted by: claude to make the benchmark, manually verified all changes
ran benchmarks and checked results etc
This fixes compiler errors on Fedora 42 and similar distros.
`<cmath>` wasn't correctly listed in the modulemap that Swift injects into libstdc++.
rdar://152032606 / resolves https://github.com/swiftlang/swift/issues/81774
Because we guaranteed that one cannot access a distribted "remote"
instance's state via type system, we can allocate the instance much
smaller because we never access those user initialized fields.
This way a remote distributed actor reference is always 128 bytes, this
is because actors have special storage 12*8 bytes of PrivateData in
addition to the 16 bytes object header.
With this optimization, regardless how many fields an actor has, the
remote ref always is the same size.
resolves rdar://81825648
Used claude to generate a bunch of tests to check the sizes of actors
etc, I think this is correct (and getting it wrong totally just crashes
immediately anyway). Could use a review though, thank you!
cc @mikeash @xedin
Reorganise the thread locals for the backtracing code in the `Runtime` module so
that there’s only one set of them, with everything else hanging off that. This
also reduces code duplication and consumption of thread local variable space.
Fix the `DefaultSymbolLocator`’s shared instance to be thread local.
rdar://171432566
We need to keep this API for source compatibility, and it was brought
back in #86820 however it used wrong availability, we need this to be
5.1+ with backdeployment as it was before
resolves rdar://171011139
EnumTypeInfoBuilder will build FieldInfos of indirect enum payloads with
the TypeRef set to Builtin.NativeObject.
EnumTypeInfoBuilder has access to the typeref of the type behind the
pointer, which currently isn't saved anywhere.
RemoteInspection clients like LLDB have to re-query it, and read
metadata to find out what the type behind the reference it.
This patch adds a field to FieldInfo with the payload TypeRef, the
one behind the reference.
rdar://170684760
While currently we should not run into any lifetime issues with the
existing code the new version should make sure that the object on which
the spans depend will be kept alive for longer in case the function is
inlined.
Explicitly mark the dependency between the base pointer and the owner object.
Otherwise the owner object could be destroyed too early.
So far we got away with this because array semantic functions were not inlined in OSSA.
Fixes a miscompile.
...to build non Darwin targets.
These are needed when using the macOS SDK that ships in Xcode 26.4 beta
1 and later.
Resolves#87327
Addresses rdar://170506176
PUBLIC is a MASM directive and causes a build error in a certain version of MSVC
```
Microsoft (R) ARM Macro Assembler Version 14.44.35217.0 for 64 bits
Copyright (C) Microsoft Corporation. All rights reserved.
D:\r\_work\swift-build\swift-build\SourceCache\swift\stdlib\public\RuntimeModule\get-cpu-context-aarch64.asm(21) : error A2003: improper line syntax: PUBLIC
```
EXPORT is an ARMASM equivalent, which is already there.
- Remove spurious `unsafe` on non-unsafe calls in TaskCancellation.swift
and UnsafeCxxIterators.swift
- Change `var fd` to `let fd` in ImageSource.swift since it is never mutated
