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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This teaches again the IncrementalExecutor to emit only one module at a time.
In the old MCJIT days, the API worked with module sets and cling assumed llvm's
jit infrastructure is moving in this direction.
LLVM 5.0 moves away from this concept and works with single llvm::Modules. This
patch will make the upgrade to LLVM 5.0 smoother.
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 is in prepare for the upcoming llvm upgrade. The future orc jit compile
layer needs a std::shared_ptr<llvm::Module>. The current design passes a
llvm::Module* around and any conversions to a shared_ptr cause the
destruction of the llvm::Module which is a long-lived object in cling.
With C++ modules we fail here because we get this extra 'include '
text before the actual header. As the header itself is correct
it seems, we just skip this extra text with modules enabled as
this code is anyway supposed to be replaced with modules
functionality.
We will probably see an increasing amount of these failures with
C++ modules as we now deserialize all declarations instead of just
the PCH ones. To safe us a lot of debugging time on where to push
the needed transaction, let's directly print the stack trace here
in the rare case that we crash here.
With the module generation in rootcling Clang rlies on AST consumers
to do the module generation work for it. Right now this doesn't work
however with the interpreter, as we just overwrite the deserialization
listener that clang added which will cause strange errors during
the module generation (the most prompinent error is that the number
of recorded submodules will be incorrect, as this it the first thing
that Clang checks before writing a module and which is recorded by
an ASTDeserializationListener).
This patch just adds a multiplexer here that allows us to keep the
old listener while also adding the one we have.
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.
Without throwing cling cannot communicate to the caller that the code has failed,
as the user code is currently running when failing the dynamic expression evaluation.
Fixes gROOT->ProcessLine("doesNotExist", &res) not signalling any error through res.
Well, it still does not set res to an error - but at least it now throws.
When run C++17 kernel in Jupyter notebook cause some errors
due to currently clang-5.0 in https://root.cern.ch/download/cling/ is not
support c++17.
So add support to C++1z for Jupyter kernel and we can try some new
features in Jupyter notebook.
for avoiding following error:
[I 05:46:38.253 NotebookApp] Kernel restarted:
d3413fa0-7046-4b63-912b-a286610eacc1
error: invalid value 'c++17' in '-std=c++17'
note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard
note: use 'gnu++98' or 'gnu++03' for 'ISO C++ 1998 with amendments and
GNU extensions' standard
note: use 'c++11' for 'ISO C++ 2011 with amendments' standard
note: use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU
extensions' standard
note: use 'c++14' for 'ISO C++ 2014 with amendments' standard
note: use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU
extensions' standard
note: use 'c++1z' for 'Working draft for ISO C++ 2017' standard
note: use 'gnu++1z' for 'Working draft for ISO C++ 2017 with GNU
extensions' standard
Fixes an issue for ATLAS, where Property<string>::Property<string&> cannot be instantiated by ROOT.
ROOT is trying to do that because the function is templated, with all template parameters having defaults.
(This "let us instantiate if all template params have defaults" is needed e.g. to see pair::pair() which is sfinae protected.)
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.
