Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Never type unsafe lint improvements #125282

Merged
merged 4 commits into from
May 20, 2024

Conversation

WaffleLapkin
Copy link
Member

@WaffleLapkin WaffleLapkin commented May 19, 2024

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:

@rustbot
Copy link
Collaborator

rustbot commented May 19, 2024

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 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
Copy link
Member Author

r? @compiler-errors

@WaffleLapkin 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
Copy link
Member

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

@compiler-errors
Copy link
Member

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?

@rust-log-analyzer

This comment has been minimized.

@WaffleLapkin
Copy link
Member Author

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

@WaffleLapkin WaffleLapkin added the I-lang-nominated Nominated for discussion during a lang team meeting. label May 19, 2024
@compiler-errors
Copy link
Member

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

@WaffleLapkin WaffleLapkin force-pushed the never-type-unsafe-improvements branch from d913b16 to 434221b Compare May 19, 2024 17:10
@Noratrieb
Copy link
Member

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

probably intuitively simply because no one has needed it yet

@traviscross
Copy link
Contributor

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.

Copy link
Member

@compiler-errors compiler-errors left a comment

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

@compiler-errors
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented May 19, 2024

📌 Commit 434221b has been approved by compiler-errors

It is now in the queue for this repository.

@bors 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
@traviscross traviscross removed the I-lang-nominated Nominated for discussion during a lang team meeting. label 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
@bors bors merged commit 8855261 into rust-lang:master May 20, 2024
6 checks passed
@rustbot rustbot added this to the 1.80.0 milestone May 20, 2024
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

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`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/enum.FutureIncompatibilityReason.html#):

```rust
enum IncompatibilityWhen {
     FutureRelease,
     Edition(Edition),
}

enum IncompatibilyWhat {
    Error,
    SemanticChange,
}

enum IncompatibilityReportInDeps {
    No,
    Yes,
}
```

Tracking:
- rust-lang#123748
@WaffleLapkin WaffleLapkin deleted the never-type-unsafe-improvements branch May 20, 2024 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants