-
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
Uplift declare_interior_mutable_const
and borrow_interior_mutable_const
from clippy to rustc
#77983
Comments
Note the lint currently has a few false positives: rust-lang/rust-clippy#5812, rust-lang/rust-clippy#3825, rust-lang/rust-clippy#3962. I think these are being fixed in rust-lang/rust-clippy#6110, so uplifting this should wait until after that PR is merged. cc @rust-lang/clippy |
I don't think this lint is ready to get uplifted, because it has too many FPs. I will do a review round in Clippy tomorrow and also take a look at rust-lang/rust-clippy#6110. If my opinion about that changes with rust-lang/rust-clippy#6110 merged, I'll write that here. That being said, a FP free version of this lint would definitely be great in |
rust-lang/rust-clippy#6110 doesn't fix rust-lang/rust-clippy#5812. My PR (6110) is for unfrozen enums with frozen variants as described in rust-lang/rust-clippy#3962. I bundled two fixes because I consider rust-lang/rust-clippy#3825 is the same as 3962 except, in the 3825 case, the constant defined in an outer crate; and the fact that the unfrozen structure in 3825 is |
Fix perf regression in rustdoc::bare_urls This regressed in rust-lang#81764. After that PR, rustdoc compiled the regex for every single item in the crate: https://perf.rust-lang.org/compare.html?start=125505306744a0a5bb01d62337260a95d9ff8d57&end=2e495d2e845cf27740e3665f718acfd3aa17253e&stat=instructions%3Au This would have been caught by `clippy::declare_interior_mutable_const` (cc rust-lang#77983).
the lint should be uplifted from clippy to rustc too . wrong behavior just build success without any warning |
Someone ran into this footgun and filed an issue recently (#114939) so I'd like to take the opportunity to bump this. What's the status on false positives? Seems like rust-lang/rust-clippy#5812 is still open. |
In tokio 0.2, there was a footgun: if you created a
const Runtime
, then each time you calledruntime.block_on()
it would make a new runtime. This lead to confusing errors at runtime like 'reactor gone' which gave no hint of what actually went wrong: rust-lang/rust-clippy#6088Fortunately, this was fixed by
const_item_mutation
in #75573. Unfortunately,Runtime::block_on
will now take&self
instead of&mut self
starting in tokio 0.3: https://tokio.rs/blog/2020-10-tokio-0-3Runtime
can now only be constructed at runtime: as a local variable or in aonce_cell
, orlazy_static
. The code for that looks like this:rustc will compile this without a warning. Clippy, however, says that this is almost certainly not what you want:
To avoid having this footgun, the lint should be uplifted from clippy to rustc (possibly as warn-by-default), so that users will notice it even if they don't use clippy.
cc @Darksonn
The text was updated successfully, but these errors were encountered: