-
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
beta regression: forbid(warnings) interacts poorly with common derives. #81218
Comments
Assigning |
This is a regression because previously the "lowering forbid" lint did not actually detect lint groups as being forbidden, i.e., the allows within the derive or elsewhere would be silently accepted and used. Derive was not previously (or currently) treated in any special way for the forbid handling specifically. This issue intends for the lang team to decide what to do with this. We have a number of options:
There may be other options, but these seem like the most apparent. For all but option 1 we will likely want to revert or apply targeted patches to avoid breakage in the short term while we figure out a proper solution. (note: I will not be able to attend lang triage this week, but am happy to answer questions async here or on zulip) |
A fourth possibility would be if derive could somehow be fixable to not need to allow that lint. |
We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218). This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect.
…lint, r=pnkfelix introduce future-compatibility warning for forbidden lint groups We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218). This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect. r? `@Mark-Simulacrum`
…lint, r=pnkfelix introduce future-compatibility warning for forbidden lint groups We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218). This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect. r? ``@Mark-Simulacrum``
…lint, r=pnkfelix introduce future-compatibility warning for forbidden lint groups We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218). This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect. r? ```@Mark-Simulacrum```
…lint, r=pnkfelix introduce future-compatibility warning for forbidden lint groups We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218). This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect. r? `@Mark-Simulacrum`
…lint, r=pnkfelix introduce future-compatibility warning for forbidden lint groups We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218). This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect. r? ``@Mark-Simulacrum``
…lint, r=pnkfelix introduce future-compatibility warning for forbidden lint groups We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218). This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect. r? ``@Mark-Simulacrum``
Fix backported to 1.50.0 and landed in 1.51.0, closing this. |
Spawned off of #80988, but specifically talking about
forbid
andderive
interacting in a surprising manner.Code
I tried this code (play):
I expected to see this happen: Successful diagnostic-free compile, just like what happens on stable 1.49 Rust
Instead, this happened:
Version it worked on
It most recently worked on: Rust 1.49
Version with regression
1.50.0-beta.6
@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged
The text was updated successfully, but these errors were encountered: