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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Unfortunately this break external tools such as cling which alters CompoundStmts
to implement its interactive extensions.
We have implemented a patch in clang which brings the old facilities only when
the new interface CompoundStmt::replaceStmts is called.
See llvm-mirror/clang@d0ee47a
ForVisibleRedeclaration does not try to deserialize content from module files.
It should be used for efficiency and when we are sure that what we look up is
in the present TU and it does not make sense to ask the module files.
See llvm-mirror/clang@6bbe311
- now the custom path of `--cuda-path` is correctly set in the ptx
compiler, allowing the use of CUDA SDK's which are not installed on
in the default location
- add the prefix "cling" (normal interpreter error) or
"cling-ptx" (ptx interpreter -> just in CUDA mode) to every
interpreter error message
- example before:
error: cannot find CUDA installation. Provide its path via --cuda-path, or pass -nocudainc to build without CUDA includes.
error: cannot find libdevice for sm_20. Provide path to different CUDA installation via --cuda-path, or pass -nocudalib to build without linking with libdevice.
error: cannot find CUDA installation. Provide its path via --cuda-path, or pass -nocudainc to build without CUDA includes.
- example after:
cling: error: cannot find CUDA installation. Provide its path via --cuda-path, or pass -nocudainc to build without CUDA includes.
cling-ptx: error: cannot find libdevice for sm_20. Provide path to different CUDA installation via --cuda-path, or pass -nocudalib to build without linking with libdevice.
cling-ptx: error: cannot find CUDA installation. Provide its path via --cuda-path, or pass -nocudainc to build without CUDA includes.
This makes all functions end up in the same text section, which is
important for TCling on macOS to catch exceptions from constructors:
Stack unwinding requires information about program addresses to find
out which objects to destroy and what code should be called to handle
the exception. These addresses are relocated against a single __text
section when loading the produced MachO binary, which breaks if the
call sites of global constructors end up in a separate init section.
Fixes ROOT-10703 and ROOT-10962
This commit allows the user to enable/disable specific interpreter capabilities
without requiring to `#include` the heavier weight `Interpreter.h` (that also
has dependencies on llvm).
The only feature covered at the moment is definition shadowing.
Closes cling issue #360.
As discussed in the associated JIRA ticket, this information is of no utility for the end user and will only be included in Debug builds.
Fixes ROOT-7199.
* [cling] DefinitionShadower: allow shadowing of non-user-defined declarations
These changes allow the DefinitionShadower to shadow declarations
whose first definition was possibly in a system header.
This solves the problem of declaring a variable 'data' that might conflict
with 'std::data' (by allowing std::data to be shadowed).
* [cling] DefinitionShadower: fix handling of variable templates
Following the discussion [on GitHub](df0e84968a#), move back the workaround for Visual Studio 2019 v16.7.0 from `rootcling_impl.cxx` to `CIFactory.cpp`
Pressing ctrl-r when no ~/.root_hist file is present or possibly
when it contains 0 lines used to cause a segfault. The culprit
if an out-of-bound access in History::GetLine, as the case in which
the history has zero entries was not taken into account.
With this patch, Histoy::GetLine returns an empty string instead.
This fixes ROOT-10917.
Co-authored-by: Axel Naumann <Axel.Naumann@cern.ch>
Fix output redirection (`.> blah.txt`) which is curently freezing the console input on Windows
When a file (or console) has been created without the `FILE_SHARE_READ | FILE_SHARE_WRITE` flags, there is no way to change this, but by closing it and re-opening it (or a new one) . And I suspect that a standard console doesn't have those flags, so when redirecting the output to a file with `.> blah.txt`, all the output is going to the file, without any echo on the console, and when typing `.>` to suppress the redirection, the file contains this kind of errors:
```
Error 6 in textinput::TerminalDisplayWin attaching to console output: The handle is invalid.
Error 6 in textinput::TerminalDisplayWin attaching / getting console info: The handle is invalid.
Error 6 in textinput::TerminalDisplayWin writing to output: The handle is invalid.
```
This patch solves those issues, even if I'm not sure if it is the root of the problem (it might be something else deep in the `MetaSema::actOnRedirectCommand` function).
NB I don't know if this can have any side effect, but I didn't see any so far...
And for info, one could Enable Console Virtual Terminal Sequences (ANSI escape code) that can control cursor movement, color/font mode, and other operations when written to the output stream by adding the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag, but then it breaks the WRAP_AT_EOL_OUTPUT. With this feature, the escape sequences like `\033[39m` would work in the Windows 10 command prompt as well.
This is a known issue, see https://github.com/microsoft/terminal/issues/349
The global module index (GMI) is an optimization which hides the introduced by
clang overhead when pre-loading the C++ modules at startup.
The GMI represents a mapping between an identifier and a set of modules which
contain this indentifier. This mean that if we TH1 is undeclared the GMI will
load all modules which contain this identifier which is usually suboptimal, too.
The semantic GMI maps identifiers only to modules which contain a definition of
the entity behind the identifier. For cases such as typedefs where the entity
introduces a synonym (rather than declaration) we map the first module we
encounter. For namespaces we add all modules which has a namespace partition.
The namespace case is still suboptimal and further improved by inspecting
what exactly is being looked up in the namespace by the qualified lookup facilities.
On Windows, the .dll files contain symbol information in COFF Format
which DLM currently fails to understand properly. This leads to
unrecognized symbol errors while starting ROOT with modules.
This commit teaches DLM to correctly read symbols when the Object File
is in COFF executable format.
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
Some platforms respect RTLD_LOCAL: symbols from libraries loaded with
this flag cannot be resolved by dlsym through the process. They should
instead be exposed to the JIT by calling ExposeHiddenSharedLibrarySymbols().
But then the JIT needs to actually make use of these libraries from
symbol resolution. That is done by setting SearchOrder to SO_LoadedLast, as
nicely documented in that flag.
Fixes ROOT not finding libCling symbols on some platforms, e.g. CentOS7,
Ubuntu 16 and 18.
