Inspired by #84826, I've dusted off and completely reworked a native
implementation of integer-to-string conversion.
Besides existing tests in this repository, the core of the
implementation has been comprehensively tested in a separate package for
all bases between 2–36 to demonstrate identical output for all 8-bit and
16-bit values, and for randomly generated 32-bit, 64-bit, and 128-bit
values.
Resolves#51902.
<!--
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!
-->
To achieve this, add a new cache variable
`SWIFT_EMBEDDED_STDLIB_SDKS_FOR_TARGET_TRIPLES` to be set like in the
following examples.
```
-DSWIFT_EMBEDDED_STDLIB_SDKS_FOR_TARGET_TRIPLES=aarch64-vendor-os@/usr/local/aarch64-vendor-os-sdk;aaarch-vendor-anotheros@/opt/aarch64-vendor-anotheros-sdk
```
We chose to use another setting instead of e.g. folding this into
`SWIFT_EMBEDDED_STDLIB_EXTRA_TARGET_TRIPLES` so it is clear this is opt
in and it does not regress existing configurations that set the SDK
directly (like it's the case for the WASM stdlib).
Addresses rdar://162368529
Resolves the following warnings:
```
stdlib/public/SwiftShims/swift/shims/CoreFoundationShims.h:86:1: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
86 | const _swift_shims_NSUInteger
| ^~~~~
stdlib/public/stubs/FoundationHelpers.mm:110:1: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
110 | const _swift_shims_NSUInteger
| ^~~~~
```
This TODO has existed since the introduction of the Windows platform and
has not been addressed. The implementation at this point is well tested
in practice. Clean up the warning message and style and remove the
warning.
`stdint.h` should be picked up from `clang/lib/Headers`, but is instead
being picked up by the system libc++. There's no C++ stdlib being used
here, so just exclude it.
Resolves rdar://134584685.
- when compiling embedded cross compile target standard libraries, include AVR
- add 16-bit pointer as a conditional compilation condition and get the void pointer size right for gyb sources
- attempt to fix clang importer not importing __swift_intptr_t correctly on 16 bit platforms
- changed the unit test target to avr-none-none-elf to match the cmake build
[AVR] got the standard library compiling in a somewhat restricted form:
General
- updated the Embedded Runtime
- tweaked CTypes.swift to fix clang import on 16 bit platforms
Strings
- as discussed in https://forums.swift.org/t/stringguts-stringobject-internals-how-to-layout-on-16-bit-platforms/73130, I went for just using the same basic layout in 16 bit as 32 bit but with 16 bit pointers/ints... the conversation is ongoing, I think something more efficient is possible but at least this compiles and will probably work (inefficiently)
Unicode
- the huge arrays of unicode stuff in UnicodeStubs would not compile, so I skipped it for AVR for now.
Synchronization
- disabled building the Synchronization library on AVR for now. It's arguable if it adds value on this platform anyway.
This will avoid CMake configuration errors in `llvm_process_sources`
in configurations that build only the the standard library for embedded.
Addresses rdar://130229502
WebAssembly does not support _Float16 type, so we need to guard the use
of the type. Unfortunately, Clang does not provide a good way to detect
the support of _Float16 type at compile time, so just disable for wasm
targets.
We can easily test all 2**16 values, so let's do it. Also now _Float16 is properly supported in clang, so we can pass arguments to CPP that way, which lets us get snan right on more platforms.
We should always be using `<errno.h>`, not `<sys/errno.h>`. The
former is part of the C standard. The latter is a non-standard
header that happens to be present on some systems.
rdar://123507361
Static read-only arrays didn't work when passed to ObjectiveC as NSArray.
The storage class of static read-only arrays doesn't carry information about the Element type.
The new `__SwiftDeferredStaticNSArray` is generic over the element type and doesn't have to rely on the element type information of the array storage.
rdar://94185998
`_swift_stdlib_configure_console_mode` reverts console codepage on Windows using `atexit`, which is declared in `stdlib.h`.
Add the missing `#include <stdlib.h>` to unblock building Swift `stdlib` with MSVC v14.37 (Visual Studio 17.7).
The alias defined here with the `.set` directive doesn't actually define a symbolic alias
that the linker respects in all cases. The resulting standard library dylib _does_ contain a
reference to the aliased symbol with the correct value, but the resulting variable is not actually
considered relocatable by the linker. Thus, its value may not always get fixed up properly.
Work around this by dropping the alias for now - directly use the type metadata for Swift.__EmptyArrayStorage
instead.
rdar://100288247
