Skip to content

Allow disabling the panic_impl defined by std #80

Closed
@morr0ne

Description

@morr0ne

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    ACP-acceptedAPI Change Proposal is accepted (seconded with no objections)T-libs-apiapi-change-proposalA proposal to add or alter unstable APIs in the standard libraries

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions