Make the unused_mut lint smarter #26378
Conversation
|
☔ The latest upstream changes (presumably #24527) made this pull request unmergeable. Please resolve the merge conflicts. |
|
bump |
|
(I don't know if I agree that #26332 is actually a bug ... that is, I don't know if I like the idea of flagging that sort of code with a warning... but I'm willing to assume that it is for the purposes of completing this review) |
|
cc @rust-lang/lang |
|
(The cleanup commit looks fine to me; I am just hesistant to r-plus this PR without double-checking that others agree that this change to the lint in question is desirable.) |
|
f+ on the principle here - it sounds like it is making the lint better, and I don't think lints count as a breaking change |
|
@nrc okay, my main concern was that someone who writes: let mut x;
...
x = 3;may intend, in the long term, to add additional statements that assign to But I am willing to believe that the change here will help more than it hurts. Especially if it helps new-comers understand the idea that the "delayed single-assignment style" like above is not considered mutation by |
|
⌛ Testing commit a18d984 with merge 73165be... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
@bors: retry On Fri, Jul 3, 2015 at 6:59 AM, bors [email protected] wrote:
|
|
⌛ Testing commit a18d984 with merge 728af15... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
@bors: retry On Fri, Jul 3, 2015 at 12:59 PM, bors [email protected] wrote:
|
This makes it somewhat more aggressive, so this is kind-of a [breaking-change] for these compiling with `#[deny(unused_mut)]`. r? @pnkfelix
This makes it somewhat more aggressive, so this is kind-of a [breaking-change] for these compiling with
#[deny(unused_mut)].r? @pnkfelix