Extend SwiftDtoa to provide optimal formatting for Float16 and use that for `Float16.description` and `Float16.debugDescription`.
Notes on signaling NaNs: LLVM's Float16 support passes Float16s on x86
by legalizing to Float32. This works well for most purposes but incidentally
loses the signaling marker from any NaN (because it's a conversion as far
as the hardware is concerned), with a side effect that the print code never
actually sees a true sNaN. This is similar to what happens with Float and
Double on i386 backends. The earlier code here tried to detect sNaN in a
different way, but that approach isn't guaranteed to work so we decided to
make this code use the correct detection logic -- sNaN printing will just be
broken until we can get a better argument passing convention.
Resolves rdar://61414101
These should hopefully all be uncontroversial, minimal changes to deal
with progressing the build to completion on OpenBSD or addressing minor
portability issues. This is not the full set of changes to get a
successful build; other portability issues will be addressed in future
commits.
Most of this is just adding the relevant clauses to the ifdefs, but of
note in this commit:
* StdlibUnittest.swift: the default conditional in _getOSVersion assumes
an Apple platform, therefore the explicit conditional and the relevant
enums need filling out. The default conditional should be #error, but
we'll fix this in a different commit.
* tgmath.swift.gyb: inexplicably, OpenBSD is missing just lgammal_r.
Tests are updated correspondingly.
* ThreadLocalStorage.h: we use the pthread implementation, so it
seems we should typedef __swift_thread_key_t as pthread_key_t.
However, that's also a tweak for another commit.
To make it possible to change the implementation of
_stdlib_isOSVersionAtLeast(), remove the @inlinable attribute from it.
Since it is currently inlinable and calls the helper function
_swift_stdlib_operatingSystemVersion(), we’ll have to keep the
helper around as ABI.
This change causes a minor pessimization where the LLVM optimizer can no
longer reason that, for example, a successful check for 10.12 availability
means that a later check for 10.11 will always succeed. I don't expect this
pessimization to be a problem, but if needed we could write a custom SIL
optimizer pass to claw back the performance.
<rdar://problem/59447474>
It is causing bots to fail.
* Revert "The __has_include(<os/system_version.h>) branch here wasn't quite right, we'll just use the dlsym one for now"
This reverts commit f824922456.
* Revert "Remove stdlib and runtime dependencies on Foundation and CF"
This reverts commit 3fe46e3f16.
rdar://54709269
Use the wrapper for the CC adjustment as on Windows x86, the destructor
needs to be `__stdcall`. This would fail otherwise with the following:
```
D:\a\1\s\swift\stdlib\public\stubs\ThreadLocalStorage.cpp(86,18): error: no matching function for call to '_stdlib_thread_key_create'
int result = SWIFT_THREAD_KEY_CREATE(&key, [](void *pointer) {
^~~~~~~~~~~~~~~~~~~~~~~
D:\a\1\s\swift\stdlib\public\stubs/../runtime/ThreadLocalStorage.h(96,35): note: expanded from macro 'SWIFT_THREAD_KEY_CREATE'
^~~~~~~~~~~~~~~~~~~~~~~~~
D:\a\1\s\swift\include\swift/Basic/Lazy.h(42,27): note: expanded from macro 'SWIFT_ONCE_F'
::std::call_once(TOKEN, FUNC, CONTEXT)
^~~~
D:\a\1\s\swift\stdlib\public\stubs\ThreadLocalStorage.cpp(43,1): note: candidate function not viable: no known conversion from '(lambda at D:\a\1\s\swift\stdlib\public\stubs\ThreadLocalStorage.cpp:85:3)' to '__swift_thread_key_destructor _Nullable' (aka 'void (*)(void *) __attribute__((stdcall))') for 2nd argument
_stdlib_thread_key_create(__swift_thread_key_t * _Nonnull key,
^
```
One additional tweak (setting the scalar-aligned bit on foreign indices) had to be made to avoid a performance regression for long non-ASCII foreign strings.
Check if building on Android through the ANDROID_DATA environment variable, then set
SWIFT_ANDROID_NATIVE_SYSROOT to the default layout for the Termux app, and key all the
include, lib, and other SDK paths off of that. The system libc and a few other libraries
are linked against from /system/lib[64]. Finally, check if lit is running natively on
Android and don't use adb if so.
__swift_size_t on Windows is a size_t, which makes it potentially a
64-bit integer. ULONG, however, is always a 32-bit integer, and so this
cast risks shrinking the apparent size of the cbBuffer argument to
BCryptGenRandom. The effect of that will be to underfill the buffer,
leaving it full of uninitialized memory that we would treat as random.
The actual risk from this in the current implementation is basically
zero, as user code can only ever invoke this with an argument size of 8.
There's no good reason to leave this sharp edge on the API though.
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
Due to the custom build system implemented in CMake for Swift, we cannot
properly detect the target and set flags appropriately. Instead, assume
that if the primary variant is an Apple target, that all targets are
Apple variants. This fixes cross-compilation on macOS.
These would never be decoded in normal use, but it's possible to construct an archive that will attempt to decode them. Without this override, that throws an exception or worse.
rdar://problem/48429185
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
These are supposed to be processed in the C locale always, irrespective
of the current locale. We were not doing this and so we would parse the
value incorrectly.
Old Swift and new Swift runtimes and overlays need to coexist in the same process. This means there must not be any classes which have the same ObjC runtime name in old and new, because the ObjC runtime doesn't like name collisions.
When possible without breaking source compatibility, classes were renamed in Swift, which results in a different ObjC name.
Public classes were renamed only on the ObjC side using the @_objcRuntimeName attribute.
This is similar to the work done in pull request #19295. That only renamed @objc classes. This renames all of the others, since even pure Swift classes still get an ObjC name.
rdar://problem/46646438
The conversion routines in MSVCPRT return "0" for the conversion of
"-inf" et al. Provde template specializations for `float`, `double`,
and `long double` to use `strtof`, `strtod`, and `strtold` respectively.
This fixes the lossless conversion of floating point constants.
The mapping of the return value of the `FlsAlloc` was flipped resulting
in the failure of the TLS key creation. The test suite would fail to
generate the TLS key resulting in failures.
This implements commandline access on Windows by using the Windows Shell
API to access the commandline information and making it available in
Swift. This is needed for the correct invocation of the child process
in the unit tests.
• Convert _AbstractStringStorage to a protocol, and the free functions used to deduplicate implementations to extensions on that protocol.
• Move 'start' into the abstract type and use that to simplify some code
• Move the ASCII fast path for length into UTF16View.
• Add a weirder but faster way to check which (if any) of our NSString subclasses a given object is, and adopt it
Previously, the stdlib provided:
- getters for AnyKeyPath and PartialKeyPath, which have remained;
- a getter for KeyPath, which still exists alongside a new read
coroutine; and
- a pair of owned mutable addressors that provided modify-like behavior
for WritableKeyPath and ReferenceWritableKeyPath, which have been
replaced with modify coroutines and augmented with dedicated setters.
SILGen then uses the most efficient accessor available for the access
it's been asked to do: for example, if it's been asked to produce a
borrowed r-value, it uses the read accessor.
Providing a broad spectrum of accessor functions here seems acceptable
because the code-size hit is fixed-size: we don't need to generate
extra code per storage declaration to support more alternatives for
key paths.
Note that this is just the compiler ABI; the implementation is still
basically what it was. That means the implementation of the setters
and the read accessor is pretty far from optimal. But we can improve
the implementation later; we can't improve the ABI.
The coroutine accessors have to be implemented in C++ and used via
hand-rolled declarations in SILGen because it's not currently possible
to declare independent coroutine accessors in Swift.
