Restrict promotion to infallible operations about lang-team

[RalfJung]

Yes, we'll definitely use crater on each PR that could break something, and we'll get T-lang involved in the discussion should there be notable amounts of regressions. (The PRs we landed so far had 0 stable regressions in crater.)

[rfcbot]

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

psst @joshtriplett, I wasn't able to add the final-comment-period label, please do so.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. Consensus was that we're in favor of this, as long as it doesn't cause serious breakage. The backup plans give more confidence in that approach.

@RalfJung Have you considered a future-incompatibility warning here, continuing to do full promotion for now but issuing future-incompat warnings for such cases?

We're assuming the work described here would happen under the auspices of the const-eval group.

@rfcbot merge

[rfcbot]

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

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @withoutboats

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!

See this document for info about what commands tagged team members can give me.

[oli-obk]

Have you considered a future-incompatibility warning here, continuing to do full promotion for now but issuing future-incompat warnings for such cases?

That's enormously hard to do. The root problem is that we don't know it's going to be a problem for the user until mir borrowck, but the user didn't request this to happen. So we can't do a future incompat lint on all cases that stop happening, because in many many cases making it not have the 'static lifetime has no effects on the compilation success of the code. As an example:

let x = &some_expr;

will keep compiling no matter whether some_expr stops getting promoted, but

let x: &'static _ = &some_expr;

will fail to compile when some_expr stops getting promoted.

While it would likely be possible to adjust mir borrowck to be able to kind of do both analyses at the same time and only emit a future incompat warning in case of some marker, I don't know if this can be done in a reasonable amount of work and complexity.

[nikomatsakis]

@rfcbot reviewed

[cramertj]

Checking my box assuming that this change will be paired with a crater run to check for major breakage / fallout.

[nikomatsakis]

Pending PR: rust-lang/rust#77526

I raised the question on Zulip of whether we feel like an RFC is appropriate here. I do think that this is an area of "language design" where clarification would be useful, though I'm not sure if I feel the need for that to hold up landing PRs like rust-lang/rust#77526.

[nikomatsakis]

We discussed this in our lang-team meeting today. @RalfJung the sense was that we do feel like an RFC would be great here, even though it need not block implementation PRs. The point of the RFC would be to

• supercede the existing RFC on promotion and document the newer, more conservative model
• combined with pointing out the explicit syntax that can now be used
• given that we hope to achieve this transition without the use of editions, the RFC wouldn't have to cover that, though if editions are ultimately required it'd be a nice place to document what's going on

In other words, the goal of the RFC is to advertise and document the overall plan in a central place. We wouldn't anticipate a lot of opposition given the soundness implications and problems with the current model, though of course it may always happen that there are useful suggestions or other considerations that arise in the course of RFC discussion.

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

The RFC will be merged soon.

[nikomatsakis]

FCP has completed. I'm going to close the issue for now, @RalfJung we should talk about the idea of drafting an RFC or other document as described above.

[RalfJung]

I did an RFC draft: https://github.com/RalfJung/rfcs/blob/infallible-promotion/text/0000-infallible-promotion.md

However, the "guide-level" and "reference-level" explanation are still mostly stubs. I have no idea what to put there. This is also taking waaay more time than I thought it would, which is kind of draining, so I'd really appreciate some help here.

Also see this Zulip thread.