[clang-repl]

[aadanen]

Hi all. This is my first pull request to an open source project. I am a student so have mercy on me!

I have done my best to read all of the relevant documentation about how to contribute most effectively but its totally possible I've made a mistake or missed something. Please let me know so I can do better next time :)

I found a simple issue and have done my best to resolve it. I believe this change resolves #143668

All i did was grep -r "Too many undos" and replace all instances of that string with the suggested replacement.

thank you for your time
aadanen

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Aaron Danen (aadanen)

Changes

Hi all. This is my first pull request to an open source project. I am a student so have mercy on me!

I have done my best to read all of the relevant documentation about how to contribute most effectively but its totally possible I've made a mistake or missed something. Please let me know so I can do better next time :)

I found a simple issue and have done my best to resolve it. I believe this change resolves #143668

All i did was grep -r "Too many undos" and replace all instances of that string with the suggested replacement.

thank you for your time
aadanen

---

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

2 Files Affected:

• (modified) clang/lib/Interpreter/Interpreter.cpp (+1-1)
• (modified) clang/unittests/Interpreter/InterpreterTest.cpp (+2-2)

diff --git a/clang/lib/Interpreter/Interpreter.cpp b/clang/lib/Interpreter/Interpreter.cpp
index ed3bae59a144c..a2696f78cb510 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -754,7 +754,7 @@ llvm::Error Interpreter::Undo(unsigned N) {
 
   if (N > getEffectivePTUSize())
     return llvm::make_error<llvm::StringError>("Operation failed. "
-                                               "Too many undos",
+                                               "No input left to undo",
                                                std::error_code());
   for (unsigned I = 0; I < N; I++) {
     if (IncrExecutor) {
diff --git a/clang/unittests/Interpreter/InterpreterTest.cpp b/clang/unittests/Interpreter/InterpreterTest.cpp
index b97f5ae17c9f0..2ec65e2a9b2ef 100644
--- a/clang/unittests/Interpreter/InterpreterTest.cpp
+++ b/clang/unittests/Interpreter/InterpreterTest.cpp
@@ -158,12 +158,12 @@ TEST_F(InterpreterTest, UndoCommand) {
 
   // Fail to undo.
   auto Err1 = Interp->Undo();
-  EXPECT_EQ("Operation failed. Too many undos",
+  EXPECT_EQ("Operation failed. No input left to undo",
             llvm::toString(std::move(Err1)));
   auto Err2 = Interp->Parse("int foo = 42;");
   EXPECT_TRUE(!!Err2);
   auto Err3 = Interp->Undo(2);
-  EXPECT_EQ("Operation failed. Too many undos",
+  EXPECT_EQ("Operation failed. No input left to undo",
             llvm::toString(std::move(Err3)));
 
   // Succeed to undo.

[DavidSpickett]

Hi all. This is my first pull request to an open source project. I am a student so have mercy on me!

Welcome!

All i did was grep -r "Too many undos" and replace all instances of that string with the suggested replacement.

Simple and effective but, there is a little bit more context in this case, which I'll explain in a review comment in a moment.

Some admin stuff:

• We prefer that PRs (which become git commits) have a title of the form "[some project tags] ". So in this case I did git log -- clang/lib/Interpreter/Interpreter.cpp and concluded that it's probably [clang-repl]. This isn't some machine enforced thing, it just helps us humans recognise the changes later in logs and emails.
• The PR description will become the git commit's message (this is a setting GitHub allows projects to change, so you may see it work other ways in other projects). Which means that the PR description is more commit message, less cover letter. What I tend to do is put that sort of thing in a new comment.

Having said that, I think you'll be better able to describe the change once we've gone through some review. So leave both of those as is, for now, and we'll make sure they're ok later.

Another thing that you may not have had to do for the change as is, but will when I explain a bit more, is run the tests locally. So if you haven't already, follow https://llvm.org/docs/GettingStarted.html and get to the point where you can build clang. From there you can either use ninja check-clang or ninja check-clang-unit. The latter is just a specific subset of tests, which does cover what you're modifying here.

In addition to that, our CI will be running tests for you but it is much more useful to have them running locally so your edit -> run -> edit loop can be faster.

[github-actions]

⚠️ We detected that you are using a GitHub private e-mail address to contribute to the repo.
Please turn off Keep my email addresses private setting in your account.
See LLVM Developer Policy and LLVM Discourse for more information.

[DavidSpickett]

The complication here is that although the clang-repl %undo only undoes one input, the internal method can actually undo more than that. This test for example is trying to undo 2 things.

So the code needs to be a bit more intelligent. You have two situations:

• You have nothing left to undo.
• You have some things left to undo but want to undo more than that.

In both cases you error because you don't want to partially undo something, but the message should be specific. In the same order as above, I suggest:

• "No input left to undo"
• "Wanted to undo X inputs, only have Y" (with the message formatted with the correct numbers)

For formatting the error, we have some utilities to do that, I will find those for you.

Side note: "inputs" might not be the right noun, but stick with it for now and we can ask a clang-repl maintainer whether it's ok.

[DavidSpickett]

I guess that the internal method can undo more than one input because you might be piping many lines at once into clang-repl? Anyway it's there so we should assume it is there for a good reason.

[DavidSpickett]

llvm-project/lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp

Line 338 in d883d5f

return llvm::make_error<llvm::StringError>(

is an example of formatting an error message.

If you've seen Python's format strings, it works like those, automatically figuring out what the type of the parameters are so that you don't have to %<something> each time like in printf. There's a bit more explanation in https://llvm.org/doxygen/FormatVariadic_8h_source.html but searching for other uses of it will be more informative than the formal grammar of it.

[DavidSpickett]

#149396 (comment) is one of our automated checks, please follow its guidance. The reason we do this is so we can attribute changes for reasons around the licensing of contributions, there's more info in those links. It can be any valid address, you don't have to use a "personal" one, for instance I use my email address provided by my employer (that and they require that I do, but beside the point).

[aadanen]

1. I am able to build clang, compile the project, and I am currently running the "ninja check-clang-unit" tests. Although it does take an incredibly long time ( 45 minutes to an hour) but that's off topic

2. I attached my email

3. I think I understand what you're describing as far as how the code should be smarter. I will investigate and try to figure out where that edit will take place.

4. some of the commits in this PR are me updating the branch with changes to the main branch. I think its okay because this whole thing will get squashed at the end but just checking

[aadanen]

I put in inputs vs undo requests logic but I think the unit test might need to be edited as well