[EXPERIMENT] Move handle_alloc_error to core#158198
Conversation
|
The job Click to see the possible cause of the failure (guessed by this bot) |
| /// [`take_alloc_error_hook`]: ../../std/alloc/fn.take_alloc_error_hook.html | ||
| /// [The panic handler]: https://doc.rust-lang.org/reference/runtime.html#the-panic_handler-attribute | ||
| /// [no_std]: https://doc.rust-lang.org/reference/names/preludes.html#the-no_std-attribute | ||
| #[stable(feature = "alloc_module", since = "1.28.0")] |
There was a problem hiding this comment.
shouldn't this be feature = "global_alloc" to match the original code?
|
Hang on won't this break rust-for-linux and others that only use libcore and don't let rustc do the linking to generate the default implementation of alloc_error_handler? This might have to wait until EII can be used for alloc_error_handler. |
|
Yeah, to be clear, this would not be mergeable as-is and you're right that this would probably break things. I mostly wanted to see how many things would break. You're right EII is probably the right solution. |
|
☔ The latest upstream changes (presumably #155625) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
Not meant to be merged as-is. This exists as a test that would be needed to make
hashbrownno longer depend onalloc.Currently, this method does not actually need to be in
alloc, minus thecfg(not(no_global_oom_handling)), which could potentially be removed. It ultimately gets replaced with something reasonable in environments withstd, but just aborts inno_stdenvironments.The unfortunate bit is that we can't change the stability of re-exported functions, and so, this makes the version in alloc a wrapper function.