Add let_underscore_drop_guard lint.

[theemathas]

This lint is similar to the existing let_underscore_lock lint, but applies to DropGuard instead of MutexGuard and similar types. It is deny-by-default, like let_underscore_lock. (Note that the related let_underscore_drop lint is allow-by-default.)

Relevant discussion: #t-libs > Linting `let _ = DropGuard::new(....);`

Note that DropGuard is a newly stabilized type, currently in 1.100 beta, and will be on the 1.100 stable release on November 12.

Tracking issue for DropGuard: #144426

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
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 18 candidates

[theemathas]

Lang-nominating to ask for approval for adding a new lint. Also, does it make sense to beta-backport this so that we have the lint at the same time as DropGuard being stabilized? (Although based on zulip discussion, it seems to me like T-libs doesn't want this to be backported, which I find a bit surprising.)

[Jules-Bertholet]

As discussed in the Zulip thread, perhaps we want a more general mechanism here?

[scottmcm]

I agree it makes sense to have a lint to catch this kind of problem with drop guards for the same reason as mutex guards.

@rfcbot fcp merge lang

I see the note that a more general mechanism might be nice, and I don't disagree, but we can always remove any behaviour from this lint in future should the general mechanism be created, so I don't see a need to reject this one. If we end up with another dead name in the removed-lints list eventually, so be it.

[rust-rfcbot]

@scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
cc @rust-lang/libs-ping: FCP proposed for libs, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[programmerjake]

Although based on zulip discussion, it seems to me like T-libs doesn't want this to be backported, which I find a bit surprising.

I think this should be backported. Do you have a link to where some of T-libs disagrees? (I happen to be on T-libs but not on the FCP list.)
Edit: the link #t-libs > Linting `let _ = DropGuard::new(....);` @ 💬

[petrochenkov]

As discussed in the Zulip thread, perhaps we want a more general mechanism here?

I agree with this, MutexGuard previously, DropGuard now, some other type next, but they are all the same pattern.