Skip to content

Confusing warn-unused-mut warnings since 1.27.0-nightly 2018-04-29 #50343

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
Robbepop opened this issue Apr 30, 2018 · 10 comments
Closed

Confusing warn-unused-mut warnings since 1.27.0-nightly 2018-04-29 #50343

Robbepop opened this issue Apr 30, 2018 · 10 comments
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. NLL-diagnostics Working towards the "diagnostic parity" goal T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Robbepop
Copy link
Contributor

With the latest nightly (rustc 1.27.0-nightly (66363b288 2018-04-29)) I get confusing compile warnings about unused mut keywords where there are no mut keywords present.

The warnings do not happen on the previous nightly (rustc 1.27.0-nightly (66363b288 2018-04-28)) - so this might be a regression.

For further inspection the project where I receive those warnings can be found here.

Some examples

warning: variable does not need to be mutable
   --> src/ast/visitor.rs:158:56
    |
158 |     fn visit_cond(&mut self, _cond: &expr::IfThenElse, _: VisitEvent) {}
    |                                                        ^ help: remove this `mut`
    |
    = note: #[warn(unused_mut)] on by default
warning: variable does not need to be mutable
   --> src/simplifier/simplifications/normalizer.rs:100:17
    |
100 |           .all(|(lhs, rhs)| {
    |                 ------^^^^
    |                 |
    |                 help: remove this `mut`
@ExpHP
Copy link
Contributor

ExpHP commented Apr 30, 2018

Bizarre; this must be where all the missing "unused mut" warnings from #50321 are running off to!

@pietroalbini pietroalbini added A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 30, 2018
@pietroalbini pietroalbini added this to the 1.27 milestone Apr 30, 2018
@pietroalbini
Copy link
Member

A quick bisect run points at #48605 as the cause of this. cc @KiChjang @nikomatsakis

@KiChjang KiChjang added A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal labels Apr 30, 2018
@nikomatsakis
Copy link
Contributor

Just to confirm: this is specific to crates using nll, right?

@realcr
Copy link

realcr commented May 2, 2018

This problem breaks our build. Some examples:

error: variable does not need to be mutable
   --> src/utils/async_mutex.rs:154:35
    |
154 |                         .map_err(|_| AsyncMutexError::AwakenerCanceled)?
    |                                   ^ help: remove this `mut`

...

error: variable does not need to be mutable
   --> src/timer.rs:153:19
    |
153 |             .map(|_| tm.create_client())
    |                   ^ help: remove this `mut`
    |
note: lint level defined here
   --> src/timer.rs:40:9
    |
40  | #![deny(warnings)]
    |         ^^^^^^^^

@KiChjang
Copy link
Member

KiChjang commented May 2, 2018

@realcr Same question as Niko posted above -- does this only happen when you enable NLL?

@Robbepop
Copy link
Contributor Author

Robbepop commented May 2, 2018

In the case of my linked project nll is enabled but I cannot tell you if this bug is exclusive to nll enabled projects so I couldn't really answer niko's question.

@pietroalbini
Copy link
Member

@KiChjang @nikomatsakis as far as I can see this only happens with NLL (or at least, this snippet emits the warning only with NLL enabled):

#![feature(nll)]

fn main() {
    vec![42].iter().map(|_| ()).count();
}

@pietroalbini pietroalbini removed the regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. label May 2, 2018
@pietroalbini pietroalbini removed this from the 1.27 milestone May 2, 2018
@nikomatsakis
Copy link
Contributor

I guess that's a reduced test case?

@realcr
Copy link

realcr commented May 2, 2018

@KiChjang : It's the first time I hear about NLL. It seems like my project does have NLL enabled.

$ ag "nll"
src/lib.rs
2:#![feature(nll)]

Interesting.

EDIT: I can't tell if this problem is unique to NLL, because if I remove it the project doesn't compile. Now I know what NLL does (:

error[E0597]: `**dur` does not live long enough
   --> src/timer.rs:164:40
    |
162 |             .map(|client| client.take(u64::from(TICKS)).collect().and_then(|_| {
    |                                                                            --- capture occurs here
163 |                     let elapsed = start.elapsed();
164 |                     assert!(elapsed >= dur * TICKS * 2 / 3);
    |                                        ^^^ borrowed value does not live long enough
...
168 |             .collect::<Vec<_>>();
    |                                - borrowed value only lives until here
...
173 |     }
    |     - borrowed value needs to live until here

@nikomatsakis
Copy link
Contributor

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. NLL-diagnostics Working towards the "diagnostic parity" goal T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants