-
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
Stop mentioning internal lang items in no_std binary errors #116343
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.