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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
This commit fixes the library path of modules in Windows by adding the Bin directory in the list of paths. Previously, ROOT by default assumes that modules are present in the Lib directory which is not the case for Windows.
When using these modifiers, a type can consist of multiple tokens
as for example "unsigned int". However the keyword "int" can also
be omitted, making "unsigned" itself also a valid type.
Note that this only handles the most basic case for the modifiers.
The size modifiers "short", "long", and "long long" would need
similar treatment. Moreover the standard permits any order for the
type specifiers, ie "unsigned long long int" and "long int unsigned
long" are both valid (and actually the same type).
For some common libraries we provide modulemaps such as tinyxml2 and boost.
Independently whether implicit or fno-implicit-module-maps is selected we insert
an overlay and register the modulemap directly.
This patch disables this when fno-implicit-module-maps is chosen. This should
resolve ROOT-10803 introduced by root-project/root#5709
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().
Ninja buffers compiler output, and compilers then think they should
not use colored output (because no terminal). Force it on them.
The same was already implemented for clang, a few lines above.
And let cling survive: it's parsing compiler output, and the ANSI
color escapes confuse the regexes.
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 40673e583fceda8b362a0902c6aba371ddd0cfd8
which lowers the SFINAE-reset to Lookup, as AutoParse can still
see partial template specialization scopes. It fixes ROOT-10777.
Commit df0b689 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 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!
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.
OSX has modularized sdk (libc++ included) and there we prefer the modulemaps
that libraries ship with. However, libc++ can be also used on other Unix
platforms and we should not try to mount the std.modulemap file for it.
This patch fixes ROOT-10677.
This prevents an assert (isClingShadowNamespace(D->getDeclContext()) && "D not in a __cling_N5xxx namespace?"), function hideDecl, file /build/jenkins/night/LABEL/mac1014/SPEC/soversion/V/master/root/interpreter/cling/lib/Interpreter/DefinitionShadower.cpp, line 61
The new release includes some improvements in Reverse mode:
* Reduce the quadratic cloning complexity to linear.
* Support variable reassignments pontentially depending on control flow.
* Support operators `+=`, `-=`, `*=`, `/=`, `,`, `++`, `--`.
* Allow assignments to array subscripts.
* Support nested assignments in expressions `a = b * ((c ? d : e) = f = g);`
* Enable differentiation of for-loops
See more at: https://github.com/vgvassilev/clad/blob/v0.6/docs/ReleaseNotes.md
This patch enables us to upgrade to llvm9. Clad supports from clang5 to clang9.
This patch also instruct the build system to not copy {libc,std}.modulemap in
OSX because the standard libraries are already modularized.
Fixes a regression introduced by root-project/root@603a1c3e96
The current logic of pseudo-automatic modulemap discovery is a little fragile
as it mounts a virtual file named module.modulemap in the location where the
a give system library header is found (cuda.h, etc). However, if the libraries
are squashed into a single folder then we end up mounting a file over another
virtual file. This should be a hard error, however, on systems such as OSX some
libraries already come with modulemap files and we should just not mount our
predefined ones. This makes it very difficult to distinguish when to issue the
hard error.
While this patch is not a solution for the general when the modulemaps are
automatically discovered (-fimplicit-module-maps), we can use the real file
stems in cases where we are called with -fno-implicit-module-maps.
As a side effect this fixes the *non-recommended* squashing of library header
files into a single folder.
