Repository navigation
Tidy on UI tests is annoying #75987
Description
Activity
Ok, I've found
// ignore-tidy-line-length. But I think it should be the default for UI tests.I disagree that this is an issue, various tidy checks are still very much useful for test code.
//~ ERRORannotations in*.rsfiles are not required to contain full messages and can be trimmed to their "essential part" if necessary,*.stderrfiles will contain full messages anyway.
// ignore-tidy-line-lengthand other// ignore-*directives are tools of last resort and should only be used in exceptional cases.- changed the title
[-]tidy is being run on UI tests[/-][+]Tidy on UI tests is annoying[/+]on Aug 28, 2020 Tidy has been a nightmare.
- The build failed. Tidy didn't like line lengths that were exceeded by a few characters.
- So I've had to find and add the
// ignore-tidy-line-length(if I truncated the message instead, it wouldn't be testing the word I added) - The build failed, because the ignore lines have changed line numbers in the tests.
- I've had to rebuild and bless tests again (it's a slow process)
- The build failed. I've added one ignore too many, and it failed because there wasn't a long line any more.
- I've removed the ignore line, but replaced it with a blank one, because I didn't want the pain of re-blessing the build (I've rebased my branch, so it'd cost me a full compiler recompile)
- The build failed. Tidy didn't allow having a blank line.
- Now I'm removing that build-breaking line. It wasn't even a big whitespace gap. Just literally one blank line at the top of the file. The file looks fine with it.
I just wanted to add one word to an error message. It's taking me hours of tinkering and recompiling and the PR is taking two days to just get past the tidy.
My enthusiasm went from "I've found a poorly worded error, I can fix it!" to "screw the petty gatekeeping tool, I don't have time to fight this".
Perhaps it's annoying for the first time, but updating failing tests doesn't require any rebuilds and take ~5 minutes at most after the initial build.
- You run
x.py test --bless src/test/ui tidyfor the first time, this is the long part. - A number of tests fail due to wrong or overlong
//~ ERRORannotations, they are fixed by updating or trimming the//~ ERRORannotations. x.py test --bless src/test/ui tidyis run again, it won't build anything and only re-test the changed tests. Fix remaining errors if something was missing, repeat as necessary.
- You run
they are fixed by updating or trimming the //~ ERROR annotations.
But what do I need to do? I got this
tidy error: /checkout/src/test/ui/parser/default.rs:24: line longer than 100 chars tidy error: /checkout/src/test/ui/parser/duplicate-visibility.rs:5: line longer than 100 charsNo action was mention on how to solve it so the first one that came into my mind is to add
tidy ignore. Maybe it should have some actionable steps?The line looks like this and I don't know how to continue other than the mentioned
// ignore tidy-line-length, I don't quite know how should I trim it.impl Foo for u32 { //~ ERROR not all trait items implemented, missing: `foo` default pub fn foo<T: Default>() -> T { T::default() } //~^ ERROR expected one of `async`, `const`, `extern`, `fn`, `pub`, `unsafe`, or `use`, found keyword `pub` }
@kornelski do you think disabling the line length check is enough? #77675
Or do you think other checks should be disabled too?I do think tidy (and all tests really) should suggest how to replicate exactly what went wrong without running a full x.py test, I'll open a separate issue for that.
Line length has been the major issue, so perhaps just this is enough.
Reacted by jyn
I've added a single word to an error message, and it broke tests for a silly reason:
The line has to be that long, otherwise it's not testing the message. I don't know what to do about this.