This commit adds the flags -static-stdlib and -no-static-stdlib to
create programs statically linked (or not) with the standard library.
Not is the default, which is also the current behavior.
These flags are currently placebos on non-Darwin platforms.
On the Raspberry Pi 2 when trying to import Glibc, without this patch, it will attempt to
find the module map at "/usr/lib/swift/linux/armv7l/glibc.modulemap" and
fail to do so.
With this patch it will attempt to find the module map at
"/usr/lib/swift/linux/armv7/glibc.modulemap" where it will succeed in
finding the module map.
Similar behavior currently happens in the Driver and Frontend. To DRY up
this behavior it has been extracted to the Swift platform.
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.
There is currently a great deal of duplication across the
`GenericUnix` and `Windows` toolchains. The Android port will
add even more duplication.
To mitigate this, have `Windows` inherit from `GenericUnix`, and
have them share most of their implementation.
In addition, rename `Windows` to `Cygwin` (it would be pretty strange
to have a `Windows` toolchain inherit from something named `*Unix`).
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.
(1) We no longer put the Clang version string in our copy of or symlink to
Clang's resource directory.
(2) Newer Clang builds now generate a separate library for the Apple OS
simulators, instead of a fat binary.
We still need a proper end-to-end test for this, but that depends on
building compiler-rt with Swift, which isn't a standard config yet.
Exposes the global warning suppression and treatment as errors
functionality to the Swift driver. Introduces the flags
"-suppress-warnings" and "-warnings-as-errors". Test case include.
This is only the driver side of the work; the frontend doesn't understand
this new -output-filelist option yet. Next commit.
More https://bugs.swift.org/browse/SR-280.
Start sketching out a way for individual jobs to request filelists for
their inputs or their outputs. This should cover all the cases mentioned
in ad945426.
More https://bugs.swift.org/browse/SR-280.
This is simply a newline-separated list of files, matching the format
from Darwin ld's -filelist option.
Part 2 of https://bugs.swift.org/browse/SR-280.
Generate frontend commands with -filelist in them. This isn't actually
implemented yet, but we can start testing at this point.
Part 1 of https://bugs.swift.org/browse/SR-280.
Previously jobs had to grovel this information out of the raw argument
list, which dropped the types we had inferred on input files. This
makes things more consistent across the compiler, though arguably we
should be able to designate "primary" and "non-primary" inputs on a
per-action basis rather than resorting to "global" state.
Use this new information to stop passing object file inputs to the
Swift frontend, fixing rdar://problem/23213785.
The list wouldn't have to live on the Compilation, but I'm going to use
it to fix SR-280 / rdar://problem/23878192 as well.
Also, cluster the flags on Action into a single word. This probably doesn't
make any real difference, but it's the convention.
No functionality change.
The existing code was only recording a change in the /last/ dependency as needing
to rebuild the file. This could have caused things not to get rebuilt when they
should have.
In practice, a number of things have to coincide for this to cause problems:
- A dependency (let's say a type) has to be considered "modified" in this build.
- Some other file has to get rebuilt that didn't previously depend on the type,
or only depended on it in a non-cascading way (e.g. it's only used in function
bodies).
- The file had to not be rebuilt because of any cascading dependencies (or
because it itself changed).
- The file has to now depend on the type in a cascading way, so that downstream
files need to be rebuilt when they didn't before.
Noticed by inspection while fixing the previous issue.
This only shows up when there's a present-but-empty sequence node in
a swiftdeps file. The compiler never generates this, but it's in some of
the tests. I'm not sure why ASan didn't catch this.
This should fix the failures some people have been seeing with
test/Driver/Dependencies/private-after.swift, rdar://problem/23382722.
