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 up
Stabilize the `#[alloc_error_handler]` attribute (for no_std + liballoc) #66740
This issue formally proposes stabilizing the
Tracking issue: #51540
Normally the tracking issue is where we propose FCP to stabilize, but this one already has many comments that go into a number of sub-topics. Since the feature did not originally go through the RFC process, this proposal is loosely structured after the RFC template.
Heap memory in
Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:
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.
If that default handler is accepted, should we not stabilize this attribute and wait for a more general "global things" mechanism?
@rfcbot fcp what if default
Just throwing this out there (and maybe it's already been proposed and rejected): if we wanted to go with the default handler approach, we could make it possible through the
Probably this would mean there's little point in having
I don't have any opinion about which of these is best. In my opinion we should just make core + alloc work on stable as soon as reasonable.
This is an interesting idea! (Though perhaps one for #66741. The perils of starting two related threads at the same time…)
One thing is that there’s currently no stable way in
We could extend single-argument