Remove edition-dependent behavior on `panic`

[traviscross]

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

Related

• Explicitly export core and std macros #139493
• Reflect explicit macro import in reference reference#2077
• Tracking Issue for future-incompatibility lint ambiguous_panic_imports #147319

[traviscross]

cc @Voultapher @petrochenkov

[Voultapher]

It wasn't clear to me before this was merged that this approved a change for the 2026 edition.

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]

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]

Was the edition timeline shortened, I would have expected 2027 to be the next one.

[petrochenkov]

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.

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]

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

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_prelude but 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]

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]

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.