Edition 2024: Make ! fall back to !

[WaffleLapkin]

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:

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

[WaffleLapkin]

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 ! (!).

[crlf0710]

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]

@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]

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

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

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.

[WaffleLapkin]

@crlf0710 do those tests look good to you?

[tmandry]

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

@rfcbot reviewed

[rfcbot]

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

[WaffleLapkin]

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

c:

[rfcbot]

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.

[lcnr]

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]

+1 to the release (and edition) notes talking about this possibility

…

On Thu, May 9, 2024, at 7:32 PM, lcnr wrote: 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 triggers this pattern which ar enot marked as `unsafe` even though 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 <https://github.com/rfcbot> reviewed — Reply to this email directly, view it on GitHub <#123508 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABF4ZTZHCPARB3WIDDNS5LZBOXLZAVCNFSM6AAAAABFZR53G6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBTGEYDMNBXGA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jackh726]

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]

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

[rfcbot]

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.

[compiler-errors]

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

@bors r+ rollup=never

[bors]

📌 Commit e79aafc has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit e79aafc with merge 9a7bf4a...

[bors]

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

[rust-timer]

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%)