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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The ClingMMapper must remain available until all ClingMemoryManagers
are destructed, which is typically during shutdown of IncrementalJIT.
This was not the case for the global object MMapperInstance that was
introduced during the upgrade to LLVM 13 because libCling variables
are destructed before running TROOT atexit handlers that shut down
the JIT. In practice, it happened to work but this will change with
the upgrade to LLVM 18 where we see crashes in some tests, potentially
because of upstream commit
47f5c54f99
See also commits e0f6c04660 ("Prevent static destruction from ending
DefaultMMapper too early") and 80c14bb948 ("Extend lifetime of
SectionMemoryManager::DefaultMMapper, again") for the same problem
that we previously patched in our copy of LLVM.
It relies on a very specific setup where Clang and Cling sources are
in llvm/tools, in order for the relative paths to work, which is not
anymore the recommended structure since upstream LLVM moved to a
monorepo. Also clang/test/Sema/address-constant.c is a very arbitrary
Clang test, so it seems best to just delete this test directory.
Clad tests will try to use the just-built Clang compiler. First, this
dependency was not declared properly, and now results in a cycle after
commit fe6c671e85 made clang depend on clad. Since we never run the
Clad tests, never build them.
Commit 785c9df34d ("Restore symbol lookup in child interpreters")
added a DefinitionGenerator to allow symbol lookup in the parent
IncrementalJIT after the upgrade to LLVM 13. It appears that instead
of the unmangled name, we need to lookup already linker mangled names.
This fixes the tests CodeUnloading/AtExit.C and
MultipleInterpreters/MultipleInterpreters.C on macOS, which adds an
underscore during linker mangling. No change on Linux because there
is no additional linker name mangling.
With the latest MacOSX15.0.sdk, Clang complains about a "cyclic
dependency in module 'std': std -> _wctype -> __wctype -> std".
Break this cycle by deleting the module for ctype.h in libc++,
it only includes ctype.h from the C library which has its own
module definition.
Closes#16219
We are relying on this since a while, for example for reemission of
template symbols. At the moment, we get the incremental extensions
because Preprocessor::enableIncrementalProcessing() turns them on
internally, but this will change with LLVM 18 where this method only
controls incremental processing of a single Preprocessor object.
Upstream Clang keeps TemplateIdAnnotations around "if they might
still be in the token stream." See upstream commit for more details:
6163aa9679
(included in Clang 11, in ROOT since the upgrade to LLVM 13)
This reasoning doesn't apply when we fully reset the Parser state in
ParserStateRAII's destructor, and we expect the swapped out vector of
TemplateIdAnnotations to be empty in order to not leak.
Fixes#16121
Manually curating the modulemap is far from ideal because it requires
updates for changes in the libc++ library shipped with the SDK, which
must also work across all supported SDK versions. An alternative would
be to locate the modulemap shipped with libc++ during configuration
time, copy it and dynamically modify its contents to suit our needs.
This commit essentially reverts a288ff9 from four years ago, which was
also part of the multi-python machinery that is not necessary anymore
after Python 2 support was dropped.
Also, make the choice of looked-up components consistent with what is
actually required.
This will allow us to simplify our ASTConsumer model instead of creating many
multiplexers that are not needed. That should simplify adoption of latest
versions of clad.
