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

[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.

[WaffleLapkin]

I remembered that this should go through a T-types FCP. So here is a summary for the changes made/proposed here:

In the next edition (2024) unconstrained diverging variables will fallback to !, instead of the () which is currently used. While this does not directly unblock never type stabilization, this is a stepping stone on the way there. The plan is to change the fallback in 2024, allow active users to port their code and make sure it still works, make sure the lints work as they should, etc; And then, once we are satisfied with all of that, bring the same change to all editions.

This is what we agreed with the lang team the process should be, but I want to double check that T-types does not have objections.

As a reminder "diverging variable" is what we create when doing a never-to-any coercion (we insert them everywhere eagerly), for example:

{ return /* : ! */ } /* ?D, diverging variable */;

This does affect code semantics, because the fallback can very easily flow back into "live code":

match b {
    true => unsafe { core::mem::zeroed() }, // we will infer zeroed's type from the fallback
    false => return,
}

I'm working on lints to make sure users know that this change might happen / that they might have a foot gun. There is a lint against fallback affecting unsafe code (see #123748) and there will be a lint against obligations that can't be satisfied with a different fallback.

To reiterate: I'm proposing to change the never type fallback to ! (the never type itself) in the next edition, does that sound good?.

[BoxyUwU]

@rfcbot fcp merge

context:
Lang fcp information
Types fcp information

note: This doesn't stabilise naming the never type only the fallback of diverging type variables (though it can already be named in some circumstances on stable already) i.e. this does not allow writing impl Foo for !.

[compiler-errors]

Can't do another fcp on top of a preexisting one I think

[compiler-errors]

Let me see if I can cancel the last one, start a new one w/ both lang, and just check all of the preexisting lang boxes

[compiler-errors]

@rfcbot fcp cancel

[rfcbot]

@compiler-errors proposal cancelled.

[compiler-errors]

@rfcbot merge

[rfcbot]

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

• @BoxyUwU
• @aliemjay
• @compiler-errors
• @jackh726
• @joshtriplett
• @lcnr
• @nikomatsakis
• @oli-obk
• @pnkfelix
• @scottmcm
• @spastorino
• @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.

[lcnr]

this is a confusing enum variant name, I would like it to be more descriptive

[WaffleLapkin]

Do you have an idea what could be a better name?

The reason I named it like that, is that it is inherently confusing, in a way. + it's probably on the way to be removed.

[lcnr]

ContextDependent

also, instead of naming the variants FallbackToX, I personally prefer using DivergingFallbackBehavior::ToNever and stop using a blob import for the variants

[WaffleLapkin]

DivergingFallbackBehavior::ToNever is a bit too long and annoying IMO, but sure. ContextDependent sounds good.

Should I rename things in this PR?

[lcnr]

i'd like that, given that these are style nits I don't consider them to be blockin though

[WaffleLapkin]

Done

[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.