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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
These symbols may not be found automatically. See also upstream issue
https://github.com/llvm/llvm-project/issues/61289. This fixes the
test DynamicLibraryManager/cached_realpath.C, approach by Lang Hames.
This new release includes some improvements:
* Add experimental support for forward vector mode
* Add pushforwards for std::floor and std::ceil
* Improve AD function interfaces with bitmasked options. For example:
clad::differentiate<<clad::order::first, clad::opts::vector_mode>(f) will
be equivalent to clad::differentiate<<1, clad::opts::vector_mode>(f) and
will request the first order derivative of f in forward vector mode.
* LLVM16 Support
See more at: https://github.com/vgvassilev/clad/blob/v1.2/docs/internalDocs/ReleaseNotes.md
Fixes https://github.com/root-project/root/issues/9449
so it is possible to define operator overload in cling cmd prompt.
btw, Make SkipPointerRefs() to not assume next token being a
tok::raw_identifier since it can be a global-scoped identifier,
e.g. int* ::class_a::func_b(short c) { return nullptr; }
e.g. class_a::class_a() = default;
class_a::~class_a();
They have no function definition body so caller of IsClassOrFunction()
should not try to parse their function bodies.
This makes it possible to drop our custom CompilerInvocation::addOverlay
functionality (but the rest of the patch that introduced it is still
needed with LLVM 13, so it cannot be reverted for now).
According to feature_test_macros, this macro is obsolete and "glibc
has been thread-safe by default for many years." Other platforms
don't use it at all, for example FreeBSD.
Some parts of ROOT used it to determine if we are compiling with
-pthread, but this is essentially unused these days because the
CMake build always enables threading support and there exists no
option to turn it off.
This will be required for future LLVM upgrades that rely on a common
cmake/ directory next to clang/ and llvm/.
The bulk of this change is the result of the following commands:
$ mkdir interpreter/llvm-project/
$ git mv interpreter/llvm/src/tools/clang/ interpreter/llvm-project/clang/
$ git mv interpreter/llvm/src/ interpreter/llvm-project/llvm/
$ git mv interpreter/llvm/llvm-project.tag interpreter/llvm-project/llvm-project.tag
Before showing command promt or executing scripts from argv,
enumerate .C files in the directory ${CLING_HOME}/.cling.d/ in alphabetic
order then .x them.
Search order of ${CLING_HOME}:
1. ${CLING_HOME} envvar
2. ${XDG_CONFIG_HOME}/cling/
3. ${HOME}/.config/cling/
4. ${HOME}/
As commit 2db042523a explains, this header doesn't exist anymore since
glibc 2.26. The oldest distributions that ROOT currently supports are
EL8 and Debian 10, both of which have glibc 2.28. Remove the module as
it also causes problems on FreeBSD due to including locale.h and a
cyclic dependency std -> xlocale.h -> std.
Prior to the upgrade to LLVM13, child interpreters used to also lookup symbols
in their parent.
This commit introduces a `DefinitionGenerator` that allows for symbol lookup
across different `IncrementalJIT` instances, which restores the old behavior.
This change fixes the following tests:
- CodeUnloading/AtExit.C
- MultipleInterpreters/MultipleInterpreters.C
Fixes#12455.
Do not use `ActOnReturnStmt()`, given that the scope returned by
`m_Sema->getCurScope()` might be == m_Sema->TUScope which obviously is
not a function scope.
This fixes the following crash:
```
1: #3 0x0000556b6a50389e clang::Sema::ActOnReturnStmt(clang::SourceLocation, clang::Expr*, clang::Scope*) (/home/jalopezg/CERN/repos/root/_build/interpreter/llvm/src/bin/cling+0x225389e)
1: #4 0x0000556b69215c56 cling::DeclExtractor::EnforceInitOrder(llvm::SmallVector<clang::Stmt*>&) (/home/jalopezg/CERN/repos/root/_build/interpreter/llvm/src/bin/cling+0xf65c56)
1: #5 0x0000556b69216788 cling::DeclExtractor::ExtractDecl(clang::FunctionDecl*) (/home/jalopezg/CERN/repos/root/_build/interpreter/llvm/src/bin/cling+0xf66788)
1: #6 0x0000556b69216a75 cling::DeclExtractor::Transform(clang::Decl*) (/home/jalopezg/CERN/repos/root/_build/interpreter/llvm/src/bin/cling+0xf66a75)
```
This diagnostic should always be promoted to error, regardless of the ignoring
state in `FilteringDiagConsumer`.
This fixes the SourceCall/ErrorMacro.C test.
The failure became visible after merging
https://github.com/root-project/root/pull/12654, given that `IgnorePromptDiags`
now defaults to 0 in `makeDefaultCompilationOptions()`.
`--enable-new-dtags` is needed in some toolchains to emit the new ELF dynamic
tags, i.e. RUNPATH.
Per ld(1) manual page: `By default, the new dynamic tags are not created.`
Clang diagnostic verification was unhappy with the previous state of
affairs. Move affected `expected-(warning|note)` markers to `Macros.h`.
Apparently, as Jonas Hahnfeld found, this failure originated in commit
8deb57c04a5ceea96533d095092fcd4f71d1df94, but is not to be reverted
per discussion in https://github.com/root-project/root/pull/12454.
The order in which declarations are removed makes a difference, e.g.
`MaybeRemoveDeclFromModule()` may require access to type information to
make up the mangled name.
Thus, we segregate declarations to be removed in `TagDecl`s (i.e., struct
/ union / class / enum) and other declarations. Removal of `TagDecl`s
is deferred until all the other declarations have been processed.
Declarations in each group are iterated in reverse order.
Fixes#12457.
Since adding bits/utility.h in commit e9a8c48e4f, a C++14 build with
GCC 12 (and potentially also other compiler versions) failed with
```
While building module 'Core':
While building module 'std' imported from input_line_1:1:
In file included from <module-includes>:38:
/opt/gcc/12.2.0/include/c++/12.2.0/functional:337:35: error: missing '#include <bits/utility.h>'; 'tuple_size' must be declared before it is used
= typename enable_if<(__i < tuple_size<_Tuple>::value),
^
/opt/gcc/12.2.0/include/c++/12.2.0/bits/utility.h:49:12: note: declaration here is not visible
struct tuple_size;
^
```
Apparently, once the module is declared, it must also be enabled for
C++14 and not restricted with cplusplus17.
In principle, for a TemplateDecl, `isDefinition()` issues a recursive
call passing the templated decl as a parameter. A `ConceptDecl` is
derived from `TemplateDecl`, however, it should always be considered
a definition.
Also, update the DeclShadowing test incorporating a C++20 concept.
Fixes#12779.
Make `FilteringDiagConsumer` also ignore -Wunused-result. Whether or not
such diagnostic is filtered depends on `CompilationOptions::IgnorePromptDiags`.
In particular, `IgnorePromptDiags` should _only_ be enabled for code parsed
via `Interpreter::EvaluateInternal()`. Thus, as of this commit `IgnorePromptDiags`
defaults to 0 in `makeDefaultCompilationOpts()`
The observable effect of this change is ignoring `-Wunused-result` for
wrapped code, e.g.
```c++
[[nodiscard]] int f() { return 0; }
// This yields `warning: ignoring return value of function declared with 'nodiscard' attribute [-Wunused-result]`
void g() { f(); }
f(); // but this should not
```
It is needed for C++11 support of #include <chrono>. Failures:
```
Processing /home/sftnight/build/night/LABEL/ROOT-fedora36/SPEC/default/V/master/root/tutorials/multicore/mt201_parallelHistoFill.C...
In file included from input_line_10:1:
/home/sftnight/build/night/LABEL/ROOT-fedora36/SPEC/default/V/master/root/tutorials/multicore/mt201_parallelHistoFill.C:55:51: error: no member named 'duration' in namespace 'std::chrono'
std::this_thread::sleep_for(std::chrono::duration<double, std::nano>(500));
~~~~~~~~~~~~~^
```
and
```
root [11] #include <bits/chrono.h>
/home/sftnight/build/night/LABEL/ROOT-fedora36/SPEC/default/V/master/build/etc/cling/std.modulemap:432:10: error: module 'std.bits/chrono.h' requires feature 'cplusplus17'
module "bits/chrono.h" [optional] {
^
ROOT_prompt_11:1:10: note: submodule of top-level module 'std' implicitly imported here
^
```
isysroot influences where clang will pick up libc++. Without this, and with
Xcode 14.3, cling will use libc++ from Xcode (or the command line tools) rather
than stdc++ from the macOS SDK, as clang would normally use. Passing the isysroot
(which point to the SDK) fixes this.
This solves build errors such as:
```
While building module 'Core':
While building module 'std' imported from input_line_1:1:
In file included from <module-includes>:17:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/math.h:309:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:462:1: error: cannot template a using declaration
using _BoolConstant _LIBCPP_NODEBUG_TYPE = integral_constant<bool, _Val>;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:462:21: error: C++ requires a type specifier for all declarations
using _BoolConstant _LIBCPP_NODEBUG_TYPE = integral_constant<bool, _Val>;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:462:68: error: use of undeclared identifier '_Val'
using _BoolConstant _LIBCPP_NODEBUG_TYPE = integral_constant<bool, _Val>;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:462:73: error: expected '(' for function-style cast or type construction
using _BoolConstant _LIBCPP_NODEBUG_TYPE = integral_constant<bool, _Val>;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
```
This reverts commit a4c07502a3e76c82f30828200f5fe4ae935ac166.
While this itself might not cause build issues, the related commit 90ffa89ae4 does;
handle them together.
