Uh oh!
There was an error while loading. Please reload this page.
rustdoc: set panic output before starting compiler thread pool - #52181
Merged
Conversation
rust-highfive
commented
Jul 9, 2018
Contributor
(rust_highfive has picked a reviewer for you, use r? to override) |
ContributorAuthor
r? @rust-lang/rustdoc Also nominating for beta backport because the linked issue in the OP is on beta. EDIT: Also, i'm not sure how this can be properly tested. The |
Member
bors=me with CI done EDIT: And please add a test. You can have one with |
tko
reviewed
Jul 9, 2018
Contributor
There was a problem hiding this comment.
While this new arrangement delays the printing of the collected output to a later, more appropriate stage, doesn't this still leave the panic handler eating more data, if there is any? Should the panic handler also be restored? (Or maybe it's otherwise guaranteed to exit before that can happen? Sorry, not familiar with the code here.)
ContributorAuthor
There was a problem hiding this comment.
My assumption is that because this is what it was doing beforehand, it's not much harm to leave it. Before I had this version, I tried calling set_panic to switch the sink back in this Drop call. It didn't change anything about the output, so I set it back. Each test will set the panic writer to a fresh buffer, so there's no chance of test outputs accumulating.
However, if any panic occurs outside of this function, the output will be swallowed. This may be what we want, but it's something to consider.
QuietMisdreavus
commented
Jul 9, 2018
ContributorAuthor
@GuillaumeGomez I can't test this in |
GuillaumeGomez
commented
Jul 9, 2018
Member
I think you can configure the output in order to be checked as is. We can't let this without a test. If needed, add a new option into the tester. |
QuietMisdreavus
commented
Jul 9, 2018
ContributorAuthor
Turns out, there is a compiletest flag, |
Zoxc
commented
Jul 9, 2018
Contributor
@QuietMisdreavus You should also return the |
rust-highfive
commented
Jul 9, 2018
Contributor
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
QuietMisdreavus
commented
Jul 9, 2018
ContributorAuthor
I'm not really sure what's up with the test error? The UI test is complaining that the
@Zoxc Is that really necessary, though? It looks like it works anyway: $ cat e.rs/// This is a function////// ```/// no/// ```pub fn foo() {}#[cfg(test)]#[test]fn bar() { panic!("the disco"); }
$ rustdoc +local --test e.rsrunning 1 testtest e.rs - foo (line 3) ... FAILEDfailures:---- e.rs - foo (line 3) stdout ----error[E0425]: cannot find value `no` in this scope --> e.rs:4:1 |3 | no | ^^ not found in this scopethread 'e.rs - foo (line 3)' panicked at 'couldn't compile the test', librustdoc/test.rs:325:17note: Run with `RUST_BACKTRACE=1` for a backtrace.failures: e.rs - foo (line 3)test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out |
Zoxc
commented
Jul 9, 2018
Contributor
With |
QuietMisdreavus
commented
Jul 10, 2018
ContributorAuthor
@Zoxc That's unfortunate. I moved those panics outside the thread pool, and added a test which makes sure that doctest compile failures also properly appear. I set parallel queries up on my local fork and made sure it worked. I also had to manually apply one kind of normalization to the test stdout file. This makes it work on travis, but because those files were made automatically, will that cause any problems with people running them locally? The test doesn't pass locally any more. |
ehuss
commented
Jul 10, 2018
Contributor
I hope you don't mind me butting in, but I was really curious about the path issue. The Offhand I'm not sure of a good way to fix that. It's a little late for me, so I can't keep looking right now, but hopefully that gives you some ideas where to look. In particular, contrary to the comments, these two values are normally absolute paths (based on |
QuietMisdreavus
commented
Jul 10, 2018
ContributorAuthor
@ehuss I think the root of the problem is that i'm disabling all UI test output normalization so i can run the test in the first place, but some flag that travis is running (path remapping?) is causing it to output |
ehuss
commented
Jul 10, 2018
Contributor
It's not a different flag, exactly. It's just running from a separate directory (see here). If you |
QuietMisdreavus
commented
Jul 10, 2018
ContributorAuthor
Aha, now i see it! Turns out, there's a bad interaction between how rustdoc prints paths in its output, and how compiletest normalizes paths: rust/src/tools/compiletest/src/runtest.rs Lines 2886 to 2898 in fc49152 Since that only runs the replace on the full path, it doesn't hit the partial path that occurs when you're in a parent folder of the file in question. A quick scan of the repo tells me that one existing test uses the I also went back and double-checked the test i added, and removing Possible solutions i can think of offhand:
|
emilyalbini
commented
Jul 19, 2018
Member
Ping @rust-lang/rustdoc, release date is approaching and this PR fixes a beta regression. |
GuillaumeGomez
commented
Jul 19, 2018
Member
And it seems like it added the missing test I asked for so let's not prevent its merge any further. Thanks @QuietMisdreavus! @bors: r+ |
bors
commented
Jul 19, 2018
Collaborator
📌 Commit 460f05aab147129e297a641b6ca47e71fd18dd29 has been approved by |
emilyalbini
commented
Jul 19, 2018
Member
@bors p=1 (fixes beta regression) Also, can someone approve this for backport? Thanks! |
bors
commented
Jul 19, 2018
Collaborator
⌛ Testing commit 460f05aab147129e297a641b6ca47e71fd18dd29 with merge 913bb6a3b955dd2672d77d040bca23a80761972d... |
bors
commented
Jul 20, 2018
Collaborator
💔 Test failed - status-travis |
rust-highfive
commented
Jul 20, 2018
Contributor
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
rust-highfive
commented
Jul 20, 2018
Contributor
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
QuietMisdreavus
commented
Jul 20, 2018
ContributorAuthor
Does macOS name threads differently? Doctest executions are run in threads that (on linux) are named after the doctest they appear in. It looks like the threads are all named |
emilyalbini
commented
Jul 24, 2018
Member
Ping, 1.28 release is approaching (next week). |
QuietMisdreavus
commented
Jul 24, 2018
ContributorAuthor
I think i see how the thread naming is happening. When specifying a doctest, rustdoc gives libtest a closure that calls Lines 561 to 582 in a1e6bcb
rust/src/librustc_driver/lib.rs Lines 1566 to 1567 in a1e6bcb If it doesn't spawn a new thread, it's because it was able to set the current thread's stack size earlier in the function. This works on Linux because it's able to call ...now i need to figure out how to fix it. |
QuietMisdreavus
commented
Jul 24, 2018
ContributorAuthor
Okay, i was able to get that last commit to work locally (forcing the thread to spawn on linux by setting the |
GuillaumeGomez
commented
Jul 24, 2018
Member
And here we go again! @bors: r+ |
bors
commented
Jul 24, 2018
Collaborator
📌 Commit 76e33b4 has been approved by |
bors
commented
Jul 24, 2018
Collaborator
bors added a commit
that referenced
this pull request
Jul 24, 2018
rustdoc: set panic output before starting compiler thread pool When the compiler was updated to run on a thread pool, rustdoc's processing of compiler/doctest stderr/stdout was moved into each compiler thread. However, this caused output of the test to be lost if the test failed at *runtime* instead of compile time. This change sets up the `set_panic` call and output bomb before starting the compiler thread pool, so that the `Drop` call that writes back to the test's stdout happens after the test runs, not just after it compiles. Fixes#51162
bors
commented
Jul 24, 2018
Collaborator
☀️ Test successful - status-appveyor, status-travis |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
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.
When the compiler was updated to run on a thread pool, rustdoc's processing of compiler/doctest stderr/stdout was moved into each compiler thread. However, this caused output of the test to be lost if the test failed at runtime instead of compile time. This change sets up the
set_paniccall and output bomb before starting the compiler thread pool, so that theDropcall that writes back to the test's stdout happens after the test runs, not just after it compiles.Fixes#51162