Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Conditionally mark the
test
cfg as a well known cfg #15007Conditionally mark the
test
cfg as a well known cfg #15007Changes from all commits
208f817
2593b86
b757af9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
If user has specified
--lib
, doesn't it mean that they requested to test the lib crate socfg(test)
is expected to be there?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.
What the command line arguments are shouldn't matter, otherwise users would get a different behavior between a "normal"
cargo test
and one with arguments like--all-targets
.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.
However,
lib.test = false
doesn't mean there is no test. It, as of today, is defined as "test" won't run by default.cfg(test)
is still relevant regardless if a test is in the default test set.Maybe I should put the question this way: Why is
cfg(test)
in atest=false
crate unexpected?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.
IMO having
test = false
meaning not tested by default compared to not tests at all is unexpected, at least before reading the documentation I would have assumed that it disabled all the testing.@jplatte made a further argument in his comment:
A similar comment was also put in the URLO thread.
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.
Thanks for linking the thread here. Yeah I've read that, and agree that
lib.test = false
largely implies no test in lib crate at all. That is a valid use case and deserves a lint or warning.However, fields under Cargo targets are mostly about including in or excluding from the default crate set, and are largely affected by the command-line argument. If Cargo has started emitting unexpected warning for Cargo targets, it may also bite users that disabling tests for other reasons. For example, I've seen people setting
test=false
because some tests are not expected to run by default for daily development, but only on CI or other special environments.While that kind of scenario I guess is far less than who don't want tests at all, it is still a valid use case aligning with what the current doc describes. Treating
unexpected_cfgs
as an indirect way of banning tests in a crate doesn't seem to be the best venue. It is more like a hack because there is no lint for really banning tests.That being said, I am not surprised if Cargo targets settings don't meet people's expectation. It is always a source of confusions1 😞.
Footnotes
I can actually name a lot of issues here. Let's just have a little peek of them:
* https://github.com/rust-lang/cargo/issues/8338
* https://github.com/rust-lang/cargo/issues/10936
* https://github.com/rust-lang/cargo/issues/10958
* https://github.com/rust-lang/cargo/issues/13668
* https://github.com/rust-lang/cargo/issues/13437
* https://github.com/rust-lang/cargo/issues/13828 ↩
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.
The
unexpected_cfgs
lint do trigger on#[test]
but only when passed with--test
.We can probably make the lint fire without the
--test
argument.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.
Unless I missed something in catching up on this, I feel like we'd get more out of
test = false
being consistent, independent of the build-target type. I'm not too concerned about false positives from people who have#[test]
but settest = false
.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.
My main point is the meaning of
test = false
will change after this PR. I don't mind shipping the particular change. Just want to make sure people aware of and feel good with it. And probably need doc update as well.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.
I have adjusted the documentation with the new behavior.
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.
There are multiple ways which a target may be tested even when it has
test = false
, notably,cargo test --all-targets
andcargo test some_test_name_filter
. Therefore, I believe this change is problematic (and have filed #15131 for tracking of that).