Summary:
The following changes were required to fix these tests:

1) Change LLVM_ENABLE_PLUGINS to an option and move it to
   llvm/CMakeLists.txt with an appropriate default -- which matches
   the original default behavior.

2) Move the plugins directory from clang/test/Analysis
   clang/lib/Analysis.  It's not enough to add an exclude to the
   lit.local.cfg file because add_lit_testsuites recurses the tree and
   automatically adds the appropriate `check-` targets, which don't
   make sense for the plugins because they aren't tests and don't
   have `RUN` statements.

   Here's a list of the `clang-check-anlysis*` targets with this
   change:

```
  $ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis
  check-clang-analysis
  check-clang-analysis-checkers
  check-clang-analysis-copypaste
  check-clang-analysis-diagnostics
  check-clang-analysis-engine
  check-clang-analysis-exploration_order
  check-clang-analysis-html_diagnostics
  check-clang-analysis-html_diagnostics-relevant_lines
  check-clang-analysis-inlining
  check-clang-analysis-objc
  check-clang-analysis-unified-sources
  check-clang-analysis-z3
```

3) Simplify the logic and only include the subdirectories under
   clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set.

Reviewed By: NoQ

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D62445

llvm-svn: 361790

The current code iterates over the combination of LLVM_EXTERNAL_PROJECTS
and LLVM_ENABLE_PROJECTS, but then disables projects that are only in
the former. If a project is in LLVM_EXTERNAL_PROJECTS, it should be
enabled.

See also llvm-commits thread on r354060.

Differential revision: https://reviews.llvm.org/D62289

llvm-svn: 361751

Enable CMake policy 77. This alters the behavior of option. The old behavior
would remove the value of the option from the cache and create a new one. The
new behavior does not create the variable if it is defined already. This ensures
that subsequent reconfigures will behave identically. This seems better than the
setting of OLD - the desire is to ensure that it is set to OLD or NEW.

llvm-svn: 361307

The unwind tables (`.eh_frame`, `.arm.extab`) add a significant chunk of data to
the final binaries.  These should not be needed normally, particularly when
exceptions are disabled.  This enables shrinking `lldb-server` by ~18% (3 MiB)
when built with gold.

llvm-svn: 359819

Standalone builds of projects other than llvm itself (lldb, libcxx,
etc) include HandleLLVMOptions but not the top level llvm CMakeLists,
so we need to set this variable here to ensure that it always has a
value.

This should fix the build issues some folks have been seeing.

llvm-svn: 357976

Simplify building with particular C++ standards by replacing the
specific "enable standard X" flags with a flag that allows specifying
the standard you want directly.

We preserve compatibility with the existing flags so that anyone with
those flags in existing caches won't break mysteriously.

Differential Revision: https://reviews.llvm.org/D60399

llvm-svn: 357899

Differential Revision: https://reviews.llvm.org/D54978

llvm-svn: 356929

As discovered in D56774 the command line gets to long, so use a response file
to give the script the libs. This change has been tested and is confirmed
working for me.

Commited on behalf of Jakob Bornecrantz.
Differential Revision: https://reviews.llvm.org/D56781

llvm-svn: 356443

LLVM is always built; including it in LLVM_ENABLE_PROJECTS has no
effect, but since it's in LLVM_ALL_PROJECTS, we produce a confusing
message about it being disabled. Drop it from LLVM_ALL_PROJECTS to avoid
this. Pointed out by David Greene on the mailing list [1].

[1] http://lists.llvm.org/pipermail/llvm-dev/2019-March/130854.html

llvm-svn: 355735

Part 4 of CSPGO changes:
(1) add support in cmake for cspgo build.
(2) fix an issue in big endian.
(3) test cases.

Differential Revision: https://reviews.llvm.org/D54175

llvm-svn: 355541

When LLVM_ENABLE_PROJECTS is set, CMake assumes the project
directories are all side-by-side. This is not always the case and
there's no reason to expect it if LLVM_EXTERNAL_<proj>_SOURCE_DIR is
set. Honor that setting if it exists and allow the build configuration
to continue.

Differential Revision: https://reviews.llvm.org/D49672

llvm-svn: 354693

LLVM r353148, changed the circumstances in which the project source directory variables are created to only create them for LLVM projects. This patch initializes the directory variables for projects specified in `LLVM_EXTERNAL_PROJECTS` as well.

llvm-svn: 354060

If you want to build clang-tools-extra with monorepo, just add it to
LLVM_ENABLE_PROJECTS like with other projects.

See also "Separating clang-tools-extra from clang in LLVM_ENABLE_PROJECTS"
on cfe-dev.

Differential Revision: https://reviews.llvm.org/D58157

llvm-svn: 354057

and commit a1853e834c65751f92521f7481b15cf0365e796b.

They broke arm and aarch64

llvm-svn: 353590

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 353374

Moved everything SMT-related to LLVM and updated the cmake scripts.

Differential Revision: https://reviews.llvm.org/D54978

llvm-svn: 353373

We iterate over the list and only enable projects from that list that
are present in LLVM_ENABLE_PROJECTS and disable all other projects. Most
users will only specify clang in LLVM_ENABLE_PROJECTS and expect
clang-tools-extra to be implicitly enabled, so remove clang-tools-extra
from LLVM_ALL_PROJECTS so that it doesn't get disabled instead.

llvm-svn: 353354

Make LLVM_ALL_PROJECTS reflect all top-level directories in the monorepo
rather than an arbitrary subset. clang-tools-extra is technically
unnecessary since it gets enabled by clang, but having it there for
consistency shouldn't hurt either.

Differential Revision: https://reviews.llvm.org/D57843

llvm-svn: 353346

It'll get ignored in LLVM_ENABLE_PROJECTS after r353148 otherwise.

llvm-svn: 353343

Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang and lldb. They were both similar,
but different. They were both broken in their own ways, for example the
one used by Clang didn't properly handle monorepo resulting in an
incorrect version information reported by Clang.

This change unifies two the scripts by introducing a new script that's
used from both LLVM, Clang and lldb, ensures that the new script
supports both monorepo and standalone SVN and Git setups, and removes
the old scripts.

Differential Revision: https://reviews.llvm.org/D57063

llvm-svn: 353268

LLVM_ENABLED_PROJECT and reconfigured it had no effect on what
projects were actually built. This was very confusing behaviour. The
reason for this is that the value of the `LLVM_TOOL_<PROJECT>_BUILD`
variables are already set.

The problem here is that we have two sources of truth:

* The projects listed in LLVM_ENABLE_PROJECTS.
* The projects enabled/disabled with LLVM_TOOL_<PROJECT>_BUILD.

At configure time we have no real way of knowing which source of truth
the user wants so we apply the following heuristic:

If the user ever sets `LLVM_ENABLE_PROJECTS` in the CMakeCache then that
is used as the single source of truth and we force the
`LLVM_TOOL_<PROJECT>_BUILD` CMake cache variables to have the
appropriate values that match the contents of the
`LLVM_ENABLE_PROJECTS`. If the user never sets `LLVM_ENABLE_PROJECTS`
then they can continue to use and set the `LLVM_TOOL_<PROJECT>_BUILD`
variables as the "source of truth".

The problem with this approach is that if the user ever tries to use
both `LLVM_ENABLE_PROJECTS` and `LLVM_TOOL_<PROJECT>_BUILD` for the same
build directory then any user set value for `LLVM_TOOL_<PROJECT>_BUILD`
variables will get overwriten, likely without the user noticing.

Hopefully the above shouldn't matter in practice because the
LLVM_TOOL_<PROJECT>_BUILD variables are not documented, but
LLVM_ENABLE_PROJECTS is.

We should probably deprecate the `LLVM_TOOL_<PROJECT>_BUILD`
variables at some point by turning them into to regular CMake
variables that don't live in the CMake cache.

Differential Revision: https://reviews.llvm.org/D57535

llvm-svn: 353148

Reverting D57264 again, it looks like we're down to two bots that need fixing:

polly-amd64-linux
polly-arm-linux

They both have old versions of libstdc++ and recent clang.

llvm-svn: 352954

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 352951

Looks like we still have a few bots that are sad. Let try to get them fixed!

llvm-svn: 352835

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 352834

A handful of bots are still breaking, either because I missed them in my audit,
they were offline, or something else. I'm contacting their authors, but I'll
revert for now and re-commit later.

llvm-svn: 352814

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 352811

This reverts commits r352729 and r352731: this broke Sanitizer Windows bots

llvm-svn: 352733

Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang. They were both similar, but
different. They were both broken in their own ways, for example the one
used by Clang didn't properly handle monorepo resulting in an incorrect
version information reported by Clang.

This change unifies two the scripts by introducing a new script that's
used from both LLVM and Clang, ensures that the new script supports both
monorepo and standalone SVN and Git setups, and removes the old scripts.

Differential Revision: https://reviews.llvm.org/D57063

llvm-svn: 352729

They were breaking the Windows build when using MSBuild, see the
discussion on D56781.

r351833: "Use response file when generating LLVM-C.dll"

> Use response file when generating LLVM-C.dll
>
> As discovered in D56774 the command line gets to long, so use a response file to give the script the libs. This change has been tested and is confirmed working for me.
>
> Commited on behalf of Jakob Bornecrantz
>
> Differential Revision: https://reviews.llvm.org/D56781

r352250: "Build LLVM-C.dll by default on windows and enable in release package"

>  Build LLVM-C.dll by default on windows and enable in release package
>
>  With the fixes to the building of LLVM-C.dll in D56781 this should now
>  be safe to land. This will greatly simplify dealing with LLVM for people
>  that just want to use the C API on windows. This is a follow up from
>  D35077.
>
>  Patch by Jakob Bornecrantz!
>
>  Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 352492

With the fixes to the building of LLVM-C.dll in D56781 this should now
be safe to land. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.

Patch by Jakob Bornecrantz!

Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 352250

This broke the build, ending up with too long command-lines when invoking gen-mscv-exports.py.

> As it says in the subject, should have gone long enough now that this
> should be safe. This will greatly simplify dealing with LLVM for people
> that just want to use the C API on windows. This is a follow up from
> D35077.
>
> Patch by Jakob Bornecrantz!
>
> Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 351329

As it says in the subject, should have gone long enough now that this
should be safe. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.

Patch by Jakob Bornecrantz!

Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 351324

llvm-svn: 351320

Reviewers: zturner

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits

Differential Revision: https://reviews.llvm.org/D55942

llvm-svn: 349792

llvm-svn: 349656

- Disable incremental linking by default. /INCREMENTAL adds extra thunks in the EXE, which makes execution slower.
- Set /MT (static CRT lib) by default instead of CMake's default /MD (dll CRT lib). The previous default /MD makes all DLL functions to be thunked, thus making execution slower (memcmp, memset, etc.)
- Adds LLVM_ENABLE_INCREMENTAL_LINK which is set to OFF by default.

Differential revision: https://reviews.llvm.org/D55056

llvm-svn: 349517

Summary:
Currently we can't install the modulemaps provided by LLVM, since they are not structured to support headers generated as part of the build (ex. `llvm/IR/Attributes.gen`).
This patch restructures the module maps in order to support installation.

Modules containing generated headers are defined in the new `module.extern.modulemap` file, and are referenced from the main `module.modulemap` using `extern module`. There are two versions of the `module.extern.modulemap` file; one used when building and another, `module.install.modulemap`, which is re-named during installation.

Users can opt-into module map installation using `-DLLVM_INSTALL_MODULEMAPS=ON`.  The default value is `OFF` due to llvm.org/PR31905.

Reviewers: rsmith, mehdi_amini, bruno, EricWF

Reviewed By: EricWF

Subscribers: tschuett, chapuni, mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D53510

llvm-svn: 347420

Summary: Allow code-signing with entitlements. FORCE may be used to avoid an error when replacing existing signatures.

Reviewers: beanz, bogner

Reviewed By: beanz

Subscribers: mgorny, llvm-commits, lldb-commits

Differential Revision: https://reviews.llvm.org/D54443

llvm-svn: 347068

This reverts commit rL346367 due to test error in compiler-rt.

llvm-svn: 346383