You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FYI, this is temporary_assignment lint. rust-lang/rust#53224 is the general issue for upstreaming Clippy lints. (temporary_assignment is not included in that issue, but it probably should be?)
The rust issue only looks at correctness lints. temporary_assignment is a complexity lint. Doing something like this cannot result in wrong code, since you can't use the structure you temporary assigned a value to (The assignment operator = always returns () in Rust, so a = b = 1, will result in a = () and b = 1*).
So this is valid rust code, that does not have any influence on the correctness of your program. So this doesn't qualify for a rustc lint, because for such cases Clippy exists.
* This seems that it may cause errors, but if you would try to use a = () as an integer somewhere in your program, this would be caught by the rust type system, so we're good here.
I very much disagree in that Rust's standard unused_variables lint is not a correctness issue either. It does make sense to prioritize correctness lints though.
I agree, that rust has lints, that aren't really correctness concerns (most of them are allow-by-default though). But on the other hand, the rust compiler still has a pretty strict "no new lints" rule, except, there are really good reasons to add a new lint. That's why Clippy exists.
As a site note: unused_variables can lead to errors:
let similar_name1 = 10;let similar_nameI = 11;// unused_variableassert_eq!(similar_name1,11);// panic
Activity
sanxiyn commentedon Sep 4, 2019
FYI, this is
temporary_assignmentlint. rust-lang/rust#53224 is the general issue for upstreaming Clippy lints. (temporary_assignmentis not included in that issue, but it probably should be?)flip1995 commentedon Sep 4, 2019
The rust issue only looks at correctness lints.
temporary_assignmentis acomplexitylint. Doing something like this cannot result in wrong code, since you can't use the structure you temporary assigned a value to (The assignment operator=always returns()in Rust, soa = b = 1, will result ina = ()andb = 1*).So this is valid rust code, that does not have any influence on the correctness of your program. So this doesn't qualify for a rustc lint, because for such cases Clippy exists.
* This seems that it may cause errors, but if you would try to use
a = ()as an integer somewhere in your program, this would be caught by the rust type system, so we're good here.sanxiyn commentedon Sep 4, 2019
I very much disagree in that Rust's standard
unused_variableslint is not a correctness issue either. It does make sense to prioritize correctness lints though.flip1995 commentedon Sep 4, 2019
I agree, that rust has lints, that aren't really correctness concerns (most of them are
allow-by-defaultthough). But on the other hand, the rust compiler still has a pretty strict "no new lints" rule, except, there are really good reasons to add a new lint. That's why Clippy exists.As a site note:
unused_variablescan lead to errors:That is a very constructed example, but it does happen in actual code. (BTW, Clippy has a lint for this: https://rust-lang.github.io/rust-clippy/master/index.html#similar_names)