* Updates to tgmath functions for CGFloat
These changes bring CGFloat in line with the other FloatingPoint types. Some of this stuff is now defined at the protocol level, so we can get rid of it at the concrete type level. A couple other functions have been deprecated for all types, with protocol or tgmath replacements.
* Cleanup tgmath wrappers.
- Remove special-case gyb logic for lgamma on Darwin; the symbols we need are always present, even if not visible in the headers, so we only need a prototype.
- Add some deprecations for symbols that have direct stdlib analogues.
- Make some operations generic on [Binary]FloatingPoint, where they can map to the protocols instead of calling libm.
- Mark ldexp(Float/Double) renamed to scalbn; for binary formats these are identical functions, and we don't really want to use these names for hypothetical future Decimal support, as they're not Swifty.
* First pass at implementing support for mapping between long double and Float80.
* Only define CLongDouble on platforms where I know what it is.
* remove some hacks that are no longer necessary.
Cygwin is considered a distinct target with a distinct ABI, environment
conditions, and data types. Though the goal of the project is
native Windows integration with UNIX-likes, that is not compatible with
the idea that the platform can be ignored as Win-like enough to have the
existing os(Windows) condition apply.
- CYGWIN symbol is used to distinguish Cygwin environment from other OS
and other environment in Windows.
- Added windows and windowsCygnus to OSVersion in StdlibUnittest
Replace the non-generic tgmath functions with generic <T: FloatingPoint> implementations where possible, and move the global sqrt() operation into tgmath.
This adds the swiftMSVCRT module which is similar in spirit to swiftGlibc and
swiftDarwin, exposing the Microsoft C Runtime library to swift. Furthermore,
disable pieces of the standard library which are not immediately trivially
portable to Windows. A lot of this functionality can still be implemented and
exposed to the user, however, this is the quickest means to a PoC for native
windows support.
As a temporary solution, add a -DCYGWIN flag to indicate that we are building
for the cygwin windows target. This allows us to continue supporting the cygwin
environment whilst making the windows port work natively against the windows
environment (msvc). Eventually, that will hopefully be replaced with an
environment check in swift.
There are a couple of features that are not yet implemented, because they require additions to the Builtin module. Specifically, this implementation does not have:
- formRemainder(dividingBy:)
- formSquareRoot()
- addProduct(_:,_:)
Also missing are the generic initializers and comparisons whose implementation depends on having new Integer protocols.
The last remaining feature of SE-0067 is that while the basic operators +,-,*,/, etc are moved onto the FloatingPoint protocol, they are still required on the concrete types in order to disambiguate overloads. Fixing this seems to require either modifying the overload resolution rules or removing these operators from some other protocols. Or it might just require that someone smarter than me looks at the problem.
Passes all the existing tests (with the included changes). I'm working on additional tests for the new features.
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.
When we're not serializing SIL for all function bodies, @_transparent
functions can only reference internal functions that are declared
@_versioned, otherwise there's no serialized body and no public entry
point, so any client that inlines the @_transparent function will
not be able to link.
This patch adds the minimum set of @_versioned declarations to allow
a non-optimized build of the standard library and overlays.
Recall that this attribute is just a temporary hack to make progress
on building the standard library with resilience enabled.
Once availability and resilience learn about each other, @_versioned
will be replaced by having an availability annotation on an internal
declaration. Invariants will be diagnosed by Sema instead of asserting
in the SIL verifier.
Finally, the set of "internal but available" declarations will
eventually be audited instead of determined by experimentation.
This almost closes out https://bugs.swift.org/browse/SR-267.
The remaining issue is an interaction between SIL optimizations and
serialization that will be fixed with some upcoming changes to the
optimizer.
