Never type unsafe lint improvements

[WaffleLapkin]

• Move linting code to a separate method
• Remove mentions of core::convert::absurd (Add core::convert::absurd #124311 was rejected)
• Make the lint into FCW

The last thing is a bit weird though. On one hand it should be EditionSemanticsChange(2024), but on the other hand it shouldn't, because we also plan to break it on all editions some time later. Also, it's weird that we don't have FutureReleaseSemanticsChangeReportInDeps, IMO "this might cause UB in a future release" is important enough to be reported in deps...

IMO we ought to have three enums instead of FutureIncompatibilityReason:

enum IncompatibilityWhen {
     FutureRelease,
     Edition(Edition),
}

enum IncompatibilyWhat {
    Error,
    SemanticChange,
}

enum IncompatibilityReportInDeps {
    No,
    Yes,
}

Tracking:

• Tracking Issue for Rust 2024: Make ! fall back to ! #123748

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
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

[WaffleLapkin]

r? @compiler-errors

[compiler-errors]

didnt know about this :0

[compiler-errors]

Do we already have consensus from T-lang that this is OK to bump to a FCW? I can't remember the policy around that. If you can find something, could you link it?

[WaffleLapkin]

I'm not aware of any policies with FCWs, ig we could nominate for T-lang?

[compiler-errors]

Yeah, let's do that. Also would like their input if they prefer this start out as an edition warning or an FCW.

[Nilstrieb]

Also, it's weird that we don't have FutureReleaseSemanticsChangeReportInDeps,

probably intuitively simply because no one has needed it yet

[traviscross]

The plan that was FCPed (twice) by the lang team in #123508 is:

1. Prior to the stabilization of Rust 2024:
   • Change fallback to ! on the nightly 2024 edition.
   • Add a lint against fallback affecting a generic that is passed to an unsafe function.
     • Perhaps make this lint deny-by-default or a hard error in Rust 2024.
   • Add a future incompat lint for some/most of the code that will be broken by fallback to !.
   • Add documentation/migration tools for people adopting the 2024 edition.
2. Stabilize Rust 2024.
3. At a later date when 2024 edition adoption is widespread:
   • Make the breaking change to fall back to ! always everywhere.
   • Change Infallible = !.
   • Stabilize ! (!).

My read is that the plan implies that this lint (about fallback affecting a generic that is passed to an unsafe function) should go immediately to a FCW. While the second bullet under item 1 does not specify this directly, it's covered by the third bullet, since this lint is also catching code that will be broken by fallback to !. Further, since the plan is to change fallback to ! always everywhere, that implies that all of these lints should be FCWs.

Put differently, it would not make sense to lint harder against #125289 than against #123939 when the latter is probably the more critical lint.

The meeting minutes from 2024-04-10 also confirm that people wanted these lints to fire in all editions.

[compiler-errors]

OK in that case I think this is good to go

[compiler-errors]

@bors r+ rollup

[bors]

📌 Commit 434221b has been approved by compiler-errors

It is now in the queue for this repository.