Skip to content

prompt the use of --nocapture flag if cargo test process is terminated via a signal.#12463

Merged
bors merged 2 commits intorust-lang:masterfrom
stupendoussuperpowers:nocapture_test_msg
Aug 10, 2023
Merged

prompt the use of --nocapture flag if cargo test process is terminated via a signal.#12463
bors merged 2 commits intorust-lang:masterfrom
stupendoussuperpowers:nocapture_test_msg

Conversation

@stupendoussuperpowers
Copy link
Contributor

Fixes #10855

As per the discussion on this issue, we want to prompt the user to use --nocapture if a test is terminated abnormally. The motivation for this change is described in the issue.

We check for 3 things before we display this flag. -

  • !is_simple (if the test ended with a non 101 status code)
  • harness (if the standard test harness was used), and
  • !nocapture (whether or not the --nocapture flag was already passed to the test)

There's further tests added to test::nonzero_exit_status that check that the stderr is correct for the various combinations possible when a test ends with a non-101 status code.

The new expected behavior is -

  • Display --nocapture note for only non-zero exit statuses, when the --nocapture flag is not passed.
  • Only display the note if we use a standard test harness since custom test harnesses do not implement the --nocapture flag.

To implement the check for the --nocapture flag, the function definition for report_test_errors was changed to add the test_args: &[&str] parameter. This parameter is passed from the immediate calling function. This private function is only called twice change and is not causing regression after making the appropriate changes to both the places it's called in.

@rustbot
Copy link
Collaborator

rustbot commented Aug 7, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added Command-test S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 7, 2023
@stupendoussuperpowers
Copy link
Contributor Author

I've split the changes into 2 commits as you asked, and changed the display string.

The tests are failing right now because it is outputting the --nocapture note even if there's an exec failure. Looking into a fix for this.

@ehuss
Copy link
Contributor

ehuss commented Aug 7, 2023

r? epage

Hope you don't mind taking this.

@rustbot rustbot assigned epage and unassigned ehuss Aug 7, 2023
@stupendoussuperpowers stupendoussuperpowers force-pushed the nocapture_test_msg branch 2 times, most recently from aa7e623 to 24fb803 Compare August 8, 2023 10:22
@stupendoussuperpowers
Copy link
Contributor Author

Hi @epage need some help with this.

cargo test -p cargo for linux x86_64 beta is passing, but the test fails for linux x86_64 nightly. Looks like the --no-fail-fast --nocapture are outputting different things for these two. Not sure how to deal with this.

@stupendoussuperpowers stupendoussuperpowers force-pushed the nocapture_test_msg branch 2 times, most recently from 0fb2a72 to 4fffb8b Compare August 8, 2023 14:15
@epage
Copy link
Contributor

epage commented Aug 8, 2023

Hi @epage need some help with this.

cargo test -p cargo for linux x86_64 beta is passing, but the test fails for linux x86_64 nightly. Looks like the --no-fail-fast --nocapture are outputting different things for these two. Not sure how to deal with this.

[..] are a type of wildcard. You can adjust these wildcards to make it still show the relevant information (t1.rs) while hiding the information that is tied to a specific rust version

@epage
Copy link
Contributor

epage commented Aug 9, 2023

@stupendoussuperpowers could you rebase, instead of merge, so I can more easily browse the individual commits?

@rustbot rustbot added A-build-execution Area: anything dealing with executing the compiler A-build-scripts Area: build.rs scripts A-cache-messages Area: caching of compiler messages A-cfg-expr Area: Platform cfg expressions A-cli Area: Command-line interface, option parsing, etc. A-configuration Area: cargo config files and env vars A-crate-dependencies Area: [dependencies] of any kind labels Aug 9, 2023
@stupendoussuperpowers
Copy link
Contributor Author

give me a day or so to work on this, really embarrassing but i'm running into multiple git issues on my local machine. will mark it ready once it's done.

@epage
Copy link
Contributor

epage commented Aug 10, 2023

btw I'm hosting office hours right now but also available at other times in case you want to do a call. See https://github.com/rust-lang/cargo/wiki/Office-Hours

@epage
Copy link
Contributor

epage commented Aug 10, 2023

Hmm, forgot to look back at this. @stupendoussuperpowers anything left or is this good to go?

EDIT: Wow, missed your marking it as ready

@epage
Copy link
Contributor

epage commented Aug 10, 2023

@bors r+

Thanks for all the work you did on this!

@bors
Copy link
Contributor

bors commented Aug 10, 2023

📌 Commit dd8cd9c has been approved by epage

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Aug 10, 2023

⌛ Testing commit dd8cd9c with merge 4312a90...

@bors
Copy link
Contributor

bors commented Aug 10, 2023

💔 Test failed - checks-actions

@weihanglo
Copy link
Member

 thread 'git_auth::ssh_something_happens' panicked at '
test failed running `/home/runner/work/cargo/cargo/target/debug/cargo check -v`
error: expected to find:
[..]Connection [..] by [..]

did not find in output:
    Updating git repository `ssh://127.0.0.1:37377/foo/bar`
warning: spurious network error (3 tries remaining): failed to fill whole buffer
error: failed to get `bar` as a dependency of package `foo v0.0.1 (/home/runner/work/cargo/cargo/target/tmp/cit/t99/foo)`

Caused by:
  failed to load source for dependency `bar`

Caused by:
  Unable to update ssh://127.0.0.1:37377/foo/bar

Caused by:
  failed to clone into: /home/runner/work/cargo/cargo/target/tmp/cit/t99/home/.cargo/git/db/bar-d4c725e0d0110fc9

Caused by:
  network failure seems to have happened
  if a proxy or similar is necessary `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  An IO error occurred when talking to the server

Caused by:
  ssh: connect to host 127.0.0.1 port 37377: Connection refused
', tests/testsuite/git_auth.rs:301:10

Not sure what's going on. Could be the TCP connection accidentally closed.

Let's @bors retry and see.

@bors
Copy link
Contributor

bors commented Aug 10, 2023

⌛ Testing commit dd8cd9c with merge 7da1030...

@bors
Copy link
Contributor

bors commented Aug 10, 2023

☀️ Test successful - checks-actions
Approved by: epage
Pushing 7da1030 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-diagnostics Area: Error and warning messages generated by Cargo itself. Command-test S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Suggest --nocapture flag when a test fails with abort

6 participants