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.
- Update the documentation to reflect that Swift supports (only)
the latest NDK version. Based on what I've heard from Android
developers that use the NDK, this is a reasonable requirement.
- The most recent version of the Android NDK no longer includes a
"4.8" toolchain version. Change the default to "4.9", and update
the paths in the documentation to match.
- The build script option "--android-ndk-version" was misleading.
This parameter actually refers to the Android API level. Swift
currently supports 21 (Android 5.0) and above (although supporting
lower API levels would be desirable).
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.
* Switch to calling `putchar_unlocked()` instead of `putchar()` for
actual printing. We're already locking stdout with `flockfile()`, so
there's no need for the redundant lock that `putchar()` uses.
* Add an explicit lock to the output stream in `dump()`. This means the
entire dump is printed with the lock held, which will prevent the
output of `dump()` from mixing with prints on other threads.
* Use `_debugPrint_unlocked()` instead of `debugPrint()` in
`_adHocPrint()`. The output stream is already locked while this
function is executing. Rename the function to `_adHocPrint_unlocked()`
to make this explicit.
* Use `targetStream.write()` and `_print_unlocked()` instead of
`print()` in `_dumpObject()`. This removes the redundant locking, and
also eliminates the creation of intermediate strings. Rename the
function to `_dumpObject_unlocked()` to make this explicit.
* Use `targetStream.write()`, `_print_unlocked()`, and
`_debugPrint_unlocked()` in `_dumpSuperclass()`. This removes the
redundant locking, and also eliminates the creation of intermediate
strings. Rename the function to `_dumpSuperclass_unlocked()` to make
this explicit.
* Use `_debugPrint_unlocked()` instead of `debugPrint()` in
`String.init(reflecting:)`. This shouldn't really make much of a
difference but it matches the usage of `_print_unlocked()` in
`String.init(_:)`.
The net result is that all printing is still covered under locks like
before, but stdout is never recursively locked. This should result in
slightly faster printing. In addition, `dump()` is now covered under a
single lock so it can't mix its output with prints from other threads.
Set up a separate libSwiftStubs.a archive for C++ stub functionality that's needed by the standard library but not part of the core runtime interface. Seed it with the Stubs.cpp and LibcShims.cpp files, which consist only of stubs, though a few stubs are still strewn across the runtime code base.
