-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
New "warning incompatible with previous forbid in same scope" error #77713
Comments
Nominating for lang team. I suspect we'll want crater, but maybe we just don't fix this. |
I know we need backwards-compatibility, but what is the usefulness of supporting #![forbid(unused_extern_crates)]
#![warn(unused_extern_crates)] ? |
The actual original code was #![forbid(rust_2018_idioms)]
#![warn(unused_extern_crates)] |
Reviewing this in the lang team meeting I was surprised that this behavior is order-dependent. That is, this works without warning or error: #![warn(unused_extern_crates)]
#![forbid(unused_extern_crates)]
fn main() {} Not sure if this is backwards compatible with the present situation on stable or nightly, but to me the intuitive behavior of overlapping lint-setters at the same level is this: we take the maximum value that the user set, and then warn that the other attributes do nothing. That is, both of these examples (regardless of order), should set On the other hand, considering this different example: #![warn(rust_2018_idioms)]
#![forbid(unused_extern_crates)]
fn main() {} This should set That is, I think the behavior should be order independent - two attributes applied to the same item (in this case, the top level module) should be considered the same regardless of the order they are in the program text. |
We spent a while discussing this in today's lang-team meeting. We didn't reach a clear consensus on what we thought was the most appropriate behavior, but we did come up with some consensus points:
We'll discuss a bit more next week but here are some notes and questions:
Also, one point of clarification for @Nemo157. In the OP, you wrote:
At first, we thought this might mean that, prior to #77534, the |
Exactly, I wrote that before I had looked into the history and realised that this was fixing a prior regression, I was just assuming it was a newly added error that was being over-zealously implemented as a hard error rather than a deny-by-default lint. |
Assigning |
Discussed in the lang team meeting:
Next step:
|
Always true:
New behavior, introduced by #77534: Forbid (essentially) takes immediate effect, rather than being overridden by other attributes at the same level. This is unique behavior specifically to forbid; no other lint receives the same treatment. I would propose the following (the implementation should be worked out, of course, but this seems feasible -- I would not FCP until we have a PR, just that if people have objections to this raising them now seems good):
|
I will try to work out an implementation to better get a sense of what would fall out of the impl naturally without too much contortion. We'll then try to FCP that proposal. (If this ends up taking too long, we will likely just revert #77534 on beta or so; I am not too worried, as it is not yet a beta regression). |
Going to denominate this until I end up with an implementation to FCP; I expect there's nothing further to discuss here until then. |
I have posted #78864 which fixes the regression here in dependencies (i.e., cap-lints will affect the new lint/error). |
…kfelix Use true previous lint level when detecting overriden forbids Previously, cap-lints was ignored when checking the previous forbid level, which meant that it was a hard error to do so. This is different from the normal behavior of lints, which are silenced by cap-lints; if the forbid would not take effect regardless, there is not much point in complaining about the fact that we are reducing its level. It might be considered a bug that even `--cap-lints deny` would suffice to silence the error on overriding forbid, depending on if one cares about failing the build or precisely forbid being set. But setting cap-lints to deny is quite odd and not really done in practice, so we don't try to handle it specially. This also unifies the code paths for nested and same-level scopes. However, the special case for CLI lint flags is left in place (introduced by rust-lang#70918) to fix the regression noted in rust-lang#70819. That means that CLI flags do not lint on forbid being overridden by a non-forbid level. It is unclear whether this is a bug or a desirable feature, but it is certainly inconsistent. CLI flags are a sufficiently different "type" of place though that this is deemed out of scope for this commit. r? `@pnkfelix` perhaps? cc rust-lang#77713 -- not marking as "Fixes" because of the lack of proper unused attribute handling in this PR
The remaining action here is to:
|
Revert in #79903, untagging as regression |
…ulacrum [beta] backports * Revert rust-lang#77534 fixing rust-lang#77713 on beta, principled fix landed on master * fix soundness issue in `make_contiguous` rust-lang#79814 * Fix exhaustiveness in case a byte string literal is used at slice type rust-lang#79072
I tried this code:
I expected to see this happen: an error that can be disabled via
--cap-lints=warn
Instead, this happened: a hard error
After writing this up, looking back through the history (#77534, #70819) it appears this is fixing a regression, but given that this has been accepted by the stable compiler for over 3 years at this point, maybe it's still worth having a deprecation period? (This was noticed by a user on the discord as their code started failing to compile).
Meta
The text was updated successfully, but these errors were encountered: