Clang-800 is crashing with C++ modules when building this version of LLVM.
Hopefully we can find a workaround. The crash is tracked
in rdar://problem/28739039
On Darwin, LLVM builds with -gmodules which causes debug info for the
types defined by the LLVM modules is stored alongside the modules in the
module cache. Deleting the module cache on every re-invocation of
build-script without re-building the LLVM and clang modules will erase
the debug info and thus render any LLVM types undebuggable.
rdar://problem/28655564
Turns out -DLLVM_ENABLE_ASSERTIONS does not actually enable assertions in LLVM!
What it actually does is rewrite the -DNDEBUG flag to be -UNDEBUG. This means
that we always want to pass in -DNDEBUG to swift. There are some complications
though. This means that we can not compile the C++ part of the runtime with a
different assertions setting than the swift compiler/llvm. This is a trade off
that for now we are ok with to get the no-asserts build working.
As part of a separate change, we are going to make -DLLVM_ENABLE_ASSERTIONS more
robust by doing what swift does now, putting -DNDEBUG or -UNDEBUG after CMake's
-DNDEBUG so we get the correct behavior of disabling or enabling assertions.
rdar://28485525
This patch resolves some post-commit feedback from @llvmbeanz. Specifically, the
only time that we need to hard code these flags are when compiling with
RelWithDebInfo since we need extra control in that case to ensure that CMake
does not sneak in a -g flag on the command line. This is important to ensure
that we are compiling with -gline-tables-only instead of -g.
Given that it is a performance fix specific to compiling with LTO with debug
info, we should no perform such a change when compiling with:
1. MINRELSIZE since we do not ever perform that build.
2. RELEASE since it does not have debug info.
3. DEBUG since why would one perform an LTO build in DEBUG mode.
In terms of 3, I can potentially imagine someone trying to compile Swift in
Debug with LTO to try to debug an LTO bug, but I imagine such a test case to be
such a rare need that there is no point in trying to make it faster.
This change introduces a helper function to construct the
LLDB Xcode options that are now used in two different locations.
On macOS Xcode builds, it builds and runs the lldb-gtest scheme
in the LLDB workspace. This step will fail the lldb test phase
if any of the gtests fail to compile or generate a test failure.
The three included Python scripts work together to generate a sqlite3
database containing mappings of all covered Swift source code regions to
the specific tests that cover them.
Additionally, build-script support is included for utilizing the
coverage database to prioritize tests covering changes in the Swift
repository.
If VERBOSE is set, the automake test harness used by libdispatch
will cat the log file for any failing testcase to stdout. This will
enable the detailed output from the failed test cases to be captured
by the CI system in the console log, enabling better test failure
diagnosis.
These are computed by build-script and passed directly by build-script-impl into
cmake for the relevant target. We can now start to migrate per product cmake
options from build-script-impl into build-script.
There may be some issues building compiler-rt with modules. Temporarily
disable the module build by default until we know more.
rdar://problem/27019000
Before this patch, it would not actually do anything unless
compute_cmake_llvm_tool_disable_flags()
was called, which is currently dead code, in the state of
build-script-impl currently.
I am preparing a different PR that reverts this change and will be merged for
swift-4.
This is disabled by default so on the builders it should be NFC.
This actually became a no-op since the build-script-impl triggered instance of
LLVM_INCLUDE_TESTS is always put strictly after this instance of setting the
cmake variable on the cmake line.
