-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
cargo test
doesn't capture print from threads
#42474
Comments
|
In my tests, I use |
I would be interested in seeing a fix for this in a PR. |
It'd be nice if there were some way to ask the current test "what print sink are you using?" so that it can pass them down to any spawned threads. That would at least work for "manual" threads. It wouldn't work for things like Rayon (AFAIK). |
The following issues appear to be duplicates (or at least, related): |
Lays the groundwork for mitigating: - rust-lang#12309 - rust-lang#31983 - rust-lang#40298 - rust-lang#42474
…cessfully The contents of this commit have a good account of the things that were tried. The short version is that there isn't much we can do until rust-lang/rust#42474 is fixed (and ← seems to be blocked on custom test frameworks).
Capture output from threads spawned in tests Fixes rust-lang#42474. r? @dtolnay since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.
Capture output from threads spawned in tests Fixes rust-lang#42474. r? @dtolnay since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.
…, r=m-ou-se Capture output from threads spawned in tests This is revival of rust-lang#75172. Original text: > Fixes rust-lang#42474. > > r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore. --- Closes rust-lang#75172.
…, r=m-ou-se Capture output from threads spawned in tests This is revival of rust-lang#75172. Original text: > Fixes rust-lang#42474. > > r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore. --- Closes rust-lang#75172.
…, r=m-ou-se Capture output from threads spawned in tests This is revival of rust-lang#75172. Original text: > Fixes rust-lang#42474. > > r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore. --- Closes rust-lang#75172.
…, r=m-ou-se Capture output from threads spawned in tests This is revival of rust-lang#75172. Original text: > Fixes rust-lang#42474. > > r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore. --- Closes rust-lang#75172.
…r=m-ou-se Capture output from threads spawned in tests This is revival of rust-lang#75172. Original text: > Fixes rust-lang#42474. > > r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore. --- Closes rust-lang#75172.
Although this issue is closed, some issues that were closed before as duplicates as this are still not solved: |
+1. Looks like the solution (d0d0e78, 11ce918) was for print_to (and consequently _print & macros) to redirect to OUTPUT_CAPTURE if set. IIUC, this leaves any direct usage of stdout() uncaptured. The title doesn't cover this specific issue, but this essentially became a meta-bug by closing all the other output capture issues as dupes. Seems like either this bug or something like #12309 should be reopened. |
12309 is closed and points to this issue and this issue is claimed as a duplicate. Is this ever going to get fixed? |
I've filed this bug in rust-lang/cargo but I'm afraid rust-lang/rust is the correct repo for this.
I ran the tests for one of my crates that uses threads in its example code. I've noticed it printed some lines to stdout, even though
--nocapture
wasn't set, but not all of them. It appears that text printed from new threads are not correctly captured, I think this is not intended.Reproduce
Output
Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: