compiletest: track LLDB inputs in up-to-date checks - #160137
Conversation
|
Some changes occurred in src/tools/compiletest cc @jieyouxu |
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
There was a problem hiding this comment.
This seems potentially OK but I'd like someone more familiar with the debuginfo story we're constructing right now to take a look.
r? @jieyouxu
| stamp.add_path(&lldb_batchmode); | ||
| stamp.add_dir(&lldb_batchmode); |
There was a problem hiding this comment.
Hm, this makes me wonder if we should make add_path detect whether you're adding a directory and recursively add in that case. It's not obvious to me why you would only want to stamp the directory itself, and it seems easy to not notice that you're doing a partial stamp.
There was a problem hiding this comment.
Yeah, that feels broadly more reasonable
| let lldb_input = test_dir.join("lldb_input"); | ||
| if lldb_input.is_dir() { | ||
| inputs_stamp.add_path(&lldb_input); | ||
| inputs_stamp.add_dir(&lldb_input); |
There was a problem hiding this comment.
These files look potentially generated? E.g., looking at tests/debuginfo/basic-types/lldb_input/non_windows.json I see bless_metadata which doesn't look written by humans... maybe we should include a __comment field in those files with some annotation of what they are?
I'm not clear from the PR description that added these files (#158298) on whether they are always 'outputs' from some process or true inputs.
There was a problem hiding this comment.
They're intended to be generated (as in the JSON files). The bless metadata was intended to be a record of how the metadata was produced, and without reblessing, bless metadata shouldn't participate in the "diff" of the JSONs. I think __comment could make sense, or maybe we could try to have a bit more elaboration in r-d-g about what the general sections are for these.
cc @Kobzol too
|
|
track LLDB's shared batch mode scripts and per test
lldb_inputdata whenchecking whether debuginfo tests are up to date.
previously changing these inputs could leave a successful LLDB test marked as
up to date, so compiletest would skip it unless
--force-rerunwas used.also the test directory timestamp is also tracked so adding or removing the
lldb_inputdirectory invalidates the cached result.Tests:
python x.py fmt --checkpython x.py test src/tools/compiletest --stage 0 --set build.compiletest-allow-stage0=true