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

Edition 2024: Make ! fall back to ! #123508

Merged
merged 5 commits into from
Jun 12, 2024
Merged

Conversation

WaffleLapkin
Copy link
Member

@WaffleLapkin WaffleLapkin commented Apr 5, 2024

This PR changes never type fallback to be ! (the never type itself) in the next, 2024, edition.

This makes the never type's behavior more intuitive (in 2024 edition) and is the first step of the path to stabilize it.

r? @compiler-errors

Tracking:

@WaffleLapkin WaffleLapkin added T-lang Relevant to the language team, which will review and decide on the PR/issue. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. F-never_type `#![feature(never_type)]` labels Apr 5, 2024
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 5, 2024
@WaffleLapkin
Copy link
Member Author

WaffleLapkin commented Apr 5, 2024

Nominating for T-lang discussion. This PR changes never type fallback in the 2024 edition. I'm asking for approval, given that this is part of the following plan:

  1. Prior to the stabilization of Rust 2024:
    • Change fallback to ! on the nightly 2024 edition (this PR).
    • 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 ! (i.e. check trait obligations on diverging type variables which are affected by fallback).
    • Add documentation/migration tools for people adopting 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 ! (!).

@WaffleLapkin WaffleLapkin added I-lang-nominated Nominated for discussion during a lang team meeting. A-edition-2024 Area: The 2024 edition labels Apr 5, 2024
@traviscross traviscross changed the title Edition 2024: Make ! fallback to ! Edition 2024: Make ! fall back to ! Apr 7, 2024
@compiler-errors compiler-errors added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 9, 2024
@crlf0710
Copy link
Member

Might worth add #66173 and #66757 as tests.

fn test66173() {
     let x = match true {
          true => Default::default(),
          false => panic!("..."),
     };
     // print `x` type
}

fn test66757() {
     struct E;

     impl From<!> for E {
          fn from(_: !) -> E {
               E
          }
     }

     #[allow(unreachable_code)]
     fn foo(never: !) {
          <E as From<!>>::from(never);  // Ok
          <E as From<_>>::from(never);  // Should the inference fail?
     }
}

@nikomatsakis
Copy link
Contributor

@rfcbot merge

This PR changes fallback to ! in Rust 2024. This has raised concerns about two particular kinds of problems, and we have plans to add two lints to catch common errors

  • Add a lint against fallback affecting a generic that is passed to an unsafe function.
  • Add a future incompat lint for some/most of the code that will be broken by fallback to ! (i.e. check trait obligations on diverging type variables which are affected by fallback).

These lints are valuable in all editions because they both address "suspicious" / error-prone code. They also catch the cases that could change behavior. Ideally we'll have them before we get to the new edition, if not, we'll want to revisit whether to proceed.

@rfcbot
Copy link

rfcbot commented Apr 10, 2024

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Apr 10, 2024
@WaffleLapkin
Copy link
Member Author

@crlf0710 do those tests look good to you?

@tmandry
Copy link
Member

tmandry commented Apr 17, 2024

I'm happy with doing this, contingent on having mitigations to avoid unsafe code changing behavior.

@rfcbot reviewed

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Apr 17, 2024
@rfcbot
Copy link

rfcbot commented Apr 17, 2024

🔔 This is now entering its final comment period, as per the review above. 🔔

@WaffleLapkin
Copy link
Member Author

@tmandry fyi the unsafe mitigation lint is being implemented in #123939. Needs a bit more polish, but it is generally working

c:

@traviscross traviscross removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Apr 24, 2024
@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Apr 27, 2024
@rfcbot
Copy link

rfcbot commented Apr 27, 2024

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@rfcbot rfcbot added the to-announce Announce this issue on triage meeting label Apr 27, 2024
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Apr 29, 2024
@traviscross traviscross removed the S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). label Apr 30, 2024
@lcnr
Copy link
Contributor

lcnr commented May 9, 2024

from a types team perspective, this change seems straightforward. While I am somewhat concerned that linting all affected cases may prove difficult, that's the responsibility of t-lang :p so I am just going to trust you with that.

Add a lint against fallback affecting a generic that is passed to an unsafe function.

I could imagine that there exist (hopefully internal) functions which trigger this pattern which are not marked as unsafe even though they can cause unsoundness when used incorrectly. I expect that lint to therefore not catch all places where this inference change causes unsoundness. I think that this is acceptable. I would like us to explicitly mention this possibility in the edition guide for this change.

@rfcbot reviewed

@nikomatsakis
Copy link
Contributor

nikomatsakis commented May 10, 2024 via email

@jackh726
Copy link
Member

I agree with @lcnr here that linting may prove difficult for at least some set of cases. It's a bit interesting because while it is T-lang's call on where we must lint, there may be some set of cases where we can lint but only with invasive type system changes (e.g. for some kind of tracking) and that would be T-types.

I overall am happy to have this land, T-lang should be mindful of the potential challenges to linting and that it may make sense to delay this until we have the lints written first.

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels May 15, 2024
@rfcbot
Copy link

rfcbot commented May 15, 2024

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label May 25, 2024
@rfcbot
Copy link

rfcbot commented May 25, 2024

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@rfcbot rfcbot added the to-announce Announce this issue on triage meeting label May 25, 2024
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Jun 7, 2024
@compiler-errors
Copy link
Member

This finished FCP 👍 sorry for taking so long to r+

@bors r+ rollup=never

@bors
Copy link
Contributor

bors commented Jun 11, 2024

📌 Commit e79aafc 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 Jun 11, 2024
@bors
Copy link
Contributor

bors commented Jun 12, 2024

⌛ Testing commit e79aafc with merge 9a7bf4a...

@bors
Copy link
Contributor

bors commented Jun 12, 2024

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 9a7bf4a to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 12, 2024
@bors bors merged commit 9a7bf4a into rust-lang:master Jun 12, 2024
7 checks passed
@rustbot rustbot added this to the 1.81.0 milestone Jun 12, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (9a7bf4a): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.3% [1.3%, 1.3%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -0.2%, secondary 2.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.5% [2.5%, 2.5%] 1
Regressions ❌
(secondary)
2.3% [2.3%, 2.3%] 1
Improvements ✅
(primary)
-2.9% [-2.9%, -2.9%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.2% [-2.9%, 2.5%] 2

Cycles

Results (primary 1.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
3.2% [2.5%, 3.8%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.9% [-0.9%, -0.9%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.8% [-0.9%, 3.8%] 3

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 676.102s -> 675.928s (-0.03%)
Artifact size: 320.10 MiB -> 320.08 MiB (-0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-edition-2024 Area: The 2024 edition disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. F-never_type `#![feature(never_type)]` finished-final-comment-period The final comment period is finished for this PR / Issue. merged-by-bors This PR was explicitly merged by bors. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.