-
Notifications
You must be signed in to change notification settings - Fork 1.6k
improve lintcheck
#9731
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
improve lintcheck
#9731
Conversation
Use `simplelog` to handle logs, as `env_logger` does not handle writing to file for the moment, see rust-cli/env_logger#208 Do not push most verbose logs on stdout, only push them in the log file
r? @flip1995 (rust-highfive has picked a reviewer for you, use r? to override) |
There were several issues: - `--fix` was ignored as part of rust-lang#9461 - `--filter` in conjunction to `--fix` was broken due to rust-lang#9703 After `lintcheck --fix` is used, crates will be re-extracted since their content has been modified
I'm really unsure if we need this level of logging in the |
This additional logging already allowed me to fix two issues of About the colouring/formatting, I'd be fine with making it similar to plain For the two dependencies, I'm not sure why it is an issue since we have no restrain in how we run |
I was thinking about adding another output mode alongside normal/markdown that output the rendered diagnostics to the log, would that cover it? |
vec!["--fix", "--"] | ||
// need to pass `clippy` arg even if already feeding `cargo-clippy` | ||
// see https://github.com/rust-lang/rust-clippy/pull/9461 | ||
vec!["clippy", "--fix", "--allow-no-vcs", "--"] | ||
} else { | ||
vec!["--", "--message-format=json", "--"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you're in the neighbourhood, could change this bit to
vec!["--", "--message-format=json", "--"] | |
vec!["clippy", "--message-format=json", "--"] |
I did find this quite confusing before the conversation in #9461
There is a list of allowed crates in the Rust compiler: https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/deps.rs Clippy should also adhere to this list of crates. For more information about this, see https://rustc-dev-guide.rust-lang.org/crates-io.html I'm ok with the I'll leave the decision whether |
This is fair, I can implement a simple log consumer by hand which would avoid that dependency. It looks like lintcheck is already using crates not from the whitelist though (
Functionality-wise it would, but I feel this would be less-maintainable than leveraging on the rust ecosystem. |
It would be an additional branch in Personally I don't see a compelling reason to add the crates |
First just want to thank you Alexendoo for your PR because I believe Now, I would argue that the difference of complexity between cea4044 (from #9764 which also add 2 new deps and rely on instable features) and 5461e99 favouring the latter is compelling enough to rely on With latest version of env_logger fixing their issue with piping logs to a file, I can revert to use it and all new deps would be in the rustc whitelist. Will wait for a final call from matthiaskrgr before doing so though. |
Comparing those commits seems odd, they do completely different things. Adding The sigpipe feature is so that |
☔ The latest upstream changes (presumably #10445) made this pull request unmergeable. Please resolve the merge conflicts. |
Hey @matthiaskrgr, this is a ping from triage. A previous commit, mentioned that they would like input from you. Would you mind taking a look at it: #9731 (comment) @kraktus Since this PR was created quite some time ago do you believe this would still be a good addition? |
Oh damn, I have absolute no memory of ever seeing this 😓 but I've also turned off all github mail notifications since getting 30-40 mails a day was getting unbearable. To be honest I'm not sure if I am still fit as "area expert" for lintcheck, I did write the initial impl with a clear goal of what I wanted it to be, but it has also been rewritten several times (at least thats what it feels like) so that I no longer feel familiar with the code, I have also not run it in probably 3-4 years by myself (if others do, that is great though :D) I looked over the PR and did not see anything that made me think "omg wtf", so lgtm I guess?? |
I think fixing —fix would be a good addition yes, eventually running it as CI whenever a new MachineApplicable lint is created to know about cornercases should be a goal. |
Ah yes! With whole crates there is always a higher change though that lints do collide in some weird way, sometimes two lints give conflicting suggestions for the same line, or that you'll have to remove major parts of the program to get a somewhat usable mvce. |
Okay, that's understandable! r? @Alexendoo Would you mind taking over this review? You already left a few comments earlier and know lintcheck a bit AFAIK. If you don't have the time, you can reassign it to me :)
Sounds reasonable, thank you for the answer :D |
Yeah I can review it, may need redoing since it's changed a fair bit since the PR was opened, I don't think anybody has touched |
Hey @Alexendoo this is a ping from triage. Could you take a look at this issue and indicate what needs to be done next? |
I could rebase it and work on next week. I'll need to check back the code as I've lost track of the changes since. I'd like to get a green light on it before though. (both fixing |
As we already use some deps that are not white listed in the Rust repo and |
Personally I'd rather have |
Hey @kraktus, could you rebase this PR on master? Recently, we made several changes to lintcheck. For the changes. I'd like to have For the logging part. Our CI now displays the full error message. You can take a look at https://github.com/xFrednet/rust-clippy/actions/runs/10044508861 from #13139 as an example. Having a local option would also be cool, but I'd also be in favor of a flag instead of logging. @Alexendoo I've also assigned myself, as I want to keep track of it. We can both do reviews on this one :D |
Hey, I don't have plan to work on this in the foreseeable future, feel free to pick it up |
Alright, then I'll close this PR for now. Thank you :D |
Two axes were improved (one per commit):
--fix
flagAbout logging, I'm open to other form and crates to use, my main point was to actually see actual clippy's suggestions, rather than for each crate look for the line
changelog: none