-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Suggestion Span for non_upper_case_globals could be more precise #48103
Comments
Sounds good! Let me know if you need help. (Self-assigning since I can't assign it to you, but this means I'm mentoring this bug) |
I'm pretty sure we can also this as a suggestion to make it auto-fixable. Not sure if we have a good SCREAMING_SNAKE_CASE transformer in rustc, but I guess it's fine to only suggest this for trivial changes at first. |
Just a quick update because it's been a few days. I was able to fix this locally already, but got a faster laptop this week where the rust repo setup is broken somehow. I will try to fix it today, otherwise it will be next week 👍 |
I'm interested in reviving this. I see in the linked PR that there's some discussion about adding the span to the HIR. I'm happy to try this, but I'm unsure where it would be added? |
So my reading of the PR points to Line 2178 in a49316d
That rust/src/librustc/hir/lowering.rs Line 3456 in a49316d
Three years ago, this already was an This move was tracked in #6993 so there might be some hygiene or similar topics related to this. .... and now I'm wondering why this is a |
rust/src/librustc_lint/nonstandard_style.rs Lines 403 to 415 in 0c1dc62
EDIT: Oh, I didn't realize you can define multiple passes for the same lint! Neat. EDIT 2: Well, maybe not. Registering multiple passes causes an ICE. |
Made a bit more progress on this. I have a commit that replaces
I suspect that it has something to do with this line: rust/src/libsyntax_ext/test.rs Line 137 in d48ab69
gensym reuses the span of the function identifier for the constant. Therefore, when the lint gets triggered, the span doesn't trip the macro check, and a warning is reported. However, I'm not sure of the best way to fix it. I suppose I could throw an #[allow(non_upper_case_globals)] on the generated constant but that doesn't feel like the right solution; I think the macro check should silence the warning. Is there a way to create that Ident with a span that indicates it's part of a macro expansion or another solution? Is my reasoning correct?
|
I still think that the correct fix is to use an early lint, and just split out the lowercase const pattern lint to stay as a late lint pass. I'd separate the datastructures completely to get around the duplication checks that you've been hitting. Most likely there's a very good reason not to have idents in HIR |
Yea that's definitely possible. Reading those issues I agree that there is desire to do so. we should do it in steps though. so first create a new lint just for the pattern const part, and once that is through, move the other lint to an early pass |
FWIW, #56225 already replaces |
Use structured suggestions for nonstandard style lints This PR modifies the lints in the nonstandard_style group to use structured suggestions. Note that there's a bit of tricky span calculation going on for the `crate_name` attribute. It also simplifies the code a bit: I don't think the "fallback" suggestions for these lints can actually be triggered. Fixes #48103. Fixes #52414.
Playground link: https://play.rust-lang.org/?gist=054aaeb143021ea121fc0c091903697b&version=nightly
It currently prints:
It would be nicer if it only underlines the variable name itself:
I have some basic lint writing experience through clippy, so I would like to give this a go.
The text was updated successfully, but these errors were encountered: