Never type unsafe lint improvements by WaffleLapkin · Pull Request #125282 · rust-lang/rust (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation12 Commits4 Checks6 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

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

(libs team decided not to add absurd to std)

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

rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

labels

May 19, 2024

WaffleLapkin changed the title~~Never type unsafe improvements~~ Never type unsafe lint improvements

May 19, 2024

reason: FutureIncompatibilityReason::FutureReleaseSemanticsChange,
reference: "issue #123748 https://github.com/rust-lang/rust/issues/123748",
};
report_in_external_macro

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

didnt know about this :0

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?

This comment has been minimized.

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

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

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

probably intuitively simply because no one has needed it yet

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

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.
Stabilize Rust 2024.
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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK in that case I think this is good to go

📌 Commit 434221b has been approved by compiler-errors

It is now in the queue for this repository.

bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

May 19, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request

May 20, 2024

…iaskrgr

Rollup of 5 pull requests

Successful merges:

rust-lang#125034 (Weekly cargo update)
rust-lang#125093 (Add fn into_raw_with_allocator to Rc/Arc/Weak.)
rust-lang#125282 (Never type unsafe lint improvements)
rust-lang#125301 (fix suggestion in E0373 for !Unpin coroutines)
rust-lang#125302 (defrost RUST_MIN_STACK=ice rustc hello.rs)

r? @ghost @rustbot modify labels: rollup

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

May 20, 2024

Rollup merge of rust-lang#125282 - WaffleLapkin:never-type-unsafe-improvements, r=compiler-errors

Never type unsafe lint improvements

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

IMO we ought to have three enums instead of FutureIncompatibilityReason:

enum IncompatibilityWhen {
     FutureRelease,
     Edition(Edition),
}

enum IncompatibilyWhat {
    Error,
    SemanticChange,
}

enum IncompatibilityReportInDeps {
    No,
    Yes,
}

Tracking:

rust-lang#123748

Labels

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.