Uplift `clippy::let_underscore_lock` to `rustc`

[estebank]

The lint clippy::let_underscore_lock should be uplifted into rustc from clippy, as this is such a big potential issue that it shouldn't require people to opt-into clippy to be detected.

[a2aaron]

@rustbot claim

Hi! I'm the person that Cassie from twitter was talking about. I'd like to help work on this issue if possible.

There's some additional discussion about the clippy::let_underscore_lock lint here: rust-lang/rust-clippy#8859. The main suggestion was to also use the #[clippy::has_significant_drop] attribute or to possibly use #[must_use] + nontrivial Drop implementation as the heuristic to trigger the lint on.

[clarfonthey]

So, I was thinking about the use cases for this and was wondering if this is necessarily the right approach to take. In general, locks should contain the values that need mutual exclusion, so that the scope of the lock can be determined simply by how long the values inside are needed. That way, you can simply annotate locking methods with #[must_use] to get the right behaviour.

However, there are definitely a fair number of cases where significant drops are useful, described in this section of the nomicon. One thing to consider here is that Rust 1.0 only had lexical drops, meaning that values were always kept until the end of the scope, but nowadays, that can't be guaranteed.

Because we don't enforce lexical drops any more, there could be genuine value to some kind of dedicated syntax for these; I'm thinking something along the lines of Python's with statements, like:

with mutex.lock() {
   // guarded code
}

We could then have some sort of attribute like must_scope which is similar to must_use, but encourages the caller to put the value into a with block.

Alternatively, if we don't want to completely enclose the code, we could use something like golang's defer keyword, which is essentially just sugar for "run this after scope ends, please."

However, if we don't think that this line of reasoning is justifiable, I think that maybe simply adding this method would do:

impl<T> MutexGuard<'_, T> {
    pub fn guard<U, F: FnOnce() -> U>(self, f: F) -> U {
        let val = f();
        drop(self);
        val
    }
}

And, if someone wants to use a lock purely for its effects, they can just call mutex.lock().guard(|| { ... }), and #[must_use] still applies.

[estebank]

Even if we provide a guard method, we would still need a linting mechanism, we would "just" suggest a different remediation.

[clarfonthey]

What would be wrong with #[must_use] as said linting mechanism?

[CAD97]

The problem is that let _ = f(); explicitly silences #[must_use]. In effect, let_underscore_drop as a lint is a strengthening of #[must_use] to not be silenced by let _.

The best way to handle this is probably something like #[must_use(and_let_underscore_is_a_footgun)] to ask for the stronger lint.

[clarfonthey]

Oh, I see now what the issue is. Yeah… that makes a lot more sense. I seem to have gotten hyperfocused on one aspect of my argument that that part, which is the main part, flew over my head.