@@ -407,6 +406,16 @@ void IncrementalParser::CleanUpPTU(PartialTranslationUnit
) {
}
}
}
+
+ // FIXME: We should de-allocate MostRecentTU
+ for (Decl *D : MostRecentTU->decls()) {
+if (!isa(D))
+ continue;
+// Check if we need to clean up the
weliveindetail wrote:
> The Unix pre-merge seems okay, however the windows pre-merge check is doing
> nothing for more than 12h.
Yeah same here. I recognized that Windows PR checks are running Flang
regression tests now. I guess that adds a huge load on the builders and causes
the delays.
@@ -407,6 +406,16 @@ void IncrementalParser::CleanUpPTU(PartialTranslationUnit
) {
}
}
}
+
+ // FIXME: We should de-allocate MostRecentTU
+ for (Decl *D : MostRecentTU->decls()) {
+if (!isa(D))
+ continue;
+// Check if we need to clean up the
https://github.com/weliveindetail edited
https://github.com/llvm/llvm-project/pull/89804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail commented:
I am not an expert on the behavior of IdResolver, but this patch works for me.
https://github.com/llvm/llvm-project/pull/89804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,21 @@
+// REQUIRES: host-supports-jit
+// UNSUPPORTED: system-aix
+
+// RUN: cat %s | clang-repl -Xcc -xc -Xcc -Xclang -Xcc -verify | FileCheck %s
+// RUN: cat %s | clang-repl -Xcc -xc -Xcc -O2 -Xcc -Xclang -Xcc -verify|
FileCheck %s
+int printf(const char *, ...);
https://github.com/weliveindetail edited
https://github.com/llvm/llvm-project/pull/89879
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail approved this pull request.
I assume the return code is supposed to reflect only frontend errors? (See my
note inline.) From reading the test it's not obvious what is interactive mode
and what is non-interactive/batch mode. Might be worth a note. Otherwise,
@@ -241,18 +243,13 @@ int main(int argc, const char **argv) {
break;
}
if (Input == R"(%undo)") {
-if (auto Err = Interp->Undo()) {
+if (auto Err = Interp->Undo())
llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "error:
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/89734
From 085a93919d8f65419cc856fe5584c83d3eceb142 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Tue, 23 Apr 2024 12:23:11 +0200
Subject: [PATCH 1/3] [clang-repl] Add test for explicit
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/89734
From 085a93919d8f65419cc856fe5584c83d3eceb142 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Tue, 23 Apr 2024 12:23:11 +0200
Subject: [PATCH 1/2] [clang-repl] Add test for explicit
weliveindetail wrote:
FYI: The run on the Windows bot failed even though tests worked as expected. In
particular, all `ClangReplInterpreterTests` unittests passed as well as all
`Interpreter` LIT tests. I could land this towards the end of the week.
@@ -0,0 +1,13 @@
+// UNSUPPORTED: system-aix
+
+// RUN: cat %s | clang-repl | FileCheck %s
+int *x = new int();
+template struct GuardX { T * GuardX(T *) : x(x) {}; ~GuardX();
};
+template GuardX::~GuardX() { delete x; x = nullptr; }
+
+// clang would normally defer codegen
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/89734
This patch adds test coverage for an edge case that is supported already.
From 085a93919d8f65419cc856fe5584c83d3eceb142 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Tue, 23 Apr
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84758
From 7ee5d29f69daf626a4fdc2fced802fe7e881f31e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Sun, 10 Mar 2024 18:17:48 +0100
Subject: [PATCH 1/4] [clang-repl] Set up executor
weliveindetail wrote:
Taking this patch would mean that deriving from Interpreter won't hold as the
mechanism for extensions! At least for customizing the JITBuilder. I propose to
pass the `LLJITBuilder` to the constructor then and to store it as a member for
later `Create/ResetExecutor()`
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84758
From 7ee5d29f69daf626a4fdc2fced802fe7e881f31e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Sun, 10 Mar 2024 18:17:48 +0100
Subject: [PATCH 1/3] [clang-repl] Set up executor
weliveindetail wrote:
> https://github.com/llvm/llvm-project/pull/89031 should unblock this PR.
@vgvassilev It did. And it uncovered an issue that I didn't think about before:
If we set up the executor in the constructor, then the interpreter instance
isn't fully initialized yet when we
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84758
From 7ee5d29f69daf626a4fdc2fced802fe7e881f31e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Sun, 10 Mar 2024 18:17:48 +0100
Subject: [PATCH 1/2] [clang-repl] Set up executor
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/87066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
weliveindetail wrote:
Possible, but might add limitations. The init process can be complex. I could
imagine a runtime to require actual execution of code (and not only parsing as
we'd implement it right now I guess) or load a dynamic library. The patch here
allows that, the constructor
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/87066
None
From 1835e627203ece2e81787d6167ccc15b62c31f36 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Fri, 29 Mar 2024 13:37:36 +0100
Subject: [PATCH] [clang-repl] Minor cleanups in
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/87064
Adding code for built-in functionality during initialization is very common.
Call this function afterwards to hide it from Undo. Any serious interpreter
needs it.
From
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/85378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
weliveindetail wrote:
@amy-kwan Thanks for your note and sorry for the long delay. There were so many
unrelated buildbot failures today, that I didn't catch this one. I think it was
fixed meanwhile with
https://github.com/llvm/llvm-project/commit/cb994d41c3afb2bd0b25a4c5b2ac48978bf1b23d
weliveindetail wrote:
We do need the target and not just the symbols. It could be any non-native
target, but implementing a selection mechanism isn't worth the effort. We just
try ARM and (with my above patch) otherwise skip the test.
https://github.com/llvm/llvm-project/pull/84461
Author: Stefan Gränitz
Date: 2024-03-25T11:50:21+01:00
New Revision: 13078cbc3eeb0ae91c370ce0f604f7165b26e0c8
URL:
https://github.com/llvm/llvm-project/commit/13078cbc3eeb0ae91c370ce0f604f7165b26e0c8
DIFF:
weliveindetail wrote:
I will try this
https://github.com/llvm/llvm-project/blob/release/18.x/llvm/unittests/DebugInfo/LogicalView/CodeViewReaderTest.cpp#L482
and push a quick-fix.
https://github.com/llvm/llvm-project/pull/84461
___
cfe-commits
weliveindetail wrote:
Thanks for your note. Looks like the problem is that the ARM target is not
registered. It's an uncommon requirement for a unitttest.. Will see how to
check that at runtime. If you have an idea, let me know. Thanks
https://github.com/llvm/llvm-project/pull/84461
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/84461
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/86118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
weliveindetail wrote:
Windows buildbot failure is unrelated. This code is covered in unittest
ClangReplInterpreterTests and it passed.
https://github.com/llvm/llvm-project/pull/86118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
weliveindetail wrote:
Let's give the pre-merge checks a 2nd chance..
https://github.com/llvm/llvm-project/pull/86118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/86118
From 0b7f4bc8bf57219f5f1e5ffa06c986beb16b9546 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Thu, 21 Mar 2024 14:04:10 +0100
Subject: [PATCH 1/3] Add reproducer
---
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84461
From fae2f46d25650b8480f9d3135f33a0d6532f43ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Thu, 7 Mar 2024 23:04:22 +0100
Subject: [PATCH 1/2] [clang-repl] Add CreateJITBuilder()
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84461
From fae2f46d25650b8480f9d3135f33a0d6532f43ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Thu, 7 Mar 2024 23:04:22 +0100
Subject: [PATCH] [clang-repl] Add CreateJITBuilder() for
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/86118
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`.
From
@@ -375,16 +375,22 @@ void IncrementalParser::CleanUpPTU(PartialTranslationUnit
) {
TranslationUnitDecl *MostRecentTU = PTU.TUPart;
TranslationUnitDecl *FirstTU = MostRecentTU->getFirstDecl();
if (StoredDeclsMap *Map = FirstTU->getPrimaryContext()->getLookupPtr()) {
-
@@ -375,16 +375,22 @@ void IncrementalParser::CleanUpPTU(PartialTranslationUnit
) {
TranslationUnitDecl *MostRecentTU = PTU.TUPart;
TranslationUnitDecl *FirstTU = MostRecentTU->getFirstDecl();
if (StoredDeclsMap *Map = FirstTU->getPrimaryContext()->getLookupPtr()) {
-
@@ -205,7 +205,7 @@ class StoredDeclsList {
Data.setPointer(Head);
}
- /// Return an array of all the decls that this list represents.
+ /// Return the list of all the decls.
weliveindetail wrote:
This is not an array (otherwise we could have done
@@ -375,16 +375,22 @@ void IncrementalParser::CleanUpPTU(PartialTranslationUnit
) {
TranslationUnitDecl *MostRecentTU = PTU.TUPart;
TranslationUnitDecl *FirstTU = MostRecentTU->getFirstDecl();
if (StoredDeclsMap *Map = FirstTU->getPrimaryContext()->getLookupPtr()) {
-
https://github.com/weliveindetail commented:
Two minor remarks
https://github.com/llvm/llvm-project/pull/85378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail edited
https://github.com/llvm/llvm-project/pull/85378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/85378
From 6fbd6e36133af7af008c84a1a2e44c243aed26be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Fri, 15 Mar 2024 11:01:09 +0100
Subject: [PATCH 1/2] [clang-repl] Fix assertion failure
weliveindetail wrote:
I can reproduce it downstream in the implicit Undo after including a header
that causes a lot of parse errors in nested headers. I am afraid it's
unpractical to emulate in the test suite upstream.
The code is exercised in all Undo tests. They don't reproduce the issue
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/85378
This assertion failure is one (fortunate) symptom:
```
clang/include/clang/AST/DeclBase.h:1337: reference
clang::DeclListNode::iterator::operator*() const: Assertion `Ptr &&
"dereferencing end()
weliveindetail wrote:
This should fix both: initializing the native target (your reported case) AND
skipping the test on platforms that don't support JIT (other build bots
complained).
https://github.com/llvm/llvm-project/pull/84460
___
cfe-commits
Author: Stefan Gränitz
Date: 2024-03-12T23:14:23+01:00
New Revision: d73c2d5df21735805a1f46a85790db64c0615e1c
URL:
https://github.com/llvm/llvm-project/commit/d73c2d5df21735805a1f46a85790db64c0615e1c
DIFF:
weliveindetail wrote:
Yes, I think I can fix it quickly
https://github.com/llvm/llvm-project/pull/84460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Stefan Gränitz
Date: 2024-03-12T14:47:23+01:00
New Revision: ffd31c5e92da9da37cf57ca653e22db38b5af9a3
URL:
https://github.com/llvm/llvm-project/commit/ffd31c5e92da9da37cf57ca653e22db38b5af9a3
DIFF:
weliveindetail wrote:
Build bot https://lab.llvm.org/buildbot/#/builders/196/builds/46799 detected an
issue with the test -- I will try and push a fix quickly:
```
https://github.com/weliveindetail edited
https://github.com/llvm/llvm-project/pull/84461
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84461
From 88271c39b30b84041b4b7fb8b8f34c211d8190d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Thu, 7 Mar 2024 23:04:22 +0100
Subject: [PATCH] [clang-repl] Add CreateJITBuilder() for
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/84460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84460
From a8c9cf8901d3fc24f3a2c2161b4a8796a7b28989 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Thu, 7 Mar 2024 23:04:22 +0100
Subject: [PATCH] [clang-repl] Expose CreateExecutor()
@@ -14,7 +14,7 @@ struct A { int a; A(int a) : a(a) {} virtual ~A(); };
// PartialTranslationUnit.
inline A::~A() { printf("~A(%d)\n", a); }
-// Create one instance with new and delete it.
+// Create one instance with new and delete it. We crash here now:
A *a1 = new A(1);
@@ -14,7 +14,7 @@ struct A { int a; A(int a) : a(a) {} virtual ~A(); };
// PartialTranslationUnit.
inline A::~A() { printf("~A(%d)\n", a); }
-// Create one instance with new and delete it.
+// Create one instance with new and delete it. We crash here now:
A *a1 = new A(1);
@@ -14,7 +14,7 @@ struct A { int a; A(int a) : a(a) {} virtual ~A(); };
// PartialTranslationUnit.
inline A::~A() { printf("~A(%d)\n", a); }
-// Create one instance with new and delete it.
+// Create one instance with new and delete it. We crash here now:
A *a1 = new A(1);
weliveindetail wrote:
> > Do you mind incorporating this patch so that we avoid churn?
>
> Sure. Essentially, this drops lazy creation of the executor and makes it
> dependent on the frontend action explicitly. Fine for me. We can still expose
> explicit setup/tear-down.
@vgvassilev I moved
https://github.com/weliveindetail edited
https://github.com/llvm/llvm-project/pull/84758
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/84758
Until now the IncrExecutor is created lazily on the first execution request. In
order to process the PTUs that come from initialization, we have to do it
upfront implicitly.
From
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/84176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/83126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84460
From 10f8d3eb040a5838d84d8a84fe636c7c2a7d196b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Fri, 8 Mar 2024 00:08:56 +0100
Subject: [PATCH 1/3] [clang-repl] Expose
weliveindetail wrote:
> Do you mind incorporating this patch so that we avoid churn?
Sure. Essentially, this drops lazy creation of the executor and makes it
dependent on the frontend action explicitly. Fine for me. We can still expose
explicit setup/tear-down.
@@ -102,4 +124,97 @@ TEST(InterpreterExtensionsTest, FindRuntimeInterface) {
EXPECT_EQ(1U, Interp.RuntimeIBPtr->TransformerQueries);
}
+class CustomJBInterpreter : public Interpreter {
+ using CustomJITBuilderCreatorFunction =
+
std::function>()>;
+
@@ -102,4 +124,97 @@ TEST(InterpreterExtensionsTest, FindRuntimeInterface) {
EXPECT_EQ(1U, Interp.RuntimeIBPtr->TransformerQueries);
}
+class CustomJBInterpreter : public Interpreter {
+ using CustomJITBuilderCreatorFunction =
+
std::function>()>;
+
https://github.com/weliveindetail edited
https://github.com/llvm/llvm-project/pull/84461
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail commented:
This PR depends on two predecessor patches, but I wanted to share it for review
already. For the moment please refer to the single commit in
https://github.com/llvm/llvm-project/pull/84461/commits/cc46034e5288ba54dfc8a0ea7d54792cbb99227d
for
@@ -373,21 +373,32 @@ Interpreter::Parse(llvm::StringRef Code) {
static llvm::Expected
createJITTargetMachineBuilder(const std::string ) {
if (TT == llvm::sys::getProcessTriple())
+// This fails immediately if the target backend is not registered
return
weliveindetail wrote:
This PR was factored out for isolated review and to reduce the size of the
follow-up patch in https://github.com/llvm/llvm-project/pull/84461. It depends
on the previous change in https://github.com/llvm/llvm-project/pull/83126.
Combined patch size will shrink
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/84461
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
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/84460
IncrementalExecutor is an implementation detail of the Interpreter. In order to
test extended features properly, we must be able to setup and tear down the
executor manually.
From
weliveindetail wrote:
Squashed, rebased, polished and tested
https://github.com/llvm/llvm-project/pull/83126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/83126
From 8ba5253b20d1aef0a542506a667f6b66b84ac5b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Fri, 8 Mar 2024 00:08:56 +0100
Subject: [PATCH] [clang-repl] Expose
@@ -137,9 +136,10 @@ class Interpreter {
Expr *SynthesizeExpr(Expr *E);
-private:
size_t getEffectivePTUSize() const;
+ void finalizeInitPTUStack();
weliveindetail wrote:
Yes, sounds goo. Done
https://github.com/llvm/llvm-project/pull/84176
@@ -136,6 +136,24 @@ TEST(InterpreterTest, DeclsAndStatements) {
EXPECT_TRUE(!!R2);
}
+TEST(InterpreterTest, PTUStack) {
+ clang::IncrementalCompilerBuilder CB;
+ auto CI = cantFail(CB.CreateCpp());
+
+ llvm::Error Err = llvm::Error::success();
+ auto Interp =
https://github.com/weliveindetail commented:
Rebased and reduced to refactoring NFC
https://github.com/llvm/llvm-project/pull/84176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail edited
https://github.com/llvm/llvm-project/pull/84176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84176
From ebf00ec8396eabf96c413e861b72ff1c88424685 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Wed, 6 Mar 2024 12:37:50 +0100
Subject: [PATCH] [clang-repl] Refactor locking of
Author: Stefan Gränitz
Date: 2024-03-07T23:15:02+01:00
New Revision: 2a4a852a67eab2f8d0533c23719b1bd08d6edea9
URL:
https://github.com/llvm/llvm-project/commit/2a4a852a67eab2f8d0533c23719b1bd08d6edea9
DIFF:
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/84150
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/84261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/84261
Reverts llvm/llvm-project#84174 due too sanitizer memory leak detection
From efe6097aad69aba7d2421880305198bf09226db6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Thu, 7 Mar
weliveindetail wrote:
Interesting, thanks for reporting! It's this code:
```
llvm::MemoryBuffer *MB = llvm::MemoryBuffer::getMemBuffer("").release();
Clang->getPreprocessorOpts().addRemappedFile("<<< inputs >>>", MB);
```
Apparently, it is related to releasing the MemBuffer and passing the
@@ -137,9 +136,10 @@ class Interpreter {
Expr *SynthesizeExpr(Expr *E);
-private:
weliveindetail wrote:
> We can befriend the test to the interpreter.
I don't think we can do this:
```
// Defines FRIEND_TEST.
#include
```
> make this `protected:` and
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/84174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
weliveindetail wrote:
Thanks for the quick feedback and review!
https://github.com/llvm/llvm-project/pull/84174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -137,9 +136,10 @@ class Interpreter {
Expr *SynthesizeExpr(Expr *E);
-private:
size_t getEffectivePTUSize() const;
+ void finalizeInitPTUStack();
weliveindetail wrote:
Hm, why restore point? Do you mean sth like `markMaxRestorePoint` as in "the
@@ -137,9 +136,10 @@ class Interpreter {
Expr *SynthesizeExpr(Expr *E);
-private:
weliveindetail wrote:
Ok, let me play with it a little more.
https://github.com/llvm/llvm-project/pull/84176
___
cfe-commits
@@ -41,3 +40,23 @@ for (; i > 4; --i) { printf("i = %d\n", i); };
int j = i; printf("j = %d\n", j);
// CHECK-NEXT: j = 4
+
+{++i; printf("i = %d (global scope)\n", i);}
+// CHECK-NEXT: i = 5
+
+while (int i = 1) { printf("i = %d (while condition)\n", i--); break; }
+//
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84150
From 27ff0ddc0d736f4959abe61c9fd43b9c48ffb6a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Wed, 28 Feb 2024 15:45:53 +0100
Subject: [PATCH 1/9] Add test cases for variable
@@ -137,9 +136,10 @@ class Interpreter {
Expr *SynthesizeExpr(Expr *E);
-private:
size_t getEffectivePTUSize() const;
+ void finalizeInitPTUStack();
weliveindetail wrote:
We could also consider renaming this to `getNumUndoSteps()` and
https://github.com/weliveindetail commented:
Yes sure! It requires access to the interface, but IMHO that makes a lot of
sense anyway.
https://github.com/llvm/llvm-project/pull/84176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/weliveindetail edited
https://github.com/llvm/llvm-project/pull/84176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84176
From 143ed8ccf592be46181fb3dcd814b4afa1b39833 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Wed, 6 Mar 2024 12:37:50 +0100
Subject: [PATCH 1/2] [clang-repl] Refactor locking of
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84174
From 0d7f6a8e72caeada251c661f5804d9766345e052 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Wed, 6 Mar 2024 16:46:56 +0100
Subject: [PATCH] [clang-repl] Pass triple to
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/84174
With out-of-process execution the target triple can be different from the one
on the host. We need an interface to configure it.
From 767fccd9b2f5badee46aaf8ab9cca5315c538720 Mon Sep 17 00:00:00 2001
weliveindetail wrote:
Thanks! Added `while` with empty body as well as `switch`. Refined test output
a bit, so that it now prints:
```
i = 5 (global scope)
i = 1 (while condition)
i = 2 (if condition)
i = 3 (switch condition)
i = 4 (for-init)
```
https://github.com/llvm/llvm-project/pull/84150
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/84150
From 27ff0ddc0d736f4959abe61c9fd43b9c48ffb6a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Wed, 28 Feb 2024 15:45:53 +0100
Subject: [PATCH 1/7] Add test cases for variable
1 - 100 of 150 matches
Mail list logo
