Skip to content
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

add tidy check that forbids issue-XXXX test filenames #113583

Merged
merged 1 commit into from
Jul 26, 2023

Conversation

asquared31415
Copy link
Contributor

@asquared31415 asquared31415 commented Jul 11, 2023

Helps with #113345 by preventing any future tests with non-descriptive names from being added.

This PR only checks modified ui test files because there are far too many existing problematic tests to be fixed at once:
3063/15424 (~19.86%) *.rs ui test files match ^issue[-_ ]?\d+$.
Another 1349 files, totaling ~28.60% of all ui test files, contain that pattern in addition to some other text, where they should probably omit it in favor of a comment.

note: between the creation of this PR and 2023-07-25 (14 days), 10 more tests were added that failed this check.

r? @workingjubilee

@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jul 11, 2023
@rustbot
Copy link
Collaborator

rustbot commented Jul 11, 2023

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

@rust-log-analyzer

This comment has been minimized.

if let Some(m) = regex.find(name) {
tidy_error!(
bad,
"test file {} should not use {} in its name. link the issue in a comment in the test and use a more descriptive name for the test instead.",
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
"test file {} should not use {} in its name. link the issue in a comment in the test and use a more descriptive name for the test instead.",
"test file `{}` should not use `{}` in its name. link the issue in a comment in the test and use a more descriptive name for the test instead.",

Copy link
Member

@workingjubilee workingjubilee Jul 11, 2023

Choose a reason for hiding this comment

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

Can this be slightly clearer that it isn't the issue number that is totally forbidden from the filename, but that the filename needs to actually identify what the test is about at-a-glance, i.e. what-it-tests-issue-\d+ is acceptable, strictly speaking (if the reviewer accepts it, at least)?

Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

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

lgtm

@@ -128,4 +132,44 @@ pub fn check(path: &Path, bad: &mut bool) {
}
}
});

// Check that any test files modified don't have a useless name
for changed_file in git::get_git_modified_files(None, &vec!["rs"]).unwrap().unwrap() {
Copy link
Member

Choose a reason for hiding this comment

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

hahah unrelated but why does get_git_modified_files take a &Vec<_> :thonk:

@matthiaskrgr
Copy link
Member

Wondering if it would make sense to actually go the other way around; if a test file contains something like
https://github.com/rust-lang/rust/issues/113583 , then it MUST also contain "113583" in the filename? 🤔
(I'm a huge fan of having issue numbers in file names fwiw 😅 )

@workingjubilee
Copy link
Member

That would break on the very likely case that a test resolves two issues and thus mentions two issues. No, I am not going to tolerate tests named issues-111111-122222-123333-123444-123455-123456-stack-overflow.rs.

@Noratrieb
Copy link
Member

What purpose do numbers in filenames serve? @matthiaskrgr
I think it's way nicer to have them as a comment inside the test, it's just as searchable and doesn't clutter the name.

@matthiaskrgr
Copy link
Member

Ooh right :D but we could special case that and make sure it contains one of them in the filename?

@matthiaskrgr
Copy link
Member

@Nilstrieb when I am triaging my icemaker reports, I can see right away "issue-12345.rs" crashed with the -Zealous flag.
I then search #12345 in the issue tracker and if the results are "0 open, 1 closed" I already know that this is a new bug and can investigate further.

Its just much more useful to have the issue number right away to open the ticket and see the related discussion/status etc than having something only something like trait-as-impl-trait-ice-in-const-closure-context.rs That may or may not contain an actual link to the original issue inside.

Entering the code of the testcase in the github search does not always work because of minimization, and going through git log / git blame to find the a fixes 123 somewhere in a parent commit takes maybe 20-30 seconds which does not sound like much but it definitely adds up compares to 0.7 seconds of grabbing the issue number from the file name, especially if you try to triage 20-40 ices at a time.

@Noratrieb
Copy link
Member

you could modify your code to try to extract issue numbers from the source, I think that short work in most cases too.

src/tools/tidy/src/ui_tests.rs Outdated Show resolved Hide resolved
src/tools/tidy/src/ui_tests.rs Outdated Show resolved Hide resolved
if let Some(m) = regex.find(name) {
tidy_error!(
bad,
"test file {} should not use {} in its name. link the issue in a comment in the test and use a more descriptive name for the test instead.",
Copy link
Member

@workingjubilee workingjubilee Jul 11, 2023

Choose a reason for hiding this comment

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

Can this be slightly clearer that it isn't the issue number that is totally forbidden from the filename, but that the filename needs to actually identify what the test is about at-a-glance, i.e. what-it-tests-issue-\d+ is acceptable, strictly speaking (if the reviewer accepts it, at least)?

@tgross35
Copy link
Contributor

It would be nice to somehow enforce an attribute style so they're easily extractable, regardless of whether or not the issue number is in the title

// issue:12345
// issue:6789
// ice:1234

@workingjubilee
Copy link
Member

I do not think we should enforce that issue numbers be in filenames for the benefit of automation. The directory structures are for humans, and machines can deal with skimming through raw inodes and bytes if they must. It is specifically because the issue numbers are effectively just a table of pointers to allocations of real data that we are discussing this lint.

@matthiaskrgr
Copy link
Member

matthiaskrgr commented Jul 11, 2023

It is specifically because the issue numbers are effectively just a table of pointers to allocations of real data that we are

Exactly! and by having the issue number in the title/filename, you only need a single lookup to access the data 🙂
Hiding the pointer somewhere inside inside the actual file and having to actually open and read the file is just a ton of unnecessary overhead!

@workingjubilee
Copy link
Member

And it's a ton of unnecessary overhead, when you are actually trying to examine the "deep history" of a bug, to have to open a bunch of files and examine each one for its purpose, rather than seeing the filename identifying things at a glance. And if a test relates to two or more issues, which is not at all uncommon now that we have over 50 thousand closed issues and over 8000 open issues, then having only one issue in the filename is equally useless if it's not the one you know the matter by.

@matthiaskrgr If you need me to PR code to you for extracting issue numbers from file contents, I am happy to put it on my todo list if you name the repo.

@workingjubilee
Copy link
Member

@tgross35 Would you be so kind as to open an issue for that?

@matthiaskrgr
Copy link
Member

Also note that it seems that the current consent is to actually prefer "issue-xyz in filename" over "issue number somewhere inside the file":

Looking just in tests/ui:

issuenr in file:
git ls-files | grep rs$ | grep "issue" | wc -l 4474

issuenr in comment:

git grep -r "#[0-9][0-9][0-9]" | grep -v stderr | grep "rs" | wc -l 2201
git grep -r "https://github.com/rust-lang/rust/" | grep -v stderr | grep "rs" | wc -l 273

@workingjubilee
Copy link
Member

rg 'issue.*[0-9]{4,}' --files-without-match | rg 'rs$' | wc -l
17174

I rest my case.

@matthiaskrgr
Copy link
Member

@workingjubilee oh maybe there is a bit of a misunderstanding, fwiw I have nothing against descriptive file names in addition to the issue number next to it, like rpitit-crash-on-unbound-whatever-103982.rs or issue-42167-OOM-on-recursive-thingamadoodle.rs but I really don't think we should rename all the files to never ever have a single digit in them "because there is already a link in the file itself" or something like that.

@workingjubilee
Copy link
Member

That is why I asked to refine the regex to allow rpitit-crash-on-unbound-whatever-issue-103982.rs.

@matthiaskrgr
Copy link
Member

Oh, and this will only affect ui tests, right? subrepo'd tools like clippy and rustfmt are still free to follow their own habits, right?

@workingjubilee
Copy link
Member

If tidy is currently running on subtrees we already have a problem, please take that up in a new issue.

@asquared31415
Copy link
Contributor Author

@rustbot author
I need to figure out how to get this working in CI properly before addressing the other concerns about the exact things that are checked.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 11, 2023
@bors
Copy link
Contributor

bors commented Jul 26, 2023

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 26, 2023
@workingjubilee
Copy link
Member

huh?

@asquared31415
Copy link
Contributor Author

asquared31415 commented Jul 26, 2023

💔 windows paths

(I'm doing string operations on hard coded paths)

@workingjubilee
Copy link
Member

Oh, right.

@workingjubilee
Copy link
Member

Sure, let's give this another go.

@workingjubilee
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jul 26, 2023

📌 Commit 13e2abf has been approved by workingjubilee

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 26, 2023
@bors
Copy link
Contributor

bors commented Jul 26, 2023

⌛ Testing commit 13e2abf with merge cf34adb...

@matthiaskrgr
Copy link
Member

shouldn't this go through an mcp at least so that more than 5 people are aware of this?

@compiler-errors
Copy link
Member

MCP was opened in rust-lang/compiler-team#658. I don't think this warrants stopping the merge, though.

@workingjubilee workingjubilee changed the title add tidy check that forbids issue-XXXX and ice-XXXX test filenames add tidy check that forbids issue-XXXX test filenames Jul 26, 2023
@bors
Copy link
Contributor

bors commented Jul 26, 2023

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing cf34adb to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 26, 2023
@bors bors merged commit cf34adb into rust-lang:master Jul 26, 2023
@rustbot rustbot added this to the 1.73.0 milestone Jul 26, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (cf34adb): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.3% [0.3%, 0.3%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.7% [2.5%, 2.9%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-2.7%, -2.7%] 1
All ❌✅ (primary) - - 0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-2.7%, -2.7%] 1
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 650.304s -> 650.76s (0.07%)

@asquared31415 asquared31415 deleted the tidy_no_issue_tests branch July 26, 2023 21:29
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 20, 2024
…t-name-lint, r=compiler-errors

Reimpl meaningful test name lint MCP658

This reintroduces the tidy rule originally proposed in rust-lang#113583 that then became an MCP in rust-lang/compiler-team#658 which eventually surfaced a quite-reasonable request for a diagnostic enhancement. I have added that to the rule. It produces output like this:
```
tidy error: file `ui/unsized/issue-115809.rs` must begin with a descriptive name, try `{reason}-issue-115809.rs`
tidy error: file `ui/unsized/issue-115203.rs` must begin with a descriptive name, try `{reason}-issue-115203.rs`
tidy error: file `ui/privacy/issue-113860-2.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/issue-119463.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/auxiliary/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/auxiliary/issue-119463-extern.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/issue-113860-1.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-113860.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/const-generics/generic_const_exprs/const_kind_expr/issue_114151.rs` must begin with a descriptive name, try `{reason}-issue-114151.rs`
tidy error: file `ui/did_you_mean/issue-114112.rs` must begin with a descriptive name, try `{reason}-issue-114112.rs`
tidy error: file `ui/did_you_mean/issue-105225.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
tidy error: file `ui/did_you_mean/issue-105225-named-args.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
```

You get the idea.

There are some tests which merely would require reordering of the name according to the rule. I could modify the diagnostic further to identify those, but doing such would make it prone to bad suggestions. I have opted to trust contributors to recognize the diagnostic is robotic, as the pattern we are linting on is easier to match if we do not speculate on what parts of the name are meaningful: sometimes a word is a reason, but sometimes it is a mere "tag", such as with a pair like:
- issue-314159265-blue.rs
- issue-314159265-red.rs

Starting them with `red-` and `blue-` means they do not sort together, despite being related, and the color names are still not very descriptive. Recognizing a good name is an open-ended task, though this pair might be:
- colored-circle-gen-blue.rs
- colored-circle-gen-red.rs

Deciding exactly *how* to solve this is not the business of tidy, only recognizing a what.

r? `@compiler-errors`
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Feb 22, 2024
…nt, r=compiler-errors

Reimpl meaningful test name lint MCP658

This reintroduces the tidy rule originally proposed in rust-lang/rust#113583 that then became an MCP in rust-lang/compiler-team#658 which eventually surfaced a quite-reasonable request for a diagnostic enhancement. I have added that to the rule. It produces output like this:
```
tidy error: file `ui/unsized/issue-115809.rs` must begin with a descriptive name, try `{reason}-issue-115809.rs`
tidy error: file `ui/unsized/issue-115203.rs` must begin with a descriptive name, try `{reason}-issue-115203.rs`
tidy error: file `ui/privacy/issue-113860-2.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/issue-119463.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/auxiliary/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/auxiliary/issue-119463-extern.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/issue-113860-1.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-113860.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/const-generics/generic_const_exprs/const_kind_expr/issue_114151.rs` must begin with a descriptive name, try `{reason}-issue-114151.rs`
tidy error: file `ui/did_you_mean/issue-114112.rs` must begin with a descriptive name, try `{reason}-issue-114112.rs`
tidy error: file `ui/did_you_mean/issue-105225.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
tidy error: file `ui/did_you_mean/issue-105225-named-args.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
```

You get the idea.

There are some tests which merely would require reordering of the name according to the rule. I could modify the diagnostic further to identify those, but doing such would make it prone to bad suggestions. I have opted to trust contributors to recognize the diagnostic is robotic, as the pattern we are linting on is easier to match if we do not speculate on what parts of the name are meaningful: sometimes a word is a reason, but sometimes it is a mere "tag", such as with a pair like:
- issue-314159265-blue.rs
- issue-314159265-red.rs

Starting them with `red-` and `blue-` means they do not sort together, despite being related, and the color names are still not very descriptive. Recognizing a good name is an open-ended task, though this pair might be:
- colored-circle-gen-blue.rs
- colored-circle-gen-red.rs

Deciding exactly *how* to solve this is not the business of tidy, only recognizing a what.

r? `@compiler-errors`
lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request Apr 7, 2024
…nt, r=compiler-errors

Reimpl meaningful test name lint MCP658

This reintroduces the tidy rule originally proposed in rust-lang/rust#113583 that then became an MCP in rust-lang/compiler-team#658 which eventually surfaced a quite-reasonable request for a diagnostic enhancement. I have added that to the rule. It produces output like this:
```
tidy error: file `ui/unsized/issue-115809.rs` must begin with a descriptive name, try `{reason}-issue-115809.rs`
tidy error: file `ui/unsized/issue-115203.rs` must begin with a descriptive name, try `{reason}-issue-115203.rs`
tidy error: file `ui/privacy/issue-113860-2.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/issue-119463.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/auxiliary/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/auxiliary/issue-119463-extern.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/issue-113860-1.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-113860.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/const-generics/generic_const_exprs/const_kind_expr/issue_114151.rs` must begin with a descriptive name, try `{reason}-issue-114151.rs`
tidy error: file `ui/did_you_mean/issue-114112.rs` must begin with a descriptive name, try `{reason}-issue-114112.rs`
tidy error: file `ui/did_you_mean/issue-105225.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
tidy error: file `ui/did_you_mean/issue-105225-named-args.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
```

You get the idea.

There are some tests which merely would require reordering of the name according to the rule. I could modify the diagnostic further to identify those, but doing such would make it prone to bad suggestions. I have opted to trust contributors to recognize the diagnostic is robotic, as the pattern we are linting on is easier to match if we do not speculate on what parts of the name are meaningful: sometimes a word is a reason, but sometimes it is a mere "tag", such as with a pair like:
- issue-314159265-blue.rs
- issue-314159265-red.rs

Starting them with `red-` and `blue-` means they do not sort together, despite being related, and the color names are still not very descriptive. Recognizing a good name is an open-ended task, though this pair might be:
- colored-circle-gen-blue.rs
- colored-circle-gen-red.rs

Deciding exactly *how* to solve this is not the business of tidy, only recognizing a what.

r? `@compiler-errors`
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 27, 2024
…nt, r=compiler-errors

Reimpl meaningful test name lint MCP658

This reintroduces the tidy rule originally proposed in rust-lang/rust#113583 that then became an MCP in rust-lang/compiler-team#658 which eventually surfaced a quite-reasonable request for a diagnostic enhancement. I have added that to the rule. It produces output like this:
```
tidy error: file `ui/unsized/issue-115809.rs` must begin with a descriptive name, try `{reason}-issue-115809.rs`
tidy error: file `ui/unsized/issue-115203.rs` must begin with a descriptive name, try `{reason}-issue-115203.rs`
tidy error: file `ui/privacy/issue-113860-2.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/issue-119463.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/auxiliary/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/auxiliary/issue-119463-extern.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/issue-113860-1.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-113860.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/const-generics/generic_const_exprs/const_kind_expr/issue_114151.rs` must begin with a descriptive name, try `{reason}-issue-114151.rs`
tidy error: file `ui/did_you_mean/issue-114112.rs` must begin with a descriptive name, try `{reason}-issue-114112.rs`
tidy error: file `ui/did_you_mean/issue-105225.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
tidy error: file `ui/did_you_mean/issue-105225-named-args.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
```

You get the idea.

There are some tests which merely would require reordering of the name according to the rule. I could modify the diagnostic further to identify those, but doing such would make it prone to bad suggestions. I have opted to trust contributors to recognize the diagnostic is robotic, as the pattern we are linting on is easier to match if we do not speculate on what parts of the name are meaningful: sometimes a word is a reason, but sometimes it is a mere "tag", such as with a pair like:
- issue-314159265-blue.rs
- issue-314159265-red.rs

Starting them with `red-` and `blue-` means they do not sort together, despite being related, and the color names are still not very descriptive. Recognizing a good name is an open-ended task, though this pair might be:
- colored-circle-gen-blue.rs
- colored-circle-gen-red.rs

Deciding exactly *how* to solve this is not the business of tidy, only recognizing a what.

r? `@compiler-errors`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants