Apply missing transmute annotations lint

[GTimothy]

Best reviewed case by case. Special care should be taken when involving pointers.

The missing_transmute_annotations lint.
The point of the lint is that in order to ensure that the safety invariant holds, the transmute source and destination should be explicitly fixed.

Remarks:

• many, many many suggested fixes were invalid rust code, as they include paths when they should just use the type in scope.
  I kept the initial suggestion and the fixed suggestion in separate commit so that the issue can be observed easily and the clippy lint can be fixed before even considering enabling it.
• the lint currently fires inside local expanded code (not in calls to external macros). Having dynamically added src and dest inside a macro is a bit iffy and sometimes impossible, as #general > Running clippy on the rustc repo @ 💬 @scottmcm points out. Perhaps there should be a lint about that :)

Notes:

• For the transmute call in define_valid_range, the transmute suggestion was wrong because:
  • we get a different suggestion for every call of the macro
  • pattern_types! are strangely formatted. The issue is being worked on in missing_transmute_annotations: handle pattern_types in suggestion rust-clippy#17613.
    Notably, the proper fix may be to change the display impl for pattern_types (see missing_transmute_annotations: handle pattern_types in suggestion rust-clippy#17613 (comment) by @ada4a

Yet I still propose a fix because this case seems clear cut, it may be an exception to the iffiness rule.

• The suggestion in main...GTimothy:rust:missing-transmute-annotations#diff-4fbe4e316a3fa623f3edea42a8d3ab2ec54de32c3ec8e46e5d5d58a562a86813 was muted because it was very very complex and inside a macro.

• core_arch suggestions are all of the same nature, and the suggestions are wrong because they:

  • use entire paths for the suggested type
  • do not use type aliases that are much leaner.

• I have no clue how this dark magic works:

  unsafe { mem::transmute::<*mut (), fn(core::alloc::Layout)>(hook) } 

Related: "Enforce even more library clippy lints in CI" by @ChrisDenton: #161328

[rustbot]

stdarch is developed in its own repository. If possible, consider making this change to rust-lang/stdarch instead.

cc @Amanieu, @folkertdev, @sayantn

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in library/core/src/fmt/rt.rs

cc @m-ou-se

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

[RalfJung]

FWIW I am not sure this makes the code better. The type of a and b is right there in the function signature, what is the point in repeating it?

View changes since the review

[GTimothy]

maybe
a) we could add an expect/allow instead.
b) the lint should not fire in this case. Right now, the lint does not fire if the transmute is the only element in the function, which is not the case here, it is a bit more complex.