Swift relies on this for now. So create our own. This makes more sense
than trying to add back in the API (which is dead besides the c api) or
use the c api itself. We should probably consider not using a global
context like this.
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.
An upcoming change has the SIL Optimizer drop the [fragile]
attribute from the specialized callee, unless the caller
is itself [fragile].
Since we need to distinguish specializations from fragile
and non-fragile contexts, add a new mangling node to
represent this concept.
Before the refactor, a dangling reference to a string may be stored in a DemanglePrinter in at least the following cases:
1) If an lvalue DemanglePrinter is initialized with an rvalue string:
DemanglePrinter printer("abc");
2) If an lvalue DemanglePrinter is initialized with an lvalue string which doesn't live as long as the printer:
unique_ptr<DemanglePrinter> printer;
{
std::string s = "abc";
printer = make_unique<DemanglePrinter>(s);
}
// Reference stored in printer is dangling
In addition, in all existing cases in the code where an lvalue DemanglePrinter is used, an empty string is initialized just before it, which isn't DRY, and is related to the previous problem - the coder shouldn't be expected to maintain the lifetime of a string separate from the DemanglePrinter which references it.
In addition, before the refactor, in any in-line use of DemanglePrinter it is constructed with an empty string parameter (in which to construct the string), but this doesn't look very clean.
The refactor solves the above issues by maintaining its own string as a member, while still enabling the original intent of being able to use DemanglePrinter both as an lvalue constructively before getting its value, and in-line as an rvalue.
This reverts commit 2262bd579a.
This information isn't necessary for field descriptor lookup,
after all. It's only the fields that need to have generic information,
which is already in the field descriptor.
Previously, the mangling didn't include generics, but these are
needed to key off of the new field descriptor metadata, as well
as to construct type references for the nominal type.
ASan allows to catch and diagnose memory corruption errors, which are possible
when using unsafe pointers.
This patch introduces a new driver/frontend option -sanitize=address to enable
ASan. When option is passed in, the ASan llvm passes will be turned on and
all functions will gain SanitizeAddress llvm attribute.
Introduce DarwinPlatformKind, which would allow us to switch on darwin
platforms instead of copying and pasting the brittle logic in several places.
Use the helper method to simplify ClangImporter.
...because "build configuration" is already the name of an Xcode feature.
- '#if' et al are "conditional compilation directives".
- The condition is a "conditional compilation expression", or just
"condition" if it's obvious.
- The predicates are "platform conditions" (including 'swift(>=...)')
- The options set with -D are "custom conditional compilation flags".
(Thanks, Kevin!)
I left "IfConfigDecl" as is, as well as SourceKit's various "BuildConfig"
settings because some of them are part of the SourceKit request format.
We can change these in follow-up commits, or not.
rdar://problem/19812930
