add lint futures_not_send

[rkuhn]

changelog: add lint futures_not_send

fixes #5379

Remark: one thing that can (should?) still be improved is to directly include the error message from the Send check so that the programmer stays in the flow. Currently, getting the actual error message requires a restructuring of the code to make the Send constraint explicit.
It now shows all unmet constraints for allowing the Future to be Send.

[rkuhn]

forgot to mention: I think this could become a “restriction” lint (as it applies to some projects but not others, depending on their target audience)

[rkuhn]

Thanks for your review @eddyb!

[rkuhn]

@eddyb brought up a point on discord: in some cases it may depend on the concrete choice of type parameter whether the resulting Future is Send. This could be checked by bringing T: Send constraints into scope for all type parameters and seeing if that fixes the obligation error.

After thinking about it for a while, I come to the conclusion that while this is an interesting additional feature, it is outside of the scope I intend for this lint: this lint is meant to support library authors in ascertaining that the Futures returned by their library can successfully be used on a multithreaded executor. This is why the lint is opt-in. If an author opts into this check, they want to ensure that their Futures are Send — and the non-generic ones will need to be Send, as will be the library-supplied components of the generic ones. So I don’t see a plausible use-case for wanting futures to be Send but permitting non-Send type parameters to potentially thwart this effort. The lint can be switched off for individual functions or modules where this is too restrictive.

Put differently, the use-case of a library that wants to leave the Send-ness of all its Futures open to the user seems too narrow to me, I can only envision very generic Future transformators to fall into this category. That case will probably be better handled by an explicit compile-time assertion (as is done in many projects already).

---

I’ll finish this PR once rust-lang/rust#70821 has been merged.

[eddyb]

I can only envision very generic Future transformators to fall into this category. That case will probably be better handled by an explicit compile-time assertion (as is done in many projects already).

This is a good point and one that I wasn't aware of.

[rkuhn]

@flip1995 I have amended the documentation and updated to the latest rustc master, using the nice async/await error reporting. To my mind it is ready.

[bors]

☔ The latest upstream changes (presumably #5438) made this pull request unmergeable. Please resolve the merge conflicts.

[flip1995]

@rkuhn Thanks! Can you remove the tests/ui/future_not_send.stdout file please? After that this is ready to get merged.

[bors]

☔ The latest upstream changes (presumably #5470) made this pull request unmergeable. Please resolve the merge conflicts.

[rkuhn]

done

[flip1995]

Thanks!

@bors r+

[bors]

📌 Commit d2cbbff has been approved by flip1995

[bors]

⌛ Testing commit d2cbbff with merge 3379faf...

[bors]

💔 Test failed - checks-action_test

[flip1995]

@bors retry

[bors]

⌛ Testing commit d2cbbff with merge f1fb815...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: flip1995
Pushing f1fb815 to master...