This is an archive of the discontinued LLVM Phabricator instance.

Mark the file entry invalid, until reread. Invalidate SLocEntry cache, readd it on reread. Do not use translateFile, because it pulls in parts of the pch.
Needs ReviewPublic

Authored by tapaswenipathak on May 23 2022, 7:44 PM.

Details

Summary

Mark the file entry invalid, until reread.

This patch marks the file entry invalid, until reread. Invalidates SLocEntry
cache, readd it on reread. Do not use translateFile, because it pulls
in parts of the pch.

This adds an invalidateCache success test in filemanager and
sourcemanager, using #define public private to access private member in
the test.

Some more related information is available here:
https://github.com/vgvassilev/clang/pull/2.

Co-authored-by: Vassil Vassilev <vvasilev@cern.ch>

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptMay 23 2022, 7:44 PM
Herald added a subscriber: ormris. · View Herald Transcript
tapaswenipathak requested review of this revision.May 23 2022, 7:44 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 23 2022, 7:44 PM
v.g.vassilev added a subscriber: cfe-commits.

Just to add that the invalidateCache is important for cling and clang-repl where we do something like:

clang-repl> #include "file_with_error.h"
// error is printed, we edit the file and include it again:
clang-repl> #include "file_with_error.h"

I am not sure if we can write such a test for clang-repl easily using the lit infrastructure...

fix for build failure:

cmdline: git reset --hard
stderr: 'fatal: Unable to create '/var/lib/buildkite-agent/builds/llvm-project-fork/.git/index.lock': File exists.

https://buildkite.com/llvm-project/diff-checks/builds/110904#01818451-4c05-49bb-9f93-ea6d0480f9ec

could be temporary, or could be because i didn't run a git pull for a few days.

omit an unrelated change.

git clang-format HEAD~1

After landing https://reviews.llvm.org/D126682 we might be able to write a test in clang-repl such as:

cpp
clang-repl> #include <iostream>
clang-repl> #include <fstream>
clang-repl>using namespace std;
clang-repl> int write_str (const char* str) {
  ofstream myfile;
  myfile.open ("a.h");
  myfile << str<<"\n";
  myfile.close();
  return 0;
}
clang-repl> auto r1 = write_str("int i = 42");
clang-repl> extern "C" int printf(const char*,...);
clang-repl> #include "a.h"
clang-repl> auto r2 = printf("i=%d\n", i);
clang-repl>%undo
clang-repl>%undo 
clang-repl> auto r3 = write_str("int i = 0");
clang-repl> #include "a.h"
clang-repl> auto r2 = printf("i=%d\n", i);
// Here we should print `i=0`.

Hmm, I'm concerned with the pieces added purely for testing. Specifically, FileEntriesToReread and TestHelper friend functions. Need to think how else we can test it.

Do you intend to support only the error cases like

clang-repl> #include "file_with_error.h"
// error is printed, we edit the file and include it again:
clang-repl> #include "file_with_error.h"

or do you want to handle re-including files? Something like

clang-repl> #include "experiments.h"
// edit the file and include it again:
clang-repl> #include "experiments.h"

Asking because maybe in the error case we commit to some state too eagerly and fixing that sticky eagerness is another option (just guessing, have no idea if it is an actual option and if it is "better").

Hmm, I'm concerned with the pieces added purely for testing. Specifically, FileEntriesToReread and TestHelper friend functions. Need to think how else we can test it.

I am not thrilled about that either. We have discussed this approach here https://reviews.llvm.org/D126183 and we have past experience going that route. I would be happy to drop this test in favor of the mentioned clang-repl test. Should be enough to cover the usecase.

Do you intend to support only the error cases like

clang-repl> #include "file_with_error.h"
// error is printed, we edit the file and include it again:
clang-repl> #include "file_with_error.h"

or do you want to handle re-including files? Something like

clang-repl> #include "experiments.h"
// edit the file and include it again:
clang-repl> #include "experiments.h"

Asking because maybe in the error case we commit to some state too eagerly and fixing that sticky eagerness is another option (just guessing, have no idea if it is an actual option and if it is "better").

We want both. The error case is somewhat easier to deal with. However, in case we have error in the logic in #include "experiments.h" we want to execute and then re-execute the new code.