Skip to content
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 unit test checking to cargo check #4592

Merged
merged 6 commits into from
Oct 30, 2017
Merged

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented Oct 7, 2017

This is an extension of PR #4039, fixing #3431, #4003, #4059, #4330. The fixes for #4059 can potentially be separated into a separate PR, though there may be some overlap.

The general gist of the changes:

  • Add --profile test flag to cargo check that will enable checking of unit tests.
  • --tests will implicitly enable checking of unit tests within the lib (checks the same targets as cargo test). This affects the check, test, and build commands.
  • --benches behaves similarly by using the same targets as cargo bench.
  • Fix erroneously linking tests when run with --test.

There is one thing I did not do because I wanted more feedback on what others think the expected behavior should be. What should the behavior of --all-targets be? This patch does not (yet) make any changes to its behavior. My initial thinking is that it should add a target of --lib --bins --profile test, but that essentially means the lib and bin targets will be checked twice (and thus any errors/warnings outside of #[cfg(test)] will appear twice, which may be confusing, and generally take twice as long to run). I can add that, but I think it would require adding a new All variant to CompileFilter so that the code in generate_targets can detect this scenario. I wanted feedback before making a more extensive change like that. The downside of not adding it is that --all-targets will ignore unit tests (if you don't specify --profile test).

Summary of the profiles used with this patch:

Command Lib Bin foo Test t1 Example e1 Bench b1
check check check - - -
check --profile test check_test† check_test† - - -
check --lib check - - - -
check --lib --profile test check_test† - - - -
check --bin foo check check - - -
check -–bin foo –profile test check_test† check_test† - - -
check --bins check check - - -
check --test t1 check check check_test - -
check --tests check, check_test† check, check_test† check_test check†, check_test† -
check --all-targets check, check_test† check, check_test† check_test check, check_test† check_test

† = different behavior from today

@rust-highfive
Copy link

r? @matklad

(rust_highfive has picked a reviewer for you, use r? to override)

@ehuss
Copy link
Contributor Author

ehuss commented Oct 8, 2017

Closing till I fix this. Fixed the broken tests.

@ehuss
Copy link
Contributor Author

ehuss commented Oct 8, 2017

I've discovered some problems with this PR, I will be fixing them soon.
EDIT: Ok, I think it's fixed now.

@bors
Copy link
Collaborator

bors commented Oct 14, 2017

☔ The latest upstream changes (presumably #4616) made this pull request unmergeable. Please resolve the merge conflicts.

- Add `--profile test` flag to `cargo check` that will enable checking of unit tests.
- `--tests` will implicitly enable checking of unit tests within the lib.
- Don't implicitly compile binaries when using just `--test` filters.
- Fix erroneously linking tests when run with `--test`.

Fixes rust-lang#3431, rust-lang#4003, rust-lang#4059, rust-lang#4330.
Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome thanks so much and sorry for the delay!

src/bin/check.rs Outdated
filter: ops::CompileFilter::new(options.flag_lib,
&options.flag_bin, options.flag_bins,
filter: ops::CompileFilter::new(options.flag_lib || options.flag_tests,
&options.flag_bin, options.flag_bins || options.flag_tests,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment to why these two || conditions were added?

src/bin/check.rs Outdated
@@ -106,6 +111,17 @@ pub fn execute(options: Options, config: &mut Config) -> CliResult {
&options.flag_exclude,
&options.flag_package)?;

let test = options.flag_tests ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logic may cause subtle oddities, although that's maybe ok for now? but for example:

cargo check --tests --bin foo

I think that'll check the binary foo in "test mode" rather than "do you compile mode", right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. The more I think about it, it is probably wrong. check --tests should not check bins with the test profile. I'll fix it.

@@ -862,7 +862,7 @@ impl<'a, 'cfg> Context<'a, 'cfg> {
ret.extend(self.maybe_lib(unit));

// Integration tests/benchmarks require binaries to be built
if unit.profile.test &&
if unit.profile.test && !unit.profile.check &&
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you expand the above comment to explain this negation?

@ehuss
Copy link
Contributor Author

ehuss commented Oct 21, 2017

OK, I have updated it with a different approach. After thinking about it more, I think people expect check --tests to check all tests, similar to cargo test. So I have reworked it so that --tests uses the same behavior as cargo test. This means it will also affect other commands that use --tests (like build, bench, and test). This also makes test --tests somewhat redundant, but consistent across the commands. I'm not entirely sure if that's for the best, I'm not sure which behavior is more surprising.

I also updated --benches to have similar behavior (mimicking what happens with cargo bench). Finally, --all-targets now really does all targets. I updated the summary above.

Also, I have so far been ignoring doctests. Since I believe that will rely on rustdoc, it might be outside of the domain of cargo check?

@alexcrichton
Copy link
Member

Gah sorry for the delay! In any case that all sounds great to me, thanks so much!

@bors: r+

@bors
Copy link
Collaborator

bors commented Oct 30, 2017

📌 Commit efc0dd1 has been approved by alexcrichton

@alexcrichton alexcrichton added the relnotes Release-note worthy label Oct 30, 2017
bors added a commit that referenced this pull request Oct 30, 2017
Add unit test checking to `cargo check`

This is an extension of PR #4039, fixing #3431, #4003, #4059, #4330.  The fixes for #4059 can potentially be separated into a separate PR, though there may be some overlap.

The general gist of the changes:

- Add `--profile test` flag to `cargo check` that will enable checking of unit tests.
- `--tests` will implicitly enable checking of unit tests within the lib (checks the same targets as `cargo test`).  This affects the `check`, `test`, and `build` commands.
- `--benches` behaves similarly by using the same targets as `cargo bench`.
- Fix erroneously linking tests when run with `--test`.

There is one thing I did not do because I wanted more feedback on what others think the expected behavior should be.  What should the behavior of `--all-targets` be?  This patch does not (yet) make any changes to its behavior.  My initial thinking is that it should *add* a target of `--lib --bins --profile test`, but that essentially means the lib and bin targets will be checked twice (and thus any errors/warnings outside of `#[cfg(test)]` will appear twice, which may be confusing, and generally take twice as long to run).  I can add that, but I think it would require adding a new `All` variant to `CompileFilter` so that the code in `generate_targets` can detect this scenario.  I wanted feedback before making a more extensive change like that.  The downside of not adding it is that `--all-targets` will ignore unit tests (if you don't specify `--profile test`).

Summary of the profiles used with this patch:

Command                         | Lib               | Bin foo     | Test t1 | Example e1 | Bench b1 |
-------                         | ---               | -------     | ------- | ---------- | -------- |
`check`                         | check             | check       | -       | -          | -        |
`check --profile test`          | check_test†       | check_test† | -       | -          | -        |
`check --lib`                   | check             | -           | -       | -          | -        |
`check --lib --profile test`    | check_test†       | -           | -       | -          | -        |
`check --bin foo`               | check             | check       | -       | -          | -        |
`check -–bin foo –profile test` | check_test†       | check_test† | -       | -          | -        |
`check --bins`                  | check             | check       | -       | -          | -        |
`check --test t1`               | check             | check       | check_test   | -          | -        |
`check --tests`                 | check, check_test†  | check, check_test† | check_test | check†, check_test†  | -    |
`check --all-targets`           | check, check_test†  | check, check_test†  | check_test   | check, check_test† | check_test    |

† = different behavior from today
@bors
Copy link
Collaborator

bors commented Oct 30, 2017

⌛ Testing commit efc0dd1 with merge 8be175e...

@bors
Copy link
Collaborator

bors commented Oct 30, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 8be175e to master...

@bors bors merged commit efc0dd1 into rust-lang:master Oct 30, 2017
@ehuss
Copy link
Contributor Author

ehuss commented Oct 30, 2017

Thanks @alexcrichton, I know you are super busy (I'm still not convinced you are just one human). I had some questions:

  • Is there anything I can do to help with the release notes process?
  • I noticed bors only closed one of the issues. Should I add comments to each one explaining how it is fixed?

I assume this will get picked up in nightly the next time Cargo is updated in the main rust repo for people to test. I feel like this is a subtle, but significant change in behavior. Hopefully most people will be happy with the changes.

@alexcrichton
Copy link
Member

Is there anything I can do to help with the release notes process?

Certainly! There's a PR upstream for the 1.22 release (which this won't be included in), but you can start a new section for the 1.23 release which would be awesome!

Should I add comments to each one explaining how it is fixed?

If you're willing, that'd be awesome! If not, feel free to just leave a comment saying it should be closed now.

I assume this will get picked up in nightly the next time Cargo is updated in the main rust repo for people to test.

Indeed! If you'd like to accelerate that, feel free to send a PR yourself to rust-lang/rust :)

@ehuss
Copy link
Contributor Author

ehuss commented Oct 30, 2017

It looks like @Aaronepower has been writing the release notes. I'll just leave this here for when he gets started on 1.23, and let him format/wordsmith as desired.

Cargo
-----
- [`cargo check --profile test` added to check unit tests][cargo/4592]
- [`--tests`, `--benches`, and `--all-targets` flags will now include all
  potential targets for their respective type][cargo/4592]

[cargo/4592]: https://github.com/rust-lang/cargo/pull/4592

@jonhoo
Copy link
Contributor

jonhoo commented Jan 24, 2018

@ehuss how does --all-targets interact with --all? Can you specify both?

@ehuss
Copy link
Contributor Author

ehuss commented Jan 24, 2018

@ehuss how does --all-targets interact with --all? Can you specify both?

@jonhoo It should work (it should build every target of every package). Are you experiencing any issues?

@jonhoo
Copy link
Contributor

jonhoo commented Jan 24, 2018

Sorry, no, this was a case of asking before trying. Seems to work as expected! It just wasn't documented anywhere that these work together, though I guess there isn't a good reason why they shouldn't. I suspect it would have helped if the docs somewhere said that selecting target crates and selecting profiles are orthogonal actions, but meh.

@ehuss
Copy link
Contributor Author

ehuss commented Jan 24, 2018

selecting target crates and selecting profiles are orthogonal actions, but meh.

I've seen that target and profile selection is a common source of confusion. Along with improving documentation, I wonder if it might be helpful to display each target/profile being built when -v is used (trying to understand that from the rustc command-line isn't exactly easy).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Release-note worthy
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants