IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The Visual Studio 2017 path is very different than the previous versions, and even the registry entries are completely different, so for now let's try the trivial way first (using the %VCToolsInstallDir% environment variable)
This patch adds support for writing out modules to the CIFactory.
If the user has passed -fmodule-name and -fmodules, we start
extending the CI instance with support for C++ modules and also
optionally setup AST consumers for writing out modules files
alongside the interpreter.
This is a preparation because we want to ship module configuration
files in the future in the cling resource directory (Clang VFS overlay
files and modulemaps). This means that we will need to know this path
in a few other places (e.g. where we specify the -ivfsoverlayPATH
arguments and potential -fmodule-map-file=PATH args)
It also makes this giant function a bit easier on the eyes.
So far we create our DeclCollector in the CIFactory and then tried to
get this variable back in the IncrementalParser by casting the
ASTConsumer of our compiler instance to a DeclCollector. This strategy
fails as soon as we want to have multiple collectors and start using
the clang multiplexer as this call will now fail (e.g. in this case to
have another ASTConsumer that looks in the C++ modules case for what
libraries we need to link - and the best way to add this is via
the multiplexed ASTConsumer that clang provides).
This patch moves the responsibility for the DeclCollector to the
caller that relies on getting a DeclCollector back, which is in this
case the constructor of IncrementalParser.
// clang currently supports native __float128 only on few targets, and
// this target does not have it. The most visible consequence of this is a
// specialization
// __is_floating_point_helper<__float128>
// in include/c++/6.3.0/type_traits:344 that clang then rejects. The
// specialization is protected by !if _GLIBCXX_USE_FLOAT128 (which is
// unconditionally set in c++config.h) and #if !__STRICT_ANSI__. Tweak the
// latter by disabling GNUMode.
GCC 4.9 only defines '__cplusplus' to the value 201300L and not to
201402L as expected for C++14. This makes the check for the available
C++ standards in the interpreter fail to enable C++14 (which in turn
means that ROOT cannot be compiled with GCC 4.9 if C++14 was enabled in
Cmake). Similarly, for C++17 apart from the proper value 201703L other
values seems to be floating around (e.g. 201406L as defined by the
version of LLVM included with ROOT). The requirement for '__cplusplus_'
to enable certain C++ standards in the interpreter is made less strict
and just needs to be larger than the previous final value.
This basically reinstates commit
0a62e34aa86b812651cfcf9526ba03b975adaa5c which was undone by commit
702298d9ad83866d0be62f0422c03ac8ea6687f1.
This is a must if everything else is compiled in C++17 mode. Not having
C++17 enabled within Interpreter caused errors in CMSSW.
Signed-off-by: David Abdurachmanov <davidlt@cern.ch>
Enabling exceptions here makes 42 more tests failing. For example, CodeGeneration\RecursiveInit.C raises a unhandled exception in WinEHPrepare.cpp, at:
if (UserI->isEHPad())
report_fatal_error("Cleanup funclets for the MSVC++ personality cannot "
"contain exceptional actions");
