LLVM SVN r286561 made the default constructor for llvm::Error protected,
requiring value initialization to `llvm::Error::success()`. Update the code
accordingly.
Considering that formatting only affects a single compilation unit, and
that code formatting does not support line ranges yet, remove dependency
on clang::tooling::Replacement.
This fixes SR-2619.
Enable newly-introduced Clang functionality to load API notes stored
alongside the headers for a module or, for a framework, in an APINotes
subdirectory within the framework. Fixes rdar://problem/28455644.
llvm::Error's destructor has an assert in it that it was checked for success or
failure. This patch puts in a quick check for failure and emits a message to
llvm::errs() and returns failure (which in this case is indicating by returning
true).
A first class diagnostic should be added here, but given that I am preparing for
a stable merge update on a quick time schedule, I did the easy thing (with
respect to the message).
The main action here is to sink the creation of the installation rule for all of
the swift host tools into this API. In a latter commit, I will use this API to
create include and build rules for add_swift_host_tool.
All of these cases seem to need the symbols from LLVM's new CodeView library to
link.
The specific executables are:
1. Swift Driver.
2. SIL Extract.
3. SIL Opt.
4. Swift IDE Test.
5. Swift LLVM Opt.
6. LLDB Module Import Test
If a line range is not set, create a line range over the unsigned type,
instead of setting an arbitrary limit. We're not probably going to ever
deal with such big files, though.
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.
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.
All of these cases seem to need the symbols from LLVM's new CodeView library to
link.
The specific executables are:
1. Swift Driver.
2. SIL Extract.
3. SIL Opt.
4. Swift IDE Test.
5. Swift LLVM Opt.
6. LLDB Module Import Test
swift supports cross-compilation. The autolink extract tool is needed when
targeting non-Darwin targets even on Darwin. Install it as the aux-driver-tools
component. Update the Linux builds to install this component by default.
This was added at some point to make 'import Foundation' faster in the REPL.
What we really care about though is not delaying synthesis of the rawValue
accessors (those are synthesized on demand anyway), but delaying the
conformance check to RawRepresentable.
This reverts commit f2154ee94d, which reverted 04e1cd5bda. The original
commit needed to be reverted because of an issue in which install
targets were added to OS X builds that did not target Linux. This
addresses that issue by guarding all the Linux-only CMake logic with a
check for the SDK being built.
The current Glibc CMakeLists.txt uses the host machine to determine
which modulemap to use. The same modulemap can't be used for all
platforms because headers are available in different locations on
different platforms.
Using the host machine to determine which modulemap to configure and
place at a specific path in the resource dir is fine, so long as:
1. Only one Glibc is being compiled in a single CMake invocation.
2. The target machine needs the same modulemap as the host.
https://github.com/apple/swift/pull/1442 violates both of these
assumptions: the Glibc module for both Linux and Android is compiled
at the same time, and the Android target can't use the Linux modulemap.
This commit instead uses the target(s) to determine which
modulemap to use. The modulemap is configured and placed in an OS-
and architecture-specific directory in the resource dir. The path to
that modulemap is referenced by the ClangImporter (since it is no
longer at a path that is automatically discovered as an implicit
modulemap).
Using Clang to compile API notes introduces a dependency on the
underlying Clang, which can cause problems as Clang's support for API
notes evolves. Re-introduce the "-apinotes" driver flag into the Swift
driver to allow us to compile API notes, and use that (rather than
Clang) to precompile API notes for the overlays.
