-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reintroduce alloc_error_handler as deprecated #110733
Conversation
r? @davidtwco (rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
|
The job Click to see the possible cause of the failure (guessed by this bot)
|
Aha, I see. Thanks! I noticed it didn't work with our pinned nightly (we test embedded stuff with a pinned nightly as well as rolling nightlies) but I misread the date and didn't realize our pinned nightly was a year old. Thanks! |
See #109507 (comment): The removal of
#[alloc_error_handler]
introduces a hard edge for people doing embedded development: code must contain the handler before that PR, and code must not contain that handler after that PR.While it is an unstable feature and we can remove it immediately, it would be nicer to our embedded users for us to provide a slightly more graceful migration path for a couple releases.
This is not as graceful as it could be, as even with this change code that wants to have a different alloc error handler from its panic handler is still forced to pick a rust version, but at least the code compiles, and for the majority of cases where panics and allocs are going to be handled the same way it doesn't matter.
Not sure of this implementation; I could make it a future incompat lint instead of just using
#[deprecated]
given that it's a behavior change, not just a deprecation.