Added diagnostic/suggestion for core::pin::pin! in addition to Box::pin if Unpin isn't implemented

[ndrewxie]

Currently, if an operation on Pin<T> is performed that requires T to implement Unpin, the diagnostic suggestion is to use Box::pin ("note: consider using Box::pin").

As others have noted, using pin! avoids a heap allocation, so it should be suggested as well (and probably over Box::pin whenever possible).

This PR adds the diagnostic "consider using Box::pin if you want ownership of the pinned value", and updates tests to match.

Addresses/attempts to address #109964

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cjgillot (or someone else) soon.

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

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[cjgillot]

What's the policy about mentioning core in an diagnostic message? Should we mention the pin! macro instead?

I'm not convinced about the "if you want ownership of the pinned value" part. The important difference between the two is the local storage. What about: "if you need to access the pinned value outside of the current scope"?

[ndrewxie]

Yeah, I suppose the std::pin::pin! macro would be better

Also yeah, that message works better, it captures the "local pin" semantics far better. I'll make the changes and commit

[ndrewxie]

@rustbot review

[cjgillot]

Suggested change

	note = "consider using `std::pin::pin!`\nconsider using `Box::pin` if you need to access the pinned value outside of the current scope",
	note = "consider using the `pin!` macro\nconsider using `Box::pin` if you need to access the pinned value outside of the current scope",

Works for both std and no-std 😄

r=me with commits squashed

[ndrewxie]

Whoops, I was trying to sort out some git stuff (git won't let me switch to the branch for this issue for some reason, git clone literally didn't clone it), and in the process of renaming the branch I accidentally closed it... Is it OK for me to create a new PR and r= you, @cjgillot ? Sorry😅

I re-made the pull request as #110259