RFC: Backtrace in core

[JDuchniewicz]

Rendered
Based on Backtrace in core PR.

Remaining concerns:

• Check if impl Backtrace return type works with backtrace_create()
• Address more abstract pointer to Backtrace type - increase size from 1 word to 2 words
• Clarify weak lang items
• Why use struct instead of trait

[yaahc]

@nrc I don't think we can use Box with this destined for core. Also, I'm not sure what you mean by impl Backtrace here. If you mean fn backtrace_create(ip: usize) -> impl Backtrace then I'd be surprised if that works, though I'm not super experienced with extern "Rust" so maybe its fine to have a generic type here.

[Aaron1011]

What's the current status of this RFC?

[yaahc]

What's the current status of this RFC?

The current status is that we don't intend to merge this RFC. It was written as one of the potential paths to moving error into core assuming generic member access didn't work out but at this point it seems extremely likely that we will merge the generic member access RFC once we finish the provider RFC. That RFC provides a superset of the functionality provided by fn backtrace() making it unnecessary. Once we have generic member access we will remove fn backtrace and immediately move Error into core.

For context:

• RFC: Generic member access for dyn Error trait objects #2895
• Add provide_any module to core #3192
• Move the Error trait into core (without fn backtrace) rust#90328
• PoC: implement core::panic::panic_error yaahc/rust#1

[nikomatsakis]

@yaahc shall we close it, then?