Building with assertions flag (-sAssertions=2) gives me these
```
[ RUN ] InterpreterTest.InstantiateTemplate Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueWithAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_3.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueWithAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_3.wasm RuntimeError: Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueWithAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment)
[ RUN ] InterpreterTest.InstantiateTemplate Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueNoAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_3.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueNoAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_3.wasm RuntimeError: Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueNoAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment)
[ RUN ] InterpreterTest.InstantiateTemplate Aborted(Assertion failed: undefined symbol '_ZnwmPv26__clang_Interpreter_NewTag'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_23.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '_ZnwmPv26__clang_Interpreter_NewTag'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_23.wasm RuntimeError: Aborted(Assertion failed: undefined symbol '_ZnwmPv26__clang_Interpreter_NewTag'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment)
[ RUN ] InterpreterTest.Value Aborted(Assertion failed: undefined symbol '_Z9getGlobalv'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_36.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '_Z9getGlobalv'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_36.wasm
[ RUN ] InterpreterTest.Value Aborted(Assertion failed: undefined symbol '_Z9getGlobalv'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_36.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '_Z9setGlobali'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_36.wasm
```
**So we have some symbols missing here that are needed by the side
modules being created here.**
First 2 are needed by both tests
Last 3 are needed for these lines accordingly in the Value test.
dc23869f98/clang/unittests/Interpreter/InterpreterTest.cpp (L355)dc23869f98/clang/unittests/Interpreter/InterpreterTest.cpp (L364)dc23869f98/clang/unittests/Interpreter/InterpreterTest.cpp (L365)
Everything should work as expected after this
```
[----------] 9 tests from InterpreterTest
[ RUN ] InterpreterTest.Sanity
[ OK ] InterpreterTest.Sanity (18 ms)
[ RUN ] InterpreterTest.IncrementalInputTopLevelDecls
[ OK ] InterpreterTest.IncrementalInputTopLevelDecls (45 ms)
[ RUN ] InterpreterTest.Errors
[ OK ] InterpreterTest.Errors (29 ms)
[ RUN ] InterpreterTest.DeclsAndStatements
[ OK ] InterpreterTest.DeclsAndStatements (34 ms)
[ RUN ] InterpreterTest.UndoCommand
/Users/anutosh491/work/llvm-project/clang/unittests/Interpreter/InterpreterTest.cpp:156: Skipped
Test fails for Emscipten builds
[ SKIPPED ] InterpreterTest.UndoCommand (0 ms)
[ RUN ] InterpreterTest.FindMangledNameSymbol
[ OK ] InterpreterTest.FindMangledNameSymbol (85 ms)
[ RUN ] InterpreterTest.InstantiateTemplate
[ OK ] InterpreterTest.InstantiateTemplate (127 ms)
[ RUN ] InterpreterTest.Value
[ OK ] InterpreterTest.Value (608 ms)
[ RUN ] InterpreterTest.TranslationUnit_CanonicalDecl
[ OK ] InterpreterTest.TranslationUnit_CanonicalDecl (64 ms)
[----------] 9 tests from InterpreterTest (1014 ms total)
```
This is similar to how we need to take care of some symbols while
building side modules during running cppinterop's test suite !
@vgvassilev @anutosh491 This is what it took for me to enable running
ClangReplInterpreterTests in an Emscripten environment. When I ran this
patch for llvm 20 we could run InterpreterTest.InstantiateTemplate , but
now it crashes gtest when running in node. Let me know what you think.
This patch introduces the ability to customize the fork process with an external lambda function. This is useful for downstream clients where they want to do stream redirection.
Updated error message logic for undo function. Throws different errors
for the case of there being nothing to undo, and for the case of
requesting more undos than there are operations to undo.
Fixes https://github.com/llvm/llvm-project/issues/143668
This patch should make msan happy as it found a real bug where we always try to
read an unsigned long long without respecting the underlying enum type.
Another follow-up on llvm/llvm-project#102858
While waiting for the bot owners it seems that this is not a major issue due
to the big endianness of the systemz platform. Instead it looks like we are not
modelling something well for enum types. Probably `va_arg` has a bug for that
platform or similar.
The asan failure seems to be a crash in asan and maybe related to the issues
we've mentioned in llvm/llvm-project#102858.
This patch should appease the bots that were broken by llvm/llvm-project#148701
The idea is to store a type-value pair in clang::Value which is updated
by the interpreter runtime. The class copies builtin types and boxes
non-builtin types to provide some lifetime control.
The patch enables default printers for C and C++ using a very
minimalistic approach. We handle enums, arrays and user types. Once we
land this we can focus on enabling user-defined pretty-printers which
take control over printing of types
The work started as part of https://reviews.llvm.org/D146809, then we
created a giant in https://github.com/llvm/llvm-project/pull/84769
This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
The `DiagnosticOptions` class is currently intrusively
reference-counted, which makes reasoning about its lifetime very
difficult in some cases. For example, `CompilerInvocation` owns the
`DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and
only exposes an accessor returning `DiagnosticOptions &`. One would
think this gives `CompilerInvocation` exclusive ownership of the object,
but that's not the case:
```c++
void shareOwnership(CompilerInvocation &CI) {
llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions();
// ...
}
```
This is a perfectly valid pattern that is being actually used in the
codebase.
I would like to ensure the ownership of `DiagnosticOptions` by
`CompilerInvocation` is guaranteed to be exclusive. This can be
leveraged for a copy-on-write optimization later on. This PR changes
usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and
`lldb` to not be intrusively reference-counted.
This reduces the size of the clang/unittests build directory by 64% and
my overall build dir size by 5%. Static linking is the real driving
factor here, but even if the default build configuration used shared
libraries, I don't see why we should be building so many unit test
binaries.
To make the project more approachable for new contributors, I'm
attempting to make the build a bit less resource-intensive. Build
directory size is a common complaint, and this is low-hanging fruit.
I've noticed that incremental builds leave behind the old, stale gtest binaries, and lit will keep running them. This mostly doesn't matter unless they use shared libraries, which will eventually stop working after successive builds. You can clean up the old test binaries with this command in the build directory:
$ find tools/clang/unittests/ -iname '*Tests' -type f | xargs rm
... or you can simply clean the build directory in a more holistic way.
---------
Co-authored-by: Petr Hosek <phosek@google.com>
This reapplies 5ffd9bdb50b57 (#133545) with fixes.
The BUILD_SHARED_LIBS=ON build was fixed by adding missing LLVM
dependencies to the InterpTests binary in
unittests/AST/ByteCode/CMakeLists.txt .
Pass all the dependencies into add_clang_unittest. This is consistent
with how it is done for LLDB. I borrowed the same named argument list
structure from add_lldb_unittest. This is a necessary step towards
consolidating unit tests into fewer binaries, but seems like a good
refactoring in its own right.
The module currently stores the target triple as a string. This means
that any code that wants to actually use the triple first has to
instantiate a Triple, which is somewhat expensive. The change in #121652
caused a moderate compile-time regression due to this. While it would be
easy enough to work around, I think that architecturally, it makes more
sense to store the parsed Triple in the module, so that it can always be
directly queried.
For this change, I've opted not to add any magic conversions between
std::string and Triple for backwards-compatibilty purses, and instead
write out needed Triple()s or str()s explicitly. This is because I think
a decent number of them should be changed to work on Triple as well, to
avoid unnecessary conversions back and forth.
The only interesting part in this patch is that the default triple is
Triple("") instead of Triple() to preserve existing behavior. The former
defaults to using the ELF object format instead of unknown object
format. We should fix that as well.
The Intel C++ Compiler (ICX) passes linker flags through the driver
unlike MSVC and clang-cl, and therefore needs them to be prefixed with
`/Qoption,link` (the equivalent of -Wl, for gcc on *nix).
Use the `LINKER:` prefix for the `/EXPORT:` options in clang-repl, this
expands to the correct flag for ICX and nothing for MSVC / clang-cl.
RFC:
https://discourse.llvm.org/t/rfc-cmake-linker-flags-need-wl-equivalent-for-intel-c-icx-on-windows/82446
This will fix duplicate and missing linker symbol errors when using
CLANG_LINK_CLANG_DYLIB on windows and explicit visibility macros are
used.
This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
window.
This patch improves the design of the IncrementalParser and Interpreter
classes. Now the incremental parser is only responsible for building the
partial translation unit declaration and the AST, while the Interpreter
fills in the lower level llvm::Module and other JIT-related
infrastructure. Finally the Interpreter class now orchestrates the AST
and the LLVM IR with the IncrementalParser and IncrementalExecutor
classes.
The design improvement allows us to rework some of the logic that
extracts an interpreter value into the clang::Value object. The new
implementation simplifies use-cases which are used for out-of-process
execution by allowing interpreter to be inherited or customized with an
clang::ASTConsumer.
This change will enable completing the pretty printing work which is in
llvm/llvm-project#84769
Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled.
LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely
compatible with export_executable_symbols as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
llvm_add_exectuable so the link flag can be determined directly
without calling export_executable_symbols_* later.
`LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES` is not completely
compatible with `export_executable_symbols` as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
`llvm_add_exectuable` so the link flag can be determined directly
without calling `export_executable_symbols_*` later.
Since `raw_string_ostream` doesn't own the string buffer, it is
desirable (in terms of memory safety) for users to directly reference
the string buffer rather than use `raw_string_ostream::str()`.
Work towards TODO comment to remove `raw_string_ostream::str()`.
At least on my Windows machine, these two tests fail due to not being
able to look up `??3@YAXPEAX_K@Z` (which is
`void __cdecl operator delete(void *, unsigned __int64)` in demangled)
after 130e93cc26ca. Since they don't test anything related to sized
deallocation, just disable sized allocation for them.
Possibly fixes#95451.
The original bug is legitimate UB, but this is in the clang constant
expression interpreter, not clang-repl.
https://github.com/llvm/llvm-project/issues/94994 covers investigation
of this specific bug in clang-repl.
This patch fixes:
clang/unittests/Interpreter/IncrementalProcessingTest.cpp:39:13:
error: unused function 'HostSupportsJit' [-Werror,-Wunused-function]
Until now the IncrExecutor was created lazily on the first execution
request. In order to process the PTUs that come from initialization, we
have to do it upfront implicitly.
Since C++14 has been released for about nine years and most standard
libraries have implemented sized deallocation functions, it's time to
make this feature default again.
This is another try of https://reviews.llvm.org/D112921.
The original commit cf5a8b4 was reverted by 2e5035a due to some
failures (see #83774).
Fixes#60061
Since C++14 has been released for about nine years and most standard
libraries have implemented sized deallocation functions, it's time to
make this feature default again.
This is another try of https://reviews.llvm.org/D112921.
Fixes#60061
PR
[https://github.com/llvm/llvm-project/pull/84461](https://github.com/llvm/llvm-project/pull/84461)
disabled `clang/unittests/Interpreter/InterpreterExtensionsTest.cpp` for
AIX by turning on `CLANG_INTERPRETER_PLATFORM_CANNOT_CREATE_LLJIT`.
This PR turns `CLANG_INTERPRETER_PLATFORM_CANNOT_CREATE_LLJIT` on for
zOS as well, since LLJIT cannot be created on zOS either.
Co-authored-by: Bahareh <bahareh.farhadi@ibm.com>
/usr/bin/ld: CMakeFiles/ClangReplInterpreterTests.dir/InterpreterExtensi
onsTest.cpp.o: undefined reference to symbol '_ZN4llvm14TargetRegistry12
lookupTargetENS_9StringRefERNSt7__cxx1112basic_stringIcSt11char_traitsIc
ESaIcEEE'
/usr/bin/ld: /work/kparzysz/git/llvm.org/b/x86/lib/libLLVMMC.so.19.0git:
error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
The missing symbol is `llvm::TargetRegistry::lookupTarget`, which
interestingly enough is in MC.
Add `MC` to the list of LLVM dependencies.
The LLJITBuilder interface provides a very convenient way to configure
the ORCv2 JIT engine. IncrementalExecutor already used it internally to
construct the JIT, but didn't provide external access. This patch lifts
control of the creation process to the Interpreter and allows injection
of a custom instance through the extended interface. The Interpreter's
default behavior remains unchanged and the IncrementalExecutor remains
an implementation detail.
Signedness of unqualified `char` is unspecified and varies between
platforms. This patch adds `Char_U` in `REPL_BUILTIN_TYPES` to account
for platforms that default to `unsigned char`.
This new test fails on the AIX bot with error `LLVM ERROR: Incompatible object format!`. Disable for now to investigate.
Same as 86337beca2e6f939127cd3e088ec80c0cf4a0a64.
