-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Stop mentioning internal lang items in no_std binary errors #116343
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Stop mentioning internal lang items in no_std binary errors #116343
Conversation
r? @cjgillot (rustbot has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
a5a795a
to
bbbe28d
Compare
| | ||
= note: this can occur when a binary crate with `#![no_std]` is compiled for a target where `eh_personality` is defined in the standard library | ||
= help: you may be able to compile for a target that doesn't need `eh_personality`, specify a target with `--target` or in `.cargo/config` | ||
= help: specify panic="abort" instead |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this always correct? #[panic_handler]
does work on no-std, so I thought you don't have to specify panic="abort"
. Is the previous help about the target not helpful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unwinding panics require the eh_personality lang item. on targets that don't support unwinding at all, panic=abort is the default so you don't have to care about eh_personality at all. but on targets that do support unwinding (that people still want to write no_std binaries for sometimes) unwinding is still the default even with no_std.
The original suggestion:
Was arrived at because it's very easy to run |
Adding this sounds reasonable. |
rust_eh_personality is currently always necessary if libcore is compiled with panic=unwind, even when using panic=abort for the end product. It should be possible to generate a dummy rust_eh_personality which aborts though if it is not defined but we are linking a panic=abort crate. |
I don't think that's true? Compiling with -Cpanic=abort works. |
Only if you don't reference any functions in libcore that have
|
I see. So users of |
Currently yes. I did call it a bug in rustc though. One option to fix this would be for rustc to synthesize an aborting personality function when linking a crate with the personality function. See also #106864 |
☔ The latest upstream changes (presumably #116366) made this pull request unmergeable. Please resolve the merge conflicts. |
I'm not sure where you discussion converged. |
bbbe28d
to
7bcb83c
Compare
☔ The latest upstream changes (presumably #119146) made this pull request unmergeable. Please resolve the merge conflicts. |
7bcb83c
to
560b2a3
Compare
This comment has been minimized.
This comment has been minimized.
560b2a3
to
822c1e0
Compare
…he-weird-lang-items-just-saying, r=bjorn3 Stop mentioning internal lang items in no_std binary errors When writing a no_std binary, you'll be greeted with nonsensical errors mentioning lang items like eh_personality and start. That's pretty bad because it makes you think that you need to define them somewhere! But oh no, now you're getting the `internal_features` lint telling you that you shouldn't use them! But you need a no_std binary! What now? No problem! Writing a no_std binary is super easy. Just use panic=abort and supply your own platform specific entrypoint symbol (like `main`) and you're good to go. Would be nice if the compiler told you that, right? This makes it so that it does do that. I don't _love_ the new messages yet, but they're decent I think. They can probably be improved, please suggest improvements.
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#116343 (Stop mentioning internal lang items in no_std binary errors) - rust-lang#118903 (Improved support of collapse_debuginfo attribute for macros.) - rust-lang#119033 (coverage: `llvm-cov` expects column numbers to be bytes, not code points) - rust-lang#119598 (Fix a typo in core::ops::Deref's doc) - rust-lang#119660 (remove an unnecessary stderr-per-bitwidth) - rust-lang#119663 (tests: Normalize `\r\n` to `\n` in some run-make tests) - rust-lang#119681 (coverage: Anonymize line numbers in branch views) - rust-lang#119704 (Fix two variable binding issues in lint let_underscore) - rust-lang#119725 (Add helper for when we want to know if an item has a host param) - rust-lang#119738 (Add `riscv32imafc-esp-espidf` tier 3 target for the ESP32-P4.) - rust-lang#119740 (Remove crossbeam-channel) Failed merges: - rust-lang#119723 (Remove `-Zdont-buffer-diagnostics`.) r? `@ghost` `@rustbot` modify labels: rollup
4533a77
to
db930c6
Compare
@bors r=bjorn3 |
This comment has been minimized.
This comment has been minimized.
2024-01-09T20:04:57.2449779Z tidy error: following path contains more than 868 entries, you should move the test to some relevant subdirectory (current: 869): /checkout/tests/ui |
I don't get this error locally 🤷 , |
@Nilstrieb might it be something akin to a merge conflict? (at least part of the CI is run after a test merge is done, so tidy might be running on code you don't have locally?) |
I thought PR CI didn't merge master... but good point I should try that |
PR CI does merge master. Unlike bors runs this may however be outdated by the time the PR is actually merged into master. |
When writing a no_std binary, you'll be greeted with nonsensical errors mentioning lang items like eh_personality and start. That's pretty bad because it makes you think that you need to define them somewhere! But oh no, now you're getting the `internal_features` lint telling you that you shouldn't use them! But you need a no_std binary! What now? No problem! Writing a no_std binary is super easy. Just use panic=abort and supply your own platform specific entrypoint symbol (like `main`) and you're good to go. Would be nice if the compiler told you that, right? This makes it so that it does do that.
db930c6
to
da26317
Compare
@bors r+ |
Rollup of 3 pull requests Successful merges: - rust-lang#116343 (Stop mentioning internal lang items in no_std binary errors) - rust-lang#119814 (bootstrap: exclude link_jobs from `check_ci_llvm!` checks) - rust-lang#119829 (Add debug info for macOS CI actions) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#116343 - Nilstrieb:maybe-dont-mention-all-the-weird-lang-items-just-saying, r=bjorn3 Stop mentioning internal lang items in no_std binary errors When writing a no_std binary, you'll be greeted with nonsensical errors mentioning lang items like eh_personality and start. That's pretty bad because it makes you think that you need to define them somewhere! But oh no, now you're getting the `internal_features` lint telling you that you shouldn't use them! But you need a no_std binary! What now? No problem! Writing a no_std binary is super easy. Just use panic=abort and supply your own platform specific entrypoint symbol (like `main`) and you're good to go. Would be nice if the compiler told you that, right? This makes it so that it does do that. I don't _love_ the new messages yet, but they're decent I think. They can probably be improved, please suggest improvements.
When writing a no_std binary, you'll be greeted with nonsensical errors mentioning lang items like eh_personality and start. That's pretty bad because it makes you think that you need to define them somewhere! But oh no, now you're getting the
internal_features
lint telling you that you shouldn't use them! But you need a no_std binary! What now?No problem! Writing a no_std binary is super easy. Just use panic=abort and supply your own platform specific entrypoint symbol (like
main
) and you're good to go. Would be nice if the compiler told you that, right?This makes it so that it does do that.
I don't love the new messages yet, but they're decent I think. They can probably be improved, please suggest improvements.