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

Proposal: get rid of nightly features in gstd #3524

Closed
StackOverflowExcept1on opened this issue Nov 26, 2023 · 0 comments · Fixed by #3527
Closed

Proposal: get rid of nightly features in gstd #3524

StackOverflowExcept1on opened this issue Nov 26, 2023 · 0 comments · Fixed by #3527
Assignees
Labels
C1-feature Feature request

Comments

@StackOverflowExcept1on
Copy link
Member

StackOverflowExcept1on commented Nov 26, 2023

Problem to Solve

Do we need nightly features in gstd at all?

  1. Once we merge new allocations and set memory limits to 4GB  #3472, out of memory errors will become very rare, so there is no point in feature(alloc_error_handler)

  2. Regarding the feature(panic_info_message): core::panic::PanicInfo implements Display and will format the panic message: panicked at {file}:{line}:{column}:\n{msg}

    Current implementation of gstd uses custom format: '{msg}', {file}:{line}:{column}. Should we use #[feature(panic_info_message)] just to implement a custom format of panic message? I think we can parse the String in a standard format and convert it to a custom format instead of requiring nightly toolchain.

Possible Solution

  1. Convert the output of <core::panic::PanicInfo as Display> to our custom format.
    It's probably easy, but it's worth considering Rust <1.73:
    Change default panic handler message format. rust-lang/rust#112849

    Discussed:

    • debug feature: Display as is
    • no debug feature: get message from Display, w/o location
  2. Make our custom format obsolete

Notes

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C1-feature Feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant