new lint: missing_must_use_on_future_types

[rmehri01]

Adds a lint that checks if Future is implemented for a type (struct or enum) and will warn if there is no #[must_use] attribute since futures must be awaited to do work, similar to how async fn works.

Example output:

error: this struct implements `Future` but is missing a `#[must_use]` attribute
  --> tests/ui/missing_must_use_on_future_types.rs:11:1
   |
LL | struct BasicStruct;
   | ^^^^^^^^^^^^^^^^^^
   |
   = note: `-D clippy::missing-must-use-on-future-types` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::missing_must_use_on_future_types)]`
help: add the attribute
   |
LL + #[must_use]
LL | struct BasicStruct;
   |

Closes #13886

changelog: [missing_must_use_on_future_types]: new lint

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Centri3 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[Centri3]

I think this would be better as foo().await, or something else that shows what the correct code is. A more complex example would be nice, i.e., this example might not get the point across

Also, we can remove no_run if you add .await, can't we?

[rmehri01]

I was trying to show accidentally missing the .await after calling foo() but yeah I agree this might not be the best example

[Centri3]

Would it not be better to start at the type instead and use implements_trait? It seems like it'd be a lot simpler...

Not sure about performance tho

[Centri3]

We should also check if we're in an external macro here.

You can add //@aux-build:proc_macros.rs at the top of your test to test macros.

[Centri3]

In the local macro case, we mostly should ensure that the span points to the right place. This could be problematic

[rmehri01]

Would it not be better to start at the type instead and use implements_trait? It seems like it'd be a lot simpler...

Not sure about performance tho

I think this wouldn't work for the SometimesFuture since it would always need to hold?

[Centri3]

I'm honestly not sure! If not then yeah, this is fine.

I'd look and see anyways because I'm not sure how implements_trait/what it calls handles not passing any arguments, or whether there's a way to make it check for any impl at all (I believe this same code would be used for T: Clone for example). It uses Obligation + InferCtxt if curious (I am).

[Centri3]

This isn't complete; I meant adding .await alongside #[must_use] in the "Use instead" example to convey the improvement this makes. Maybe also with a comment pointing this out

[Centri3]

I would like to make sure two Future impls doesn't lint twice.

One idea if they do: Store all the data needed to lint in the struct, then lint in check_crate_post using span_lint_hir_and_then.