[yashaggarwal85d]

let _ = y; where y is a local guard doesn't move or drop y, but
let_underscore_lock (deny by default) says the lock is released immediately and suggests
drop(y), which would change behaviour. Same for let_underscore_drop.

This skips the lint when the let initializer is a place expression. Temporaries still lint,
including fields of temporaries like (m.lock(), 1).0.

Fixes #164746
cc @theemathas @traviscross

[rustbot]

r? @mu001999

rustbot has assigned @mu001999.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 77 candidates
• Random selection from 19 candidates

[mu001999]

@rustbot author

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[mu001999]

@rustbot author

View changes since this review

[mu001999]

I'm thinking about cases like:

let &_ = &m.lock().unwrap(); // Shouldn't lint

and

fn identity<T>(x: &T) -> &T { x }

let _ = *identity(&NontrivialDrop); // Should lint

let d = NontrivialDrop;
let _ = *identity(&d); // Shouldn't lint

I suspect we may not be able to cover the above cases at the HIR level by further modifying is_local_or_static_place. If so, I think that's fine. Our goal can be to reduce false positives as much as possible without introducing any new false negatives.

Could you investigate further whether we can eliminate more false positives? If not, I'd like to see some FIXME comments on is_local_or_static_place explaining its current limitations.