-
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
Add needs-unwind to tests that depend on panicking #91373
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon. Please see the contribution instructions for more information. |
You should also be able to remove the existing |
I did that originally but the flag in compiletest needs a command-line argument (i.e. it's not inherently set for specific target configurations). Should we be pulling that setting from a config? |
Ah right, the plan was to add a flag to bootstrap that enables |
9b924d9
to
ce8b18e
Compare
This comment has been minimized.
This comment has been minimized.
a485fc8
to
b3c1e65
Compare
I forget what PR added needs-unwind (maybe my bad there), but if it's currently just not being used at all (which seems to be the case), it seems a little misleading to go through annotating tests with this flag, particularly when it "seems" like some of the ignore- flags would be removable with this flag added. I also noted that the current target specs for fuchsia don't have a panic strategy of abort, so it seems like in general unwinding is supported? I am not strictly opposed to merging this, but I would like a better understanding of the expectation on your end for integrating needs-unwind into actual invocations of compile test from our build system (rough sense of timeline), and maybe some commentary in the PR description for how these tests were found (did you run with a panic=abort flag and just blanket added for where it failed?). My review comment suggests that it's possible some unrelated tests were also adjusted in this PR, which seems best to avoid and is part of the reason I'd like the test selection rationale better documented in the PR. (If I miss your comment, please |
b3c1e65
to
468c05c
Compare
There is a flag and it is functional, but it has to be manually passed (e.g.
Although I believe it is now possible to build fuchsia with unwinding, I believe this was not always the case and the standard library is compiled with
I expect that eventually x.py will automatically determine whether the
Updated.
Ack, you are correct. Those are fixes for other tests that failed on fuchsia, but are unrelated to this PR. They were added by mistake and I've removed them from this PR. |
@rustbot ready |
For context, my plan was to add an explicit flag to x.py for building with panic=abort (ideally with defaults for the platforms that don't support it). This would modify compilation flags (including It's true that adding the |
I'm okay proceeding here -- it sounds like we're on a good path toward this being integrated, and it's already ~usable directly, when needed. @djkoloski it looks like an unrelated commit and a couple merges landed on this branch -- can you rebase those away? After that's done I expect to r+ |
This directive isn't automatically set by compiletest or x.py, but can be turned on manually for targets that require it.
468c05c
to
ea68758
Compare
Sorry about that, accidentally pulled in an unrelated commit. @rustbot ready |
@bors r+ |
📌 Commit ea68758 has been approved by |
…k-Simulacrum Add needs-unwind to tests that depend on panicking These tests were found by running the test suite on fuchsia which compiles with `panic=abort` by default, then picking through the failures manually to locate the tests that require unwinding support. Most of these tests are already opted-out on platforms that compile with `panic=abort` by default. This just generalizes it a bit more so that fuchsia tests can be run properly. Currently, the `needs-unwind` directive needs to be manually passed to compiletest (e.g. via `--test-args '--target-panic=abort'`). Eventually, I would like `x.py` or compiletest to determine whether the directive should be used automatically based on the target panic settings.
…askrgr Rollup of 6 pull requests Successful merges: - rust-lang#91127 (Add `<*{const|mut} T>::{to|from}_bits`) - rust-lang#91310 (Add --out-dir flag for rustdoc) - rust-lang#91373 (Add needs-unwind to tests that depend on panicking) - rust-lang#91426 (Make IdFunctor::try_map_id panic-safe) - rust-lang#91515 (Add rsplit_array variants to slices and arrays) - rust-lang#91553 (socket ancillary data implementation for dragonflybsd.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
These tests were found by running the test suite on fuchsia which compiles with
panic=abort
by default, then picking through the failures manually to locate the tests that require unwinding support.Most of these tests are already opted-out on platforms that compile with
panic=abort
by default. This just generalizes it a bit more so that fuchsia tests can be run properly. Currently, theneeds-unwind
directive needs to be manually passed to compiletest (e.g. via--test-args '--target-panic=abort'
). Eventually, I would likex.py
or compiletest to determine whether the directive should be used automatically based on the target panic settings.