Minimum lint levels for C-future-compatibility issues: take two#68501
Minimum lint levels for C-future-compatibility issues: take two#68501Aaron1011 wants to merge 6 commits intorust-lang:masterfrom
Conversation
|
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
Some notes:
|
| // If this code originates in a foreign macro, aka something that this crate | ||
| // did not itself author, then it's likely that there's nothing this crate | ||
| // can do about it. We probably want to skip the lint entirely. | ||
| if err.span.primary_spans().iter().any(|s| in_external_macro(sess, *s)) { | ||
| // Any suggestions made here are likely to be incorrect, so anything we | ||
| // emit shouldn't be automatically fixed by rustfix. | ||
| err.allow_suggestions(false); | ||
|
|
||
| // If this is a future incompatible lint it'll become a hard error, so | ||
| // we have to emit *something*. Also allow lints to whitelist themselves | ||
| // on a case-by-case basis for emission in a foreign macro. | ||
| if future_incompatible.is_none() && !lint.report_in_external_macro { | ||
| err.cancel() | ||
| } | ||
| } |
There was a problem hiding this comment.
I'm not sure what you mean.
There was a problem hiding this comment.
Looking at the diff, it seems like this code is now duplicated from earlier in struct_span_level (take a look at "view file"), so I'm wondering if you inadvertently brought old code in with the forward port.
davidtwco
left a comment
There was a problem hiding this comment.
Implementation looks good to me. I don't have an opinion on the behaviour.
|
|
||
| /// Lint level was set by an attribute. | ||
| Node(Symbol, Span, Option<Symbol> /* RFC 2383 reason */), | ||
| Node(Symbol, Option<Level>, Span, Option<Symbol> /* RFC 2383 reason */), |
There was a problem hiding this comment.
Perhaps this (and the CommandLine variant) should be made into struct variants with named fields for clarity?
| // Add notes about minimum levels and what the user should do here: | ||
| err.note(&format!("the minimum lint level for `{}` is `{}`", name, min_level.as_str())) | ||
| .note(&format!("the lint level cannot be reduced to `{}`", level_str)) | ||
| .help(&format!("remove the #[{}({})] directive", level_str, name)); |
There was a problem hiding this comment.
I can't see any tests that show this help message - was wondering if it could be a suggestion?
|
☔ The latest upstream changes (presumably #68080) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Triaged |
|
Closing this after a discussion with the author :) |
This is a revival of #59658.
For now, I've just rebased against
master, and tweaked the output (e.g. added in backticks) to remove unnecessary churn.It doesn't look like the discussion in #59658 arrived at a consensus as to what the exact behavior of this should be. The main options seem to be:
cap-lint): do not suppress any warning messages, and additional emit a warning whenever#[allow]is applied to the future-compat lint. This is the most verbose option, and seems quite spammy.cap-lint): emit a single message per lint type, possibly pointing to the span where it occurs.I'm interested in getting this infrastructure merged in order to support #68350 (never-type fallback lint)., I'd like the never-type fallback lint to be deny-by-default while piercing
cap-lints.