release/20.x: [clang-repl] Fix error recovery while PTU cleanup (#127467) #142445
Conversation
Fixes llvm#123300 What is seen ``` clang-repl> int x = 42; clang-repl> auto capture = [&]() { return x * 2; }; In file included from <<< inputs >>>:1: input_line_4:1:17: error: non-local lambda expression cannot have a capture-default 1 | auto capture = [&]() { return x * 2; }; | ^ zsh: segmentation fault clang-repl --Xcc="-v" (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) * frame #0: 0x0000000107b4f8b8 libclang-cpp.19.1.dylib`clang::IncrementalParser::CleanUpPTU(clang::PartialTranslationUnit&) + 988 frame #1: 0x0000000107b4f1b4 libclang-cpp.19.1.dylib`clang::IncrementalParser::ParseOrWrapTopLevelDecl() + 416 frame #2: 0x0000000107b4fb94 libclang-cpp.19.1.dylib`clang::IncrementalParser::Parse(llvm::StringRef) + 612 frame #3: 0x0000000107b52fec libclang-cpp.19.1.dylib`clang::Interpreter::ParseAndExecute(llvm::StringRef, clang::Value*) + 180 frame #4: 0x0000000100003498 clang-repl`main + 3560 frame #5: 0x000000018d39a0e0 dyld`start + 2360 ``` Though the error is justified, we shouldn't be interested in exiting through a segfault in such cases. The issue is that empty named decls weren't being taken care of resulting into this assert https://github.com/llvm/llvm-project/blob/c1a229252617ed58f943bf3f4698bd8204ee0f04/clang/include/clang/AST/DeclarationName.h#L503 Can also be seen when the example is attempted through xeus-cpp-lite.  (cherry picked from commit 3b4c51b)
|
@vgvassilev What do you think about merging this PR to the release branch? |
llvmbot
added
clang
|
@llvm/pr-subscribers-clang Author: None (llvmbot) ChangesBackport 3b4c51b Requested by: @anutosh491 Full diff: https://github.com/llvm/llvm-project/pull/142445.diff 2 Files Affected:
diff --git a/clang/lib/Interpreter/IncrementalParser.cpp b/clang/lib/Interpreter/IncrementalParser.cpp
index e43cea1baf43a..1d223e230669c 100644
--- a/clang/lib/Interpreter/IncrementalParser.cpp
+++ b/clang/lib/Interpreter/IncrementalParser.cpp
@@ -175,7 +175,7 @@ void IncrementalParser::CleanUpPTU(TranslationUnitDecl *MostRecentTU) {
// FIXME: We should de-allocate MostRecentTU
for (Decl *D : MostRecentTU->decls()) {
auto *ND = dyn_cast<NamedDecl>(D);
- if (!ND)
+ if (!ND || ND->getDeclName().isEmpty())
continue;
// Check if we need to clean up the IdResolver chain.
if (ND->getDeclName().getFETokenInfo() && !D->getLangOpts().ObjC &&
diff --git a/clang/test/Interpreter/lambda.cpp b/clang/test/Interpreter/lambda.cpp
index df75274a050b2..7e5e1057e4c9e 100644
--- a/clang/test/Interpreter/lambda.cpp
+++ b/clang/test/Interpreter/lambda.cpp
@@ -1,7 +1,8 @@
// REQUIRES: host-supports-jit
// UNSUPPORTED: system-aix
// RUN: cat %s | clang-repl | FileCheck %s
-// RUN: cat %s | clang-repl -Xcc -O2 | FileCheck %s
+// RUN: cat %s | clang-repl -Xcc -Xclang -Xcc -verify -Xcc -O2 | FileCheck %s
+
extern "C" int printf(const char *, ...);
auto l1 = []() { printf("ONE\n"); return 42; };
@@ -14,4 +15,14 @@ auto r2 = l2();
auto r3 = l2();
// CHECK: TWO
-%quit
+// Verify non-local lambda capture error is correctly reported
+int x = 42;
+
+// expected-error {{non-local lambda expression cannot have a capture-default}}
+auto capture = [&]() { return x * 2; };
+
+// Ensure interpreter continues and x is still valid
+printf("x = %d\n", x);
+// CHECK: x = 42
+
+%quit
\ No newline at end of file
|
|
cc @DavidSpickett , I executed a cherry pick on my patch to move it into the next release. Haven't had the time to go through the issue you discovered on Windows but is this all we want ? Or should I change something here ? |
|
We should cherry pick beffd15 as well so that release builders don't get failures. I have confirmed it "fixes" the test on Windows on Arm and x64, and it's very unlikely that your code changes are making any difference to the output ordering. It's likely a pre-existing issue. So this PR does not need to change. |
|
Not sure how to do that given that it relies on this change. I don't think you can push more changes to this PR yourself. Could you close this and re-do the command with both commit hashes? (https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches) |
|
Are you guys saying we should merge this one and merge another one later on? |
|
Yes, we need to have the commit in this PR, and then beffd15 to prevent test failures on Windows. |
Okay in that case let's do that. |
github-project-automation
bot
moved this from Needs Review
to Needs Merge
in LLVM Release Status
|
cc @tstellar I think this should be ready now. Could you help us out here ? |
|
Was beffd15 squashed in with this commit? |
We thought we would take this in and then cherry pick that on top of this. I am not sure if the cherry pick done by the bot here can be updated in any way to also include changes from the other commit. Is that feasible ? In that case maybe we can take both in through the same pr. Not sure if it can be done manually by me though. Could you help us with the same if that's possible ? |
|
#143851 has both. |
Backport 3b4c51b
Requested by: @anutosh491