Tracking Issue for future-incompatibility lint `unstable_imports`

[mejrs]

This is the tracking issue for the unstable_imports future-compatibility warning and other related errors. The goal of this page is to describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.

What is the warning for?

Several import paths through the intrinsics module were accidentally allowed. They are stably available through other modules; these import paths should be used instead.

Why was this change made?

Supporting this behavior (through the rustc_allowed_through_unstable_modules attribute) significantly complicates stability checking in the compiler, we would like to be able to get rid of the hacks required for it.

Example

use {std/core}::intrinsics::{transmute/copy/copy_nonoverlapping/write_bytes};

Recommendations

Import these items through the {core/std}::mem module (for transmute) and {std/core}::ptr module (for the other items) instead. rustfix can apply these fixes automatically.

When will this warning become a hard error?

The fallout, at this time, would be significant, see #157082 (comment). Especially older rand-core versions are heavily affected, but note that since that crater run new minor versions of the affected rand-core crate have been released (much thanks to @dhardy).

Steps

• Implement the lint
• Raise lint level to deny
• Change the lint to report in dependencies
• Switch to a hard error

Implementation history

• Support unstable moves via stable in unstable items #95956
• rustc_allowed_through_unstable_modules: require deprecation message #136434
• add suggestion for rustc_allowed_through_unstable_modules attribute #162155
• implement FCW for rustc_allowed_through_unstable_modules items #163161