In incremental compilation clang works with multiple `llvm::Module`s.
Our current approach is to create a CodeGenModule entity for every new
module request (via StartModule). However, some of the state such as the
mangle context needs to be preserved to keep the original semantics in
the ever-growing TU.
Fixes: llvm/llvm-project#95581.
cc: @jeaye
When instantiating a delayed template, the recorded token stream is
passed to `Parser::ParseLateTemplatedFuncDef` which will append the
current token "so it doesn't get lost". With incremental extensions
enabled, this is `repl_input_end` which subsequently needs support for
(de)serialization.
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.
Original commit message:"
[clang-repl] Extend the C support. (#89804)
The IdResolver chain is the main way for C to implement lookup rules. Every new
partial translation unit caused clang to exit the top-most scope which in turn
cleaned up the IdResolver chain. That was not an issue for C++ because its
lookup is implemented on the level of declaration contexts.
This patch keeps the IdResolver chain across partial translation units
maintaining proper C-style lookup infrastructure.
"
It was reverted in dfdf1c5fe45a82b9c578306f3d7627fd251d63f8 because it broke the
bots of lldb. This failure was subtle to debug but the current model does not
work well with ObjectiveC support in lldb. This patch does cleans up the
partial translation units in ObjectiveC. In future if we want to support
ObjectiveC we need to understand what exactly lldb is doing when recovering from
errors...
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.
The IdResolver chain is the main way for C to implement lookup rules.
Every new partial translation unit caused clang to exit the top-most
scope which in turn cleaned up the IdResolver chain. That was not an
issue for C++ because its lookup is implemented on the level of
declaration contexts.
This patch keeps the IdResolver chain across partial translation units
maintaining proper C-style lookup infrastructure.
These test cases are testing features not available when either
targeting the s390x-ibm-zos target or use tools/features not available
on the z/OS operating system. In a couple cases the lit test had a
number of subtests with one or two that aren't supported on z/OS. Rather
than mark the entire test as unsupported I split out the unsupported
tests into a separate test case.
This PR fixes the following issue when working with `clang-repl`:
```
fatal error: error in backend: Inline asm not supported by this streamer because we don't have an asm parser for this target
```
When working with the following input (named "unit.cpp"):
```cpp
__asm(".globl _ZSt21ios_base_library_initv");
int x;
```
and then in `clang-repl`:
```
#include "unit.cpp"
x = 10;
```
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
Make TopLevelStmtDecl a DeclContext so that variables defined in statements
are attached to the TopLevelDeclContext. This fixes redefinition errors
from variables declared in if conditions and for-init statements. These
must be local to the inner context (C++ 3.3.2p4), but they had generated
definitions on global scope instead.
This PR makes the TopLevelStmtDecl looking more like a FunctionDecl and
that's fine because the FunctionDecl is very close in terms of semantics.
Additionally, ActOnForStmt() requires a CompoundScope when processing a
NullStmt body.
---------
Co-authored-by: Vassil Vassilev <v.g.vassilev@gmail.com>
Fix linking error: "ld: error: can't create dynamic relocation
R_X86_64_64 against local symbol in readonly segment; recompile object
files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in
the output"
See https://github.com/llvm/llvm-project/pull/79261 for details.
It shows that clang-repl uses a different target triple with clang so that it
may be problematic if the calng-repl reads the generated BMI from clang
in a different target triple.
While the underlying issue is not easy to fix, this patch tries to make
this test green to not bother developers.
This adds a warning when applying the `pure` attribute along with the `const` attribute, or when applying the `pure` attribute to a function with a `void` return type (including constructors and destructors).
Fixes https://github.com/llvm/llvm-project/issues/77482
This patch brings back the basic support for C by inserting the required
for value printing runtime only when we are in C++ mode. Additionally,
it defines a new overload of operator placement new because we can't
really forward declare it in a library-agnostic way.
Fixes the issue described in llvm/llvm-project#69072.
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as
the printout looks like this:
A(1), this = 0000025597930000
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
While the expected printout looks like this:
A(1), this = 000002C903E10000
f: this = 000002C903E10000, val = 1
f: this = 000002C903E10000, val = 1
~A, this = 000002C903E10000, val = 1
Reapplying #70991 with the XFAIL changed to check the host triple, not
the target triple. On an MSVC based build of Clang, but with the default
target triple set to PS4/PS5, we will still see the failure. And a Linux
based build of Clang that targets PS4/PS5 won't see the issue.
This reverts commit e9db60c05e2fb96ff40cbb1f78790abc5de9237e.
This was still failing (unexpectedly passing) on some Sony PS
buildbots.
The issue is that the clang-repl testcases don't depend on what
the default target triple is, but what the host triple is,
which is used for JIT purposes.
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as
the printout looks like this:
A(1), this = 0000025597930000
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
While the expected printout looks like this:
A(1), this = 000002C903E10000
f: this = 000002C903E10000, val = 1
f: this = 000002C903E10000, val = 1
~A, this = 000002C903E10000, val = 1
Reapplying with the XFAIL pattern expanded to include PS4/PS5
triples as well, which also seem to have the same behaviour
as MSVC.
This reverts commit 3bc056d5f0ebe9e4074afa088c3a0355f9ab901a.
This broke on bots with a target triple of x86_64-sie-ps5,
which also appear to behave like the MSVC case.
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as
the printout looks like this:
A(1), this = 0000025597930000
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
While the expected printout looks like this:
A(1), this = 000002C903E10000
f: this = 000002C903E10000, val = 1
f: this = 000002C903E10000, val = 1
~A, this = 000002C903E10000, val = 1
Disable internal linkage for const variables if IncrementalExtensions
are enabled. Otherwise the variables are emitted multiple times, with
multiple constructions at unique memory locations, during every PTU.
Member functions and static variable definitions may use typedefs that
are private in the global context, but fine in the class context.
Differential Revision: https://reviews.llvm.org/D157838
An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizations stripped it from the Module. The added test case
shows the problem; before this patch, it would fail with:
Symbols not found: [ _ZN1AD0Ev, _ZN1AD1Ev ]
This reapplies commit f8dadefd4a, reverted in commit 0e17372b38, but
disables RTTI in the test to avoid problems on Windows.
Differential Revision: https://reviews.llvm.org/D156537
An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizations stripped it from the Module. The added test case
shows the problem; before this patch, it would fail with:
Symbols not found: [ _ZN1AD0Ev, _ZN1AD1Ev ]
Differential Revision: https://reviews.llvm.org/D156537
A double colon starts an identifier name in the global namespace and
must be tentatively parsed as such.
Differential Revision: https://reviews.llvm.org/D157480
This test case was fixed in commit 2c4620c1 ("Consider the scope spec
in template lookups for deduction guides."), but it is worth having a
dedicated test case with a templated struct and a using declaration.
Differential Revision: https://reviews.llvm.org/D157477
CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.
Differential Revision: https://reviews.llvm.org/D146389
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D150761
This patch allows the users to use backslash to tell clang-repl that more input
is coming. This would help support OpenMP directives which generally require to
be in separate lines.
CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.
Differential Revision: https://reviews.llvm.org/D146389
isDeductionGuideName looks up the underlying template and if the template name
is qualified we miss that qualification resulting in an error. This issue
resurfaced in clang-repl where we call isDeductionGuideName more often to
distinguish between if we had a statement or declaration.
This patch passes the CXXScopeSpec information down to LookupTemplateName to
make the lookup more precise.
Differential revision: https://reviews.llvm.org/D147319
Non-incremental Clang can also exit with the WeakRefReferences not empty upon
such example. This patch makes clang-repl consistent to what Clang does.
Differential revision: https://reviews.llvm.org/D148435
