Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upMake `handle_alloc_error` default to panic (for no_std + liballoc) #66741
Comments
This comment has been minimized.
This comment has been minimized.
|
Proposing FCP for deciding to adopt this approach: @rfcbot fcp merge |
This comment has been minimized.
This comment has been minimized.
|
Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
This comment has been minimized.
This comment has been minimized.
Should we still adopt this default behavior if the @rfcbot concern what if stable attribute |
This comment has been minimized.
This comment has been minimized.
|
What's the way forward here? Personally I would answer this simply with "yes":
|
This comment has been minimized.
This comment has been minimized.
|
I’m ok with that. I’ll make this not a blocking concern for now, but anyone feel free to discuss some more. @rfcbot resolve what if stable attribute
This proposal still needs at least 6 out of the 8 members of @rust-lang/lang and @rust-lang/libs who haven’t yet to approve it in #66741 (comment) |
This comment has been minimized.
This comment has been minimized.
|
I personally do not have a mode of checking off my box here which aligns with what I feel. I do not think this is a good change to make and I personally lament the current state of the Overall I feel that I don't feel strongly enough about this though to pursue a blocking objection, nor am I really that interested in trying to debate the finer points here. The |
This comment has been minimized.
This comment has been minimized.
|
Cheer up Alex! It's not all that bad. While I would agree that there's some obvious bad parts to the |
This comment has been minimized.
This comment has been minimized.
|
@alexcrichton Thanks for writing up your thoughts on this. I hear you on these concerns. What do you think of taking some time at the next Rust All Hands for @rust-lang/libs to discuss the crate organization of the standard library and such high-level design? |
This comment has been minimized.
This comment has been minimized.
|
@alexcrichton that was my feeling for many years, but recently I've been pleased and impressed with the work on the alloc-wg (which, to be clear, I've only been a belated and minor contributor to, not trying to complement myself here!) It looks like this RFC wasn't really done in consultation to that working group? Maybe the libs team could kick this over to them, and whatever their decision they could contextualize it in a more thorough long-term design you are interested in. My personal opinion is that I don't like this RFC either, but if the allocator parameter stuff the working group has prototyped is merged it will matter a lot less as all no_std code can (and should) return alloc errors explicitly with Result giving the caller maximum flexibility to locally handle the error or punt and let the global handler deal with it. In other words, no_std code shouldn't be using this handler at all so I don't care so much how it works. |
This comment has been minimized.
This comment has been minimized.
|
My understanding of https://github.com/rust-lang/wg-allocators is that it is not about everything allocation-related, but specifically about making it possible to use a non-global allocator with standard library containers. So the behavior of
|
This comment has been minimized.
This comment has been minimized.
That sounds right to me, but if you and/or the rest of the libs team wants to change the scope of the working group, they can. If @alexcrichton feels stretched thin, maybe that's something he'd want to pursue.
That is right and I cannot change it. It is my opinion one ought to use |
This comment has been minimized.
This comment has been minimized.
|
Even if you always used |
This comment has been minimized.
This comment has been minimized.
Agreed. IMO the alloc crate issues have nothing to do with wg-allocators, but instead to do with our story around no-std and support for diverse platforms that don't support all of std. It would be bizarre to link this issue to wg-allocators. |
Summary
This issue is for getting consensus on a change initially proposed in the tracking issue for
#[alloc_error_handler]: #51540 (comment)When no
#[alloc_error_handler]is defined (which implies thatstdis not linked, since it literally has such a handler),alloc::alloc::handle_alloc_errorshould default to callingcore::panic!with a message identical to the one thatstdprints to stderr before aborting in that case.Although #51540 (comment) suggested that a full RFC would not be necessary, this is loosely structured after the RFC template.
Background
See the Background section of the sibling issue proposing stabilization of the attribute.
Motivation
As of Rust 1.36, specifying an allocation error handler is the only requirement for using the
alloccrate inno_stdenvironments (i.e. without thestdcrate being also linked in the program) that cannot be fulfilled by users on the Stable release channel.Removing this requirement by having a default behavior would allow:
no_std+liballocapplications to start running on the Stable channelno_stdapplications that run on Stable to start usingliballocGuide-level explanation
When
stdis linked in an application,alloc::alloc::handle_alloc_errordefaults to printing an error message to stderr and aborting the process.When
stdis not linked and no other#[alloc_error_handler]is defined,handle_alloc_errordefaults to panicking as if the following handler were defined:Reference-level explanation
The implementation for this would be very similar to that of
#[global_allocator]. (Links in the next two paragraphs go to that implementation.)alloc::alloc::handle_alloc_erroris modified to call anextern "Rust" { fn … }declaration.The definition of this function does not exist in Rust source code. Instead, it is synthesized by the compiler for “top-level” compilations (executables,
cdylibs, etc.) whenallocis in the crate dependency graph. If an#[alloc_error_handler]is defined, the synthesized function calls it. If not, the synthesized function callsalloc::alloc::default_error_handlerwhich is a new lang item. (Or is it?)In order to allow experimentation for this new default behavior, it should initially be gated behind the
#![feature(default_alloc_error_handler)]feature flag. When no handler is defined, a call to the default is (at first) only synthesized if any of the crates in the dependency graph has that feature gate. If none of them do, the current compilation error continues to be emitted.Alternatives
The status quo is that
no_std+allocrequires Nightly.Stabilizing
#[alloc_error_handler]or some other mechanism for specifying this handler is another way to unlock theno_std+liballocon Stable use case. This removes the initial motivation for coming up with this default behavior. However perhaps this default is still desirable? In ano_stdenvironment where there is no process to abort, the allocation error handler will likely be very similar to the panic handler (which is already mandatory).