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.
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.
When building on Linux, the definition of `swift_snprintf_l` would cause
an unused function warning. Expand the scope of the preprocessor guard
to encompass the function for the single use. This avoids the unused
function warning.
Some of the previously used stubs are no longer needed in newer releases
of the Android API. Android L and Android O provide the functions in
their associated versions of bionic. This is needed to build against a
newer version of the SDK.
The returned type `std::streamoff` on Windows x64 is a `long long`
rather than `int`. This results in a 64-to-32 bit shortening of the
value. Use the appropriate type to avoid the truncation.
`strlen` returns a unsigned value, but `std::streamoff` is an signed
value. Explicitly cast the value to avoid the warning about the
implicit signed conversion.
Move the duplicated compiler-rt support routines into its own source
file. This will need to be expanded for Windows. As on Linux, there
are certain builtin routines which are not available from the standard
runtime and need to be augmented for now.
* SR-106: New floating-point `description` implementation
This replaces the current implementation of `description` and
`debugDescription` for the standard floating-point types with a new
formatting routine based on a variation of Florian Loitsch' Grisu2
algorithm with changes suggested by Andrysco, Jhala, and Lerner's 2016
paper describing Errol3.
Unlike the earlier code based on `sprintf` with a fixed number of
digits, this version always chooses the optimal number of digits. As
such, we can now use the exact same output for both `description` and
`debugDescription` (except of course that `debugDescription` provides
full detail for NaNs).
The implementation has been extensively commented; people familiar with
Grisu-style algorithms should find the code easy to understand.
This implementation is:
* Fast. It uses only fixed-width integer arithmetic and has constant
memory and time requirements.
* Simple. It is only a little more complex than Loitsch' original
implementation of Grisu2. The digit decomposition logic for double is
less than 300 lines of standard C (half of which is common arithmetic
support routines).
* Always Accurate. Converting the decimal form back to binary (using an
accurate algorithm such as Clinger's) will always yield exactly the
original binary value. For the IEEE 754 formats, the round-trip will
produce exactly the same bit pattern in memory. This is an essential
requirement for JSON serialization, debugging, and logging.
* Always Short. This always selects an accurate result with the minimum
number of decimal digits. (So that `1.0 / 10.0` will always print
`0.1`.)
* Always Close. Among all accurate, short results, this always chooses
the result that is closest to the exact floating-point value. (In case
of an exact tie, it rounds the last digit even.)
This resolves SR-106 and related issues that have complained
about the floating-point `description` properties being inexact.
* Remove duplicate infinity handling
* Use defined(__SIZEOF_INT128__) to detect uint128_t support
* Separate `extracting` the integer part from `clearing` the integer part
The previous code was unnecessarily obfuscated by the attempt to combine
these two operations.
* Use `UINT32_MAX` to mask off 32 bits of a larger integer
* Correct the expected NaN results for 32-bit i386
* Make the C++ exceptions here consistent
Adding a C source file somehow exposed an issue in an unrelated C++ file.
Thanks to Joe Groff for the fix.
* Rename SwiftDtoa to ".cpp"
Having a C file in stdlib/public/runtime causes strange
build failures on Linux in unrelated C++ files.
As a workaround, rename SwiftDtoa.c to .cpp to see
if that avoids the problems.
* Revert "Make the C++ exceptions here consistent"
This reverts commit 6cd5c20566.
On `istringstream`, `tellg()` returns -1 if the stream is at the end of the file. This indicates success in this circumstance, so we should update `pos` to reflect that the whole string has been read.
NFC on platforms other than Windows, Cygwin, and Haiku.
Use the KeyPath implementation's new support for instantiating and dealing with captures to lower the generic context required to dispatch computed accessors with dependent generics.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
Update for SE-0107: UnsafeRawPointer
This adds a "mutating" initialize to UnsafePointer to make
Immutable -> Mutable conversions explicit.
These are quick fixes to stdlib, overlays, and test cases that are necessary
in order to remove arbitrary UnsafePointer conversions.
Many cases can be expressed better up by reworking the surrounding
code, but we first need a working starting point.
`WIN32_LEAN_AND_MEAN` prevents "rarely-used" headers from being pulled in. This
significantly reduced preprocessor pressure, speeding up compile. It also
reduces the amount of cruft pulled in by the Windows.h.
`NOMINMAX` ensures that the `min` and `max` macros are not defined. These
macros collide with the use of `min` and `max` from C++ in certain cases: e.g.
`std::limits<T>`.
This is a purely mechanical change replacing the attributes with the reserved
spelling. Compilers are to not error when they encounter a reserved spelling
for an attribute which they do not support.
The general rule here is that something needs to be SWIFT_CC(swift)
if it's just declared in Swift code using _silgen_name, as opposed to
importing something via a header.
Of course, SWIFT_CC(swift) expands to nothing by default for now, and
I haven't made an effort yet to add the indirect-result / context
parameter ABI attributes. This is just a best-effort first pass.
I also took the opportunity to shift a few files to just implement
their shims header and to demote a few things to be private stdlib
interfaces.
This adds an Android target for the stdlib. It is also the first
example of cross-compiling outside of Darwin.
Mailing list discussions:
1. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151207/000171.html
2. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000492.html
The Android variant of Swift may be built using the following `build-script`
invocation:
```
$ utils/build-script \
-R \ # Build in ReleaseAssert mode.
--android \ # Build for Android.
--android-ndk ~/android-ndk-r10e \ # Path to an Android NDK.
--android-ndk-version 21 \
--android-icu-uc ~/libicu-android/armeabi-v7a/libicuuc.so \
--android-icu-uc-include ~/libicu-android/armeabi-v7a/icu/source/common \
--android-icu-i18n ~/libicu-android/armeabi-v7a/libicui18n.so \
--android-icu-i18n-include ~/libicu-android/armeabi-v7a/icu/source/i18n/
```
Android builds have the following dependencies, as can be seen in
the build script invocation:
1. An Android NDK of version 21 or greater, available to download
here: http://developer.android.com/ndk/downloads/index.html.
2. A libicu compatible with android-armv7.
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.
This patch adds powerpc64le Linux support. While the patch also adds
the matching powerpc64 bits, there are endian issues that need to be
sorted out.
The PowerPC LLVM changes for the swift ABI (eg returning three element
non-homogeneous aggregates) are still in the works, but a simple LLVM
fix to allow those aggregates results in swift passing all but 8
test cases.
