Allow disabling the panic_impl defined by std #80
Labels
ACP-accepted
API Change Proposal is accepted (seconded with no objections)
api-change-proposal
A proposal to add or alter unstable APIs in the standard libraries
T-libs-api
Proposal
Problem statement
It's not currently possible to mark a function with
#[panic_handler]
in std programs. The reason is quite simple: Only onepanic_impl
can be defined per program and std already defines one. The obvious solution to this problem is to allow users to disable thepanic_impl
defined by stdMotivation, use-cases
It is already possible to define custom
panic_impl
in no_std environments. There are certain situations where it would be useful in normal programs:Furthermore I believe that making std more configurable in general is always a good thing.
Solution sketches
The best solution, that doesn't require a rework of how std works, is making the
panic_impl
togglable via a cargo feature. Any user that wishes to disable it would need to build std themself + enabling the corresponding feature. Thus making it impossible to accidentally enable.I opened a pull request over at rust-lang/rust#100156 that does what described above by adding a feature called
no_panic_impl
.Right now this would require nightly rust to actually use since it relies on build-std and build-std-features.
Example usage:
Links and related work
I was asked here to open an ACP since this should qualify as unstable api change.
I also asked some questions over on zulip so the conversation might be continued there:
https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Allow.20custom.20panic_handler.20when.20building.20std
What happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.
The text was updated successfully, but these errors were encountered: