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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
and use a standard mechanism that plays well with -fvisibility.
Given that several symbols now use declspec(dllexport), remove them from
the ad-hoc cling_exports in ROOT's CMakeLists.txt.
Additionally, this commit extends the behavior of `.x`. Specifically, it adds
support for a list of function names whose execution will be tried in order.
To be compliant with the old behavior, this list currently only includes an
entry that matches the macro filename.
The dynamic library manager's dyld can search a symbol in the library path.
This patch uses that functionality to aid the 'unresolved while linking'
diagnostics.
Now we get:
cling -L lib/
****************** CLING ******************
* Type C++ code and press enter to run it *
* Type .q to exit *
*******************************************
[cling]$ extern int gErrorIgnoreLevel;
[cling]$ gErrorIgnoreLevel
IncrementalExecutor::executeFunction: symbol 'gErrorIgnoreLevel' unresolved while linking [cling interface function]!
Symbol found in '/.../lib/libCore.so'; did you mean to load it with .L /.../lib/libCore.so ?
[cling]$
This avoids problems where we consider other executables and object files as
libraries and the dyld decides to scan them. Upon this we hit files opened by
other processes and locked by the system (such as bootstat.dat :))
Thanks to Bertrand Bellenot for the diagnosis!
Sema::AddTemplateOverloadCandidate() can issue diagnostics as part of the
template instantiation it performs. The LookupHelper just wants to know
whether there is a matching function, which is similar to a SFINAE context
and a good reason to silence potential diagnostics if asked to do so!
Do get there, simple increase the scope of the setSuppressAllDiagnostics()
calls, and make it an RAII for robustness.
For the update of LLVM 9, Cling required another patch to Clang for
replacing the children of a CompoundStmt. Instead solve this by
creating a new CompoundStmt with the right Stmts attached.
Co-authored-by: Jonas Hahnfeld <Hahnfeld@itc.rwth-aachen.de>
Co-authored-by: Jonas Hahnfeld <hahnjo@hahnjo.de>
As Node is still a CompoundStmt, this will call the same function
recursively and again visit all previously visited and replaced
children, which doesn't seem necessary.
The argument -Xclang -triple=... completely bypasses Clang's Driver
logic and only sets the triple in CC1. This suffices for most code
generation tasks, but the Driver cannot compute the correct ABI and
sets the generic AArch64 "aapcs" instead of the specific "darwinpcs".
In turn, this causes integer arguments with less than 32 bits not
being sign-extended but being passed directly, which for example
manifests as (short)-1 being read as 65535 on the callee side.
The new argument --target=arm64-apple-darwin20.3.0 matches what
Apple's and LLVM main's clang return for --print-target-triple.
Fixes#7090
Outer RAIIs might still reference the Transaction, and unload is
assuming that it owns the transaction and can delete it / put it
into the TransactionPool.
This fixes https://github.com/root-project/root/issues/7657
We still need to track ownership as what has happened here (unload
of a Transaction held by an RAII) can happen again / elsewhere.
This will be addressed by a subsequent PR in master.
new of a char array might not have the correct alignment to hold a Transaction.
Allocate a Transaction itself directly, instead of in-place constructing it in
the character array.
Each Transaction in the pool is thus constructed through `new Transaction(S)`
and destructed through `delete T`, which is nicely symmetrical. The use of
`::operator new` and `::operator delete` isn't actually necessary.
While I'm at it, improve the assert message's wording.
The CMAKE_OSX_SYSROOT exports the exact version of the sdk which we build
against. However, this means that binary releases become sensitive to minor sdk
upgrades (eg. MacOSX11.1.sdk -> MacOSX11.2.sdk). Our infrastructure is
relatively resilient to such changes.
This patch introduces a workaround to address this issue -- it uses the fact
that the current sdk's parent directory has a symlink MacOSX.sdk which points
to the current sdk.
This should resolveroot-project/root#7021.
Before, pre-existing fwd decls of specializations got unloaded.
OTOH, any decl produced during (failed) template instantiation must
also be unloaded; see #6331. Those are easiest identified by unloading
the whole (failed) transaction.
```
error: no member named 'value' in 'std::__and_<std::is_copy_assignable<std::__cxx11::basic_string<char> >, std::is_copy_assignable<Inner<int> > >'
is_copy_assignable<_T2>>::value,
~~~~~~~~~~~~~~~~~~~~~~~~~~^
```
which is due to the first decl being invalid (as `Inner<int>` does not have a deinition and a `static_assert` /usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/type_traits:1093 being triggered), then not unloaded, and then picked up again where we *do* have the definition for `Inner<int>`.
Add test for templt spec lookup vs unloading.
There is no point in emitting a transaction that has been rolled back to
CodeGen. To make matters worse, a rolled-back transaction will not show up
in the list of transactions.
If Lookup fails to instantiate, its transaction should not be committed,
as we know it's useless and must be unloaded as it might contain invalid
Decls.
But that means Lookup needs to unload a non-committed transaction.
To determine the file magic, the file needs to be opened and read.
This is done with *each* file in $LD_LIBRARY_PATH, including ./
If one of them is e.g. a FIFO then reading blocks until someone
writes into the FIFO, which might cause the process to hang. This
was reported a couple of times, such as at https://root-forum.cern.ch/t/compiling-from-source-first-interactive-command-hangs/43997/5
Solution: only check for the file magic of *regular* files.
Sadly, llvm::sys::fs::get_file_type never sets file_not_found but
returns an unspecific status_error.
With llvm9, the module ptr gets reset upon emission.
Instead, just look for the symbol in the JIT - where it should be found,
as Init() is injecting it there, and we want to find *that* symbol,
not the one from the binary.
Fixes `CodeUnloading/AtExit.C` cling test.
In tests on an Apple M1 after the upgrade to LLVM 9, this new
instruction selection framework emits branches / calls that expect
all code to be reachable in +/- 128 MB. This cannot be guaranteed
during JIT, which generates code into allocated pages on the heap
and could span the entire address space of the process.
such as __dllonexit() and _onexit(). Without, static destruction
does not happen, as can be seen by roottest/cling/staticinit/execROOT-7775.C
failing to call the static destructors.
In LLVM 9, the `CompoundStmt::replaceStmts()` call seems to write to an invalid
memory location if the body was empty. This may happen after a parse error and
might end up corrupting the program state.
This patch makes `DeclExtractor` to exit early if there is nothing to do, which
solves the aforementioned problem.
This should fix a problem where the ClingTest unit test fails due to the fact
that std::vector is copied and delivered by Vc pulling a wrong dependency.
The patch applies a patch to remove duplicated entries from the StoredDeclsList.
Apparently, reading a yet-to-be-determined PCM file adds the same `Decl *` to
the lookup table. Trying to remove it using `StoredDeclsList::remove()` makes
an internal assertion to fail, as it expects the Decl to disappear from the
lookup table after being removed.
So far, `darwin.pcm` seems like one of the possible causes of this problem, but
more investigation is needed.
Sema create an ImportDecl, and that should not end up e.g. inside
a class definition, or wherever else the "autoparsing" was triggered.
Fixes roottest-root-meta-assertVarOffset.
(cherry picked from commit 4d8fcf0984118663a356d462eeec6cb6c34ebfef)