Tracking Issue for panic_backtrace_config · Issue #93346 · rust-lang/rust (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Appearance settings

Description

Feature gate: #![feature(panic_backtrace_config)]

This is a tracking issue for configuring the capture and display of backtraces in the default panic hook, as well as exposing that configuration to third-party libraries for usage.

Public API

mod panic { #[derive(Copy, Clone, Debug, PartialEq, Eq)] #[non_exhaustive] pub enum BacktraceStyle { Short, Full, Off, } fn set_backtrace_style(BacktraceStyle); fn get_backtrace_style() -> Option; }

This API is intended to form part of the strategy for addressing the unsoundness of the std::env::set_var API on some platforms (mostly non-Windows). See #92431 (comment) for a summary.

Steps / History

• Implementation: Support configuring whether to capture backtraces at runtime #93101
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Do we need to move to a thread-local or otherwise more customizable strategy for whether to capture backtraces? See this comment for some potential use cases for this.
  • Proposed answer: no, leave this for third-party hooks.
• Bikeshed on naming of all the options, as usual.
• Should BacktraceStyle be moved into std::backtrace?
  • It's already somewhat annoying to import and/or re-type the std::panic:: prefix necessary to use these APIs, probably adding a second module to the mix isn't worth it.
• Should get_backtrace_style be exposed?
  • The Option<BacktraceStyle> return type looks a little weird, and may not mean the intuitive thing -- None represents Unsupported, not "not set" or "don't print backtraces", as might be initially assumed.
  • We may want a std::panic::report_backtrace(&mut dyn Write) instead which internally knows how to format things.