-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
declare_interior_mutable_const and borrow_interior_mutable_const need to respect enum variants #3962
Comments
I just tripped over this. In my case, it occurs with a trait constant:
The playground doesn't have
|
It's probably also possible to get a false positive from this without using an enum, if there is some other kind of type that can be constructed I think the the root of this particular problem is that the lint ought to depend on the value of the constant, rather than the type. |
@ijackson I think what you found is actually something related to #5050 because I believe the below is the only error message you'd get if you removed
|
fix a false positive in two `interior_mutable_const` lints where a constant with enums gets linted even if it uses a clearly unfrozen variant. Note that the code uses the MIR interpreter, which the author of rust-lang#3962 thought unlikely to be a solution. This might be over-engineering; but, I think it's important to be able to work with the 'http' crate (rust-lang#3825).
fix a false positive in two `interior_mutable_const` lints where a constant with enums gets linted even if it uses a clearly unfrozen variant. Note that the code uses the MIR interpreter, which the author of rust-lang#3962 thought unlikely to be a solution. This might be over-engineering; but, I think it's important to be able to work with the 'http' crate (rust-lang#3825).
fix a false positive in two `interior_mutable_const` lints where a constant with enums gets linted even if it uses a clearly unfrozen variant. Note that the code uses the MIR interpreter, which the author of rust-lang#3962 thought unlikely to be a solution. This might be over-engineering; but, I think it's important to be able to work with the 'http' crate (rust-lang#3825).
I realize that it isn't possible to know if the thing on the rhs of a const declaration is interior mutable or not without full const evaluation, but trivial cases such as the example shouldn't be too difficult.
The text was updated successfully, but these errors were encountered: