Skip to content

[clang-repl] Refactor locking of runtime PTU stack (NFC) #84176

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

weliveindetail
Copy link
Member

The previous implementation seemed hacky, because it required the reader to be familiar with the internal workings of the PTU stack. The concept itself is a pragmatic solution and not very surprising. Keeping it behind a finalization call seems reasonable.

@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Mar 6, 2024
@llvmbot
Copy link
Member

llvmbot commented Mar 6, 2024

@llvm/pr-subscribers-clang

Author: Stefan Gränitz (weliveindetail)

Changes

The previous implementation seemed hacky, because it required the reader to be familiar with the internal workings of the PTU stack. The concept itself is a pragmatic solution and not very surprising. Keeping it behind a finalization call seems reasonable.


Full diff: https://github.com/llvm/llvm-project/pull/84176.diff

2 Files Affected:

  • (modified) clang/include/clang/Interpreter/Interpreter.h (+1)
  • (modified) clang/lib/Interpreter/Interpreter.cpp (+8-4)
diff --git a/clang/include/clang/Interpreter/Interpreter.h b/clang/include/clang/Interpreter/Interpreter.h
index 292fa566ae7037..ce46aefe08a475 100644
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ b/clang/include/clang/Interpreter/Interpreter.h
@@ -139,6 +139,7 @@ class Interpreter {
 
 private:
   size_t getEffectivePTUSize() const;
+  void finalizeInitPTUStack();
 
   bool FindRuntimeInterface();
 
diff --git a/clang/lib/Interpreter/Interpreter.cpp b/clang/lib/Interpreter/Interpreter.cpp
index 9f97a3c6b0be9e..e06ab45fc6fa0d 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -278,15 +278,14 @@ Interpreter::create(std::unique_ptr<CompilerInstance> CI) {
   if (Err)
     return std::move(Err);
 
+  // Runtimes contain essential definitions that are irrevocable. Lock their
+  // stack of initial PTUs to make them unavailable for undo.
   auto PTU = Interp->Parse(Runtimes);
   if (!PTU)
     return PTU.takeError();
+  Interp->finalizeInitPTUStack();
 
   Interp->ValuePrintingInfo.resize(4);
-  // FIXME: This is a ugly hack. Undo command checks its availability by looking
-  // at the size of the PTU list. However we have parsed something in the
-  // beginning of the REPL so we have to mark them as 'Irrevocable'.
-  Interp->InitPTUSize = Interp->IncrParser->getPTUs().size();
   return std::move(Interp);
 }
 
@@ -343,6 +342,11 @@ const ASTContext &Interpreter::getASTContext() const {
   return getCompilerInstance()->getASTContext();
 }
 
+void Interpreter::finalizeInitPTUStack() {
+  assert(!InitPTUSize && "We only do this once");
+  InitPTUSize = IncrParser->getPTUs().size();
+}
+
 size_t Interpreter::getEffectivePTUSize() const {
   std::list<PartialTranslationUnit> &PTUs = IncrParser->getPTUs();
   assert(PTUs.size() >= InitPTUSize && "empty PTU list?");

@vgvassilev
Copy link
Contributor

This looks reasonable to me. Is it worth to add some tests?

Copy link
Member Author

@weliveindetail weliveindetail left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes sure! It requires access to the interface, but IMHO that makes a lot of sense anyway.


auto NumBuiltinPTUs = Interp->getEffectivePTUSize();
cantFail(Interp->Parse("void firstRuntimePTU() {}"));
EXPECT_EQ(NumBuiltinPTUs + 1, Interp->getEffectivePTUSize());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn’t using the public interpreter::Undo indirectly achieve the same effect? If it errors out we will know the size of the builtin PTUs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's right. In fact, we could just not expose it right now and instead keep this a NFC. Then we don't need a new test either.

The previous implementation seemed hacky, because it required the reader to be familiar with the internal workings of the PTU stack. The concept itself is a pragmatic solution and not very surprising. Keeping it behind a finalization call seems reasonable.
@weliveindetail weliveindetail force-pushed the clang-repl-refactor-finalize-init-ptu-stack branch from 6aa4f90 to ebf00ec Compare March 7, 2024 22:49
Copy link
Member Author

@weliveindetail weliveindetail left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebased and reduced to refactoring NFC


auto NumBuiltinPTUs = Interp->getEffectivePTUSize();
cantFail(Interp->Parse("void firstRuntimePTU() {}"));
EXPECT_EQ(NumBuiltinPTUs + 1, Interp->getEffectivePTUSize());
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's right. In fact, we could just not expose it right now and instead keep this a NFC. Then we don't need a new test either.

@weliveindetail weliveindetail merged commit aec9283 into llvm:main Mar 11, 2024
@weliveindetail weliveindetail deleted the clang-repl-refactor-finalize-init-ptu-stack branch March 11, 2024 13:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema" clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants