Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow disabling the panic_impl defined by std #80

Closed
morr0ne opened this issue Aug 8, 2022 · 1 comment
Closed

Allow disabling the panic_impl defined by std #80

morr0ne opened this issue Aug 8, 2022 · 1 comment
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

Comments

@morr0ne
Copy link

morr0ne commented Aug 8, 2022

Proposal

Problem statement

It's not currently possible to mark a function with #[panic_handler] in std programs. The reason is quite simple: Only one panic_impl can be defined per program and std already defines one. The obvious solution to this problem is to allow users to disable the panic_impl defined by std

Motivation, 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:

  • Bypass the default implementation as it might be desirable to avoid all the other stuff that std sets up
  • Allow the use of rust programs in more constrained environments without having to resort to no_std
  • Allow to assert at compile time that a program cannot panic with tricks like this, which currently only work in no_std environments.

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:

cargo +nightly build -Zbuild-std=no_panic_impl

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.

@morr0ne morr0ne added api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api labels Aug 8, 2022
@joshtriplett
Copy link
Member

We haven't committed to supporting feature flags in build-std, but this is a nightly feature, and it seems fine to have it in nightly for now. We can consider it further when we have stabilized build-std and then start considering how or if to support configurability of std. (Note for such future consideration: we're unlikely to want no_* negative features.)

That said, could you please confirm that you've usefully built programs with this that call into functionality from std and don't actually need a panic handler?

@joshtriplett joshtriplett added the ACP-accepted API Change Proposal is accepted (seconded with no objections) label May 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

2 participants