Repository navigation
Remove edition-dependent behavior on panic #151084
Description
As @ehuss said:
It wasn't clear to me before this was merged that this approved a change for the 2026 edition. Can we remove that edition check and go through the process for adding new features to an edition? (Or, preferably, if this ends up changing for all editions, then there will be no additional work to do.)
Originally posted by @ehuss in #139493 (comment)
Let's please remove the edition-dependent behavior until we separately accept this within a future edition.
cc @rust-lang/edition
Activity
traviscross commentedon Jan 13, 2026
cc @Voultapher @petrochenkov
Voultapher commentedon Jan 13, 2026
I added that check as a hedge against forgetting to address it in the future. Not sure if "not doing something we begrudgingly do as a hack because of backwards compatibility" counts as a new feature.
traviscross commentedon Jan 14, 2026
It counts as an edition item. Those go through a particular process. It'd actually be good if we could avoid ever making this an edition item (by breaking it in all editions). E.g., check back in after some releases and see whether we can make that FCW deny-by-default and warn-in-deps.
Voultapher commentedon Jan 14, 2026
Was the edition timeline shortened, I would have expected 2027 to be the next one.
petrochenkov commentedon Jan 14, 2026
I think that the current processes over-extend the lang team responsibilities, in general.
IMO, the language should just say that "X vs Y ambiguity is an error", and compatibility lints are a compiler's way to deviate from the language to accommodate for real world concerns, so they can use whatever hacks necessary to do that, including editions, without putting any of that into language documentation. (I.e. the panic part of rust-lang/reference#2077 should not exist.)
traviscross commentedon Jan 15, 2026
@ehuss and I are speaking mostly from an Edition team perspective. Each edition item is documented in the Edition Guide. Each gets an edition tracking issue. Each generally needs an edition migration. When we do crater testing for the edition, each needs to be understood and accounted for in those analyses. Etc.
It's for those reasons that we can't have something in the code that is in fact an edition item but which we have not tracked and for which we have not taken the appropriate steps. I.e., we can't lose track of edition items as it'll cause problems for us later, so we need these to go through a process so we can track them along with all other such items in a consistent way.
Voultapher commentedon Jan 15, 2026
While I understand the motivation it conflates different aspects. The edition guide does not precisely track N+1 order effects, for example it doesn't mention
no_implicit_preludebut there is edition specific behavior bound to that. There are plenty of ways for the compiler to produce edition specific behavior without explicitly checking the edition. What the edition guide can realistically aim for, is tracking edition items that are deliberate edition items and will stay so for the foreseeable future. The hack we added in #139493 will be removed again in a year or two, that's not how edition items usually work.Voultapher commentedon Jan 15, 2026
The check as it stands makes the potential blast radius smaller and will lead to fewer headaches for our users because their project doesn't compile anymore after upgrading rustc. If we want to make our users' lives worse for the sake of some abstract process that realistically can't achieve the goals it aims for seems like a sadly inflexible thing to do.
jyn514 commentedon Jan 15, 2026
i think it would help to distinguish “tracking edition changes” from whether the edition team gets to control whether things are added to the edition. the first thing seems clearly good to me even if this ends up being reverted in a year.
traviscross commentedon Jan 15, 2026
It was simply missed. That 2018 change should have had an edition guide chapter.
What do you have in mind?
If we later stabilize something in all editions, we simply note that in the edition guide chapter. See, e.g.:
https://doc.rust-lang.org/nightly/edition-guide/rust-2024/missing-macro-fragment-specifiers.html
traviscross commentedon Jan 15, 2026
Adding something to a particular numbered edition requires sign-off from both the underlying team (e.g. lang) and the edition team.
I didn't catch the edition-specific behavior when signing off on #139493 as a lang matter -- there was a lot of churn in that PR -- otherwise I would have flagged it then.
Nobody wants to create headaches for our users or make our users' lives worse. Certain processes are necessary for edition management so as to ensure that we uphold the assurances about editions that we promise our users. I.e., the processes are there to make users' lives better.
We're happy for this to be an edition item if that turns out to be the best way to do this. We just need it then done correctly according to the process.
Voultapher commentedon Jan 15, 2026
That just does a lot of heavy lifting, I for one don't intend to subject myself to that process. Which in practice means, someone will remove it and then let's see who feels like going through it. It's telling that everyone complaining about the process didn't show any initiative in doing so themselves. The time we spent discussing in this issue could have been spent initiating the process.
By generating code dependent on edition specific behavior and by depending on code depending on edition specific behavior.
RalfJung commentedon Jan 30, 2026
Is there a summary somewhere of what this "edition-dependent behavior" even is that this issue is tracking? #139493 is a huge PR.
Whether or not compilation succeeds or fails is a lang matter, including any compatibility exceptions. Many of these compatibility exceptions exist not just for a transition but become part of the language long-term. The Reference would not be doing its job if those cases were not documented there. Some are temporary, but even then -- lang is generally closely involved for future-compat lints.
Voultapher commentedon Jan 30, 2026
The reference kind of explains it. But it's probably easier to summarize it here:
The code that turns the panic ambiguity error into the
ambiguous_panic_importslint only triggers for Rust Edition <= 2024.