LLVM_DIR cannot be "${CMAKE_BINARY_DIR}/interpreter/llvm/src" in case
of external LLVM, set it to ${LLVM_BINARY_DIR} instead.

Silly workaround for rootcling not being able to parse the STL headers anymore after the update of Visual Studio to the version 16.7.0:
```
  Generating G__Core.cxx, ../bin/libCore.rootmap
  In file included from input_line_5:1:
  In file included from C:/Users/sftnight/build/release/include\Rtypes.h:191:
  In file included from C:/Users/sftnight/build/release/include/TGenericClassInfo.h:21:
  In file included from C:/Users/sftnight/build/release/include/TSchemaHelper.h:17:
  In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.291  10\\include\string:11:
  In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.291  10\\include\xstring:14:
  In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.291  10\\include\xmemory:16:
  In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.291  10\\include\xutility:15:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\utility(137,9): error G08EB1F86: expected member name or ';' after declaration specifiers [C:\Users\sftnight\build\release\core\G__Core.vcxproj]
          !_Is_implicitly_default_constructible<_Uty1>::value || !_Is_implicitly_default_constructible<_Uty2>::value)
          ^
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\utility(137,9): error GC66A3811: expected ')' [C:\Users\sftnight\build\release\core\G__Core.vcxproj]
  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\utility:136:23: note: to match this '('
      constexpr explicit(
                        ^
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\utility(218,24): error G08EB1F86: expected member name or ';' after declaration specifiers [C:\Users\sftnight\build\release\core\G__Core.vcxproj]
      constexpr explicit(!is_convertible_v<const _Other1&, _Ty1> || !is_convertible_v<const _Other2&, _Ty2>)
      ~~~~~~~~~~~~~~~~~~ ^
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\utility(218,24): error GC66A3811: expected ')' [C:\Users\sftnight\build\release\core\G__Core.vcxproj]
  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\utility:218:23: note: to match this '('
      constexpr explicit(!is_convertible_v<const _Other1&, _Ty1> || !is_convertible_v<const _Other2&, _Ty2>)
                        ^
  In file included from input_line_5:1:
  In file included from C:/Users/sftnight/build/release/include\Rtypes.h:191:
  In file included from C:/Users/sftnight/build/release/include/TGenericClassInfo.h:21:
  In file included from C:/Users/sftnight/build/release/include/TSchemaHelper.h:17:
  In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\string:11:
  In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\xstring:14:
  In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\xmemory:16:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\xutility(63,31): error G959205E0: '_To' does not refer to a value [C:\Users\sftnight\build\release\core\G__Core.vcxproj]
      return __builtin_bit_cast(_To, _Val);
                                ^
  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\\include\xutility:51:17: note: declared here
  template <class _To, class _From,
                  ^
CUSTOMBUILD : error : Error loading the default header files. [C:\Users\sftnight\build\release\core\G__Core.vcxproj]
```
To be checked/removed after the upgrade of LLVM & Clang

The new release includes some improvements:
  * Implement hessian matrices via the clad::jacobian interface.

See more at: https://github.com/vgvassilev/clad/blob/v0.7/docs/ReleaseNotes.md

This patch should be the last part of the fix for ROOT-10886.

This is needed to fix ROOT-10886 in conjunction with
https://github.com/vgvassilev/clad/pull/170.

This reverts commit 1a9569aa81b0aab0316ded194e4e0cc28005a4aa.

This reverts commit 30ecf72b.
It's superseded by "[clang] Backport llvm svn 331428:"

commit eaf11ad70904679593d3c7c100bcbcc395c91a89
Author: Richard Smith <richard-llvm@metafoo.co.uk>
Date:   Thu May 3 03:58:32 2018 +0000

    Track the result of evaluating a computed noexcept specification on the
    FunctionProtoType.

    We previously re-evaluated the expression each time we wanted to know whether
    the type is noexcept or not. We now evaluate the expression exactly once.

    This is not quite "no functional change": it fixes a crasher bug during AST
    deserialization where we would try to evaluate the noexcept specification in a
    situation where we have not deserialized sufficient portions of the AST to
    permit such evaluation.

    llvm-svn: 331428

Prevents conflicts of subsequent patch backport.

This reverts commit 73ae6729.
It's superseded by "[clang] Backport llvm svn 331428:"

This reverts commit 98ee7a19.
It's superseded by "[clang] Backport llvm svn 331428:"

ROOT-10812: Fix building clad with external clang

This should fix the issue when cling is built against prebuilt llvm on setups
such as conda.

Even for the ErrorOut case the Transaction should be flagged as beyond
kCompleted, to prevent it from being asserted on as "we have transaction
without errors that was not committed" in ~IncrementalParser().

(cherry picked from commit 43ee232163d3cbc8d9b8a6d83501a82469009759)

This conservative assert intended to capture future uses of the
shouldPermanentlyIgnore routine and check if we have specified an absolute
non-symlinked path.

Turns out that when we scan for libraries we iterate a given folder which may
move files around. Then the iterable (official) filename's real path might
differ at the point of iteration and the point of the check. Some file systems
use a temporary filename while copying/moving file and the rename it to the
real filename preserving atomicity of the operations.

It looks like this exactly happens in the description of ROOT-10791 -- the
iterator gives the expected real path of the filename which is not yet available
when we ask for the real path of that path we get something different (using the
same inode) eg: `mathsymb.ps` vs `mathsymb.ps_tmp_4810`.

Instead of asserting, let the file system handles this instead.

Kudos to Philippe Canal for investigating this sporadic failure.

When doing lookup on templates, instantiation can fail.
This can be triggered during template instantiation somewhere
in clang, autoloading, cling-lookup - and SFINAE errors that
occur in cling-lookup must not bubble up to clang, or else
clang will think that there was a problem (where there was
none - just e.g. ROOT trying to autoload a bogus template).

In this concrete case, a template specialized with a lambda
was not found by clang, was tried to be autoloaded, TMetaUtils
produced a broken normalized type name, lookup on the broken
type name failed with a SFINAE error - and that ended up being
swallowed by a clang SFINAETrap by the topmost lookup.

Instead, keep SFINAE errors to ourselves.

This is an improved version of 40673e58
which lowers the SFINAE-reset to Lookup, as AutoParse can still
see partial template specialization scopes. It fixes ROOT-10777.

(cherry picked from commit 4dcdbcb9f7a5cdc774da9e1dcb67b388cd685039)

(cherry picked from commit add00009abbf854b6838778c947d6d2bbd4943ff)

[wincxxmodules] Fix std and libc modules on Windows

If all requirements were satisfied, tar_required would always be false.
This commit fixes it.

There might be an issue when using conda as default Python for Python3
because conda calls it pip but otherwise it is pip3.

This is part of root-project/root#4717

This is part of root-project/root#4717

Commit df0b689e simplified the search for the C++ include directories and
tried to use a locale independent regex.

However this regex doesn't work for all locales, for example in German
the string in the output is not

```
#include <...> search starts here:
```

but the word order is switched and we have

```
Suche für »#include <...>« beginnt hier:
```

As such I propose to go back to C-locale for this query to be completely
safe against weird locale settings.

This fixes an assert in isBloomFilterEmpty which assumes
the bloom filter is already built.

This patch consolidates the symbol resolution facilities throughout TCling into
a new singleton class Dyld part of the cling's DynamicLibraryManager.

The new dyld is responsible for:
  * Symlink resolution -- it implements a memory efficient representation of
    the full path to shared objects allowing search at constant time O(1). This
    also fixes issues when resolving symbols from OSX where the system libraries
    contain multiple levels of symlinks.
  * Bloom filter optimization -- it uses a stohastic data structure which gives
    a definitive answer if a symbol is not in the set. The implementation checks
    the .gnu.hash section in ELF which is the GNU implementation of a bloom
    filter and uses it. If the symbol is not in the bloom filter, the
    implementation builds its own and uses it. The measured performance of the
    bloom filter is 30% speed up for 2mb more memory. The custom bloom filter on
    top of the .gnu.hash filter gives 1-2% better performance.
    The advantage for the custom bloom filter is that it works on all
    implementations which do not support .gnu.hash (windows and osx). It is also
    customizable if we want to further reduce the false positive rates
    (currently at p=2%).
  * Hash table optimization -- we build a hash table which contains all symbols
    for a given library. This allows us to avoid the fallback symbol iteration
    if multiple symbols from the same library are requested. The hash table
    optimization targets to optimize the case where the bloom filter tells us
    the symbol is *maybe* in the library.

Patch by Alexander Penev and me!

Force deserialization also for unevaluated ESTs.
Deserializing the decl chain (as part of the linkage spec calculation)
will update the EST between Start and End EH emission, causing an
asymmetry and triggering the assert. This forces the decl chain to be
loaded.

Fixes roottest/root/treeformula/stl/assertSparseSelection.C on MacOS.

We might have an instantiation around, and the exception spec type
is only available if we have deserialized it. Force deserialization
which will update the EST. We certainly know that we will not
CodeGen and uninstantiated decl.

This patch fixes an assertion in codegen:
"CGCleanup.h:584: void clang::CodeGen::EHScopeStack::popTerminate(): Assertion `!empty() && "popping exception stack when not empty"' failed.
Aborted (core dumped)"

It is minimally reproducible by:

cat repro.C
template <typename T>
struct Template {
   Template() {}
private:
   T m[1];
};
std::vector<Template<int> > use;

//std::vector<float>f;
template class Template<std::vector<float> >;

void repro() {}

on fedora-30 with build config:

cmake  -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_CXX_FLAGS="-UNDEBUG"
-DCMAKE_CXX_STANDARD="14" -DCMAKE_INSTALL_PREFIX="../install"
-DLLVM_BUILD_TYPE="Debug" -Dalien="Off" -Darrow="Off" -Dasimage="On"
-Dbuiltin_afterimage="On" -Dbuiltin_cfitsio="Off" -Dbuiltin_davix="On"
-Dbuiltin_fftw3="Off" -Dbuiltin_freetype="Off" -Dbuiltin_ftgl="On"
-Dbuiltin_gl2ps="On" -Dbuiltin_glew="On" -Dbuiltin_gsl="Off" -Dbuiltin_lz4="On"
-Dbuiltin_lzma="On" -Dbuiltin_openssl="Off" -Dbuiltin_pcre="On"
-Dbuiltin_tbb="On" -Dbuiltin_unuran="On" -Dbuiltin_vc="On" -Dbuiltin_vdt="On"
-Dbuiltin_veccore="On" -Dbuiltin_xrootd="On" -Dbuiltin_xxhash="On"
-Dbuiltin_zlib="On" -Dbuiltin_zstd="Off" -Dccache="ON" -Dcefweb="Off"
-Dclad="On" -Dcocoa="Off" -Dcuda="Off" -Dcudnn="Off" -Ddataframe="On"
-Ddavix="On" -Ddcache="Off" -Ddev="Off" -Dfail-on-missing="On" -Dfcgi="Off"
-Dfftw3="On" -Dfitsio="On" -Dfortran="On" -Dgdml="On" -Dgfal="Off"
-Dgsl_shared="Off" -Dgviz="Off" -Dhttp="On" -Dimt="On" -Dlibcxx="Off"
-Dmathmore="On" -Dmemstat="Off" -Dminuit2="On" -Dmlp="On" -Dmonalisa="Off"
-Dmpi="Off" -Dmysql="On" -Dodbc="Off" -Dopengl="On" -Doracle="Off" -Dpgsql="On"
-Dpyroot="On" -Dpythia6="Off" -Dpythia6_nolink="Off" -Dpythia8="On"
-Dqt5web="Off" -Dr="Off" -Droofit="On" -Droottest="ON" -Dshadowpw="On"
-Dsoversion="On" -Dspectrum="On" -Dsqlite="On" -Dssl="On" -Dtesting="ON"
-Dtmva="On" -Dtmva-cpu="On" -Dtmva-gpu="Off" -Dtmva-pymva="On" -Dtmva-rmva="Off"
-Dunuran="On" -Dvc="On" -Dvdt="On" -Dveccore="On" -Dvecgeom="Off" -Dvmc="On"
-Dwin_broken_tests="Off" -Dx11="On" -Dxml="On" -Dxrootd="On"
/build/workspace/root-pullrequests-build-vvasilev/root -G Ninja

This patch works around compatibility issues between libcxx and glibc. It should
fix the set up of the FNAL ART framework.

Thanks to Chris Green this patch should resolve ROOT-10677.