-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-libtestArea: `#[test]` / the `test` libraryArea: `#[test]` / the `test` libraryA-stabilityArea: `#[stable]`, `#[unstable]` etc.Area: `#[stable]`, `#[unstable]` etc.C-bugCategory: This is a bug.Category: This is a bug.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Description
The libtest --include-ignored
flag is intended to be unstable, but it does not present a clear way to use it.
> cargo +nightly test -- --include-ignored
error: The "include-ignored" flag is only accepted on the nightly compiler
error: test failed, to rerun pass '--lib'
Hmm, I'm running on nightly. Only through some sleuthing can one find out that you have to pass -Zunstable-options
to make it work:
cargo +nightly test -- --include-ignored -Zunstable-options
There are several issues here (some of which were noted in the original PR):
- The text "is only accepted on the nightly compiler" should probably say something about
-Zunstable-options
. - The text "is only accepted on the nightly compiler" is wrong, it works on stable, too. And this isn't a compiler.
- There is no tracking issue for this feature, so there is nowhere to discuss it. Should one be created?
- The
--help
text gives no indication that this flag is unstable. - Is there any reason not to just stabilize it now?
mockersf, yonilerner, gauteh, workingjubilee, kappa and 3 more
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-libtestArea: `#[test]` / the `test` libraryArea: `#[test]` / the `test` libraryA-stabilityArea: `#[stable]`, `#[unstable]` etc.Area: `#[stable]`, `#[unstable]` etc.C-bugCategory: This is a bug.Category: This is a bug.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.