SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled altogether.
Add a message for two such reasons:
1. When whole module compilation is enabled, since optimizations for
WMO require a full rebuild.
2. When embedding LLVM IR bitcode, which needs to be re-generated.
SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled altogether.
Add a message for one such reason: when the build record file is
malformed.
Sorry -- I meant to include this with the previous commit. LLVM is
moving away from llvm::sys:TimeValue in favor of std::chrono. For consistency
with LLVM, I used the new llvm::sys::TimePoint type in most places.
There are a few places, like the SourceKit files modified here, where it
makes more sense to use std::chrono directly.
SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled
altogether.
Add a message for one such reason: when the arguments passed to the Swift
compiler don't match the ones used previously.
SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled altogether.
Add a message for one such reason: when the inputs passed to the
Swift compiler don't match the ones used previously.
SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled altogether.
Add a message for one such reason: when the version of the Swift
compiler being used to incrementally compile doesn't match the one used
to compile previously.
This flag switches the "effective language version" of the compiler,
at least to any version supported (as of this change: "3" or "3.0").
At the moment nothing uses it except the language version build
configuration statements (#if swift(...)) and various other places
that report, encode, or otherwise check version numbers.
In the future, it's intended as scaffolding for backwards compatibility.
Fixes SR-2582
The scope map models all of the name lookup scopes within a source
file. It can be queried by source location to find the innermost scope
that contains that source location. Then, one can follow the parent
pointers in the scope to enumerate the enclosing scopes.
The scope map itself is lazily constructed, only creating scope map
nodes when required implicitly (e.g, when searching for a particular
innermost scope) or forced for debugging purposes.
using a lazily-constructed tree that can be searched by source
location. A search within a particular source location will
Define compilation record (.swiftdeps) top-level keys, as well as string
identifiers used in compilation record files (like "!dirty" and "!private"), in
a single location. NFC.
Currently the Swift driver stops invoking frontend commands as soon as one of
them reports an error. Add a flag to control this behavior, so that users can
choose whether to see all the errors at once or bail out early.
Cygwin and MinGW should use the autolink feature in the sameway of Linux
due to the linker's limit. Now swift-autolink-extract recognizes the
COFF format file for Cygwin/MinGW.
Otherwise we get into a situation like this:
1. Change made to the interface of file A.swift that also causes an
error in A.swift.
2. Fixing the error in A.swift does not affect A.swift's interface.
3. File B.swift that depends on A.swift is not rebuilt, since the most
recent change to A.swift did not change its interface.
To fix this, mark downstream files as needing to be rebuilt even when
a compilation job fails with errors. Additionally, attempt to be extra
conservative when there's a crash.
rdar://problem/25405605
Background
----------
Now that Swift AST type support in LLDB has matured, we can stop emitting DWARF
type information by default to reduce compile time and ibject file size.
A future commit will change -g to emit only AST type references.
The full set of debug options will be
-gnone
-gline-tables-only
-g // AST types (= everything that LLDB needs)
-gdwarf-types // AST types + DWARF types (for legacy debuggers)
"Sanitizer Coverage" with a new flag ``-sanitize-coverage=``. This
flag is analogous to Clang's ``-fsanitize-coverage=``.
This instrumentation currently requires ASan or TSan to be enabled
because the module pass created by ``createSanitizerCoverageModulePass()``
inserts calls into functions found in compiler-rt's "sanitizer_common".
"sanitizer_common" is not shipped as an individual library but instead
exists in several of the sanitizer runtime libraries so we have to
link with one of them to avoid linking errors.
The rationale between adding this feature is to allow experimentation
with libFuzzer which currently relies on "Sanitizer Coverage"
instrumentation.
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.
