Skip to content

rustdoc: properly detect input file exists #27074

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

Merged
merged 1 commit into from
Jul 18, 2015
Merged

Conversation

steveklabnik
Copy link
Member

Fixes #27014

r? @alexcrichton

I'm not 100% sure there's not a better way to do this, but it works.

Also, I wasn't sure how, where, or if to write a test for this.

@alexcrichton
Copy link
Member

The compiler's actually already spitting out the right error message here, it's just that none of the subsequent panic messages are being suppressed. To solve this I think it'd be better to handle the panic messages in the same manner as the compiler, only emitting some of them for major errors.

@steveklabnik
Copy link
Member Author

@alexcrichton what about this second commit instead? It now prints out

$ x86_64-unknown-linux-gnu/stage1/bin/rustdoc fake
No such file or directory (os error 2)

Handling bad input proactively just seems like a good idea to me, personally, rather than letting some inner thing panic.

@alexcrichton
Copy link
Member

rustdoc currently has a bad error message for any panic on behalf of the compiler (e.g. any compiler error message), so I think it'd be best to fix both issues instead of just special casing this one

@steveklabnik
Copy link
Member Author

word. i'll try to figure out where that is.

@alexcrichton
Copy link
Member

All of rustc's logic is in the monitor function, so this may be as simple as just calling that when rustdoc spawns a thread.

@steveklabnik
Copy link
Member Author

Nice! using monitor now makes it look like this:

$ x86_64-unknown-linux-gnu/stage1/bin/rustdoc fake
error: couldn't read "fake": No such file or directory (os error 2)
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Any', src/libcore/result.rs:731

That last extra message happens because of https://github.com/rust-lang/rust/blob/master/src/librustdoc/lib.rs#L135

Given that we're setting up a 32MB stack here, I guess I can't turn this spawn into a monitor either, eh? What should I do here?

@alexcrichton
Copy link
Member

I think it's fine to change that unwrap to just a unwrap_or(101)

@steveklabnik
Copy link
Member Author

ahhh yes. I just started make check on the rollup, but i'll do that after. anything else I should take care of, assuming that works? I'll squash and such too

@alexcrichton
Copy link
Member

Nah I think that should do it!

@@ -56,7 +56,7 @@ extern crate serialize as rustc_serialize; // used by deriving
use std::cell::RefCell;
use std::collections::HashMap;
use std::env;
use std::fs::File;
use std::fs::{self, File};
Copy link
Contributor

Choose a reason for hiding this comment

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

doesn't look like this change is needed

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, it's since been removed

When rustc gives an error, there's a ton of extra output from the panic.
Now, we use monitor() to supress the excess output.

Fixes rust-lang#27014
@steveklabnik
Copy link
Member Author

@alexcrichton r?

@alexcrichton
Copy link
Member

@bors: r+ 82d0442

bors added a commit that referenced this pull request Jul 18, 2015
Fixes #27014 

r? @alexcrichton 

I'm not 100% sure there's not a better way to do this, but it works.

Also, I wasn't sure how, where, or if to write a test for this.
@bors
Copy link
Collaborator

bors commented Jul 18, 2015

⌛ Testing commit 82d0442 with merge 81b6b91...

@bors bors merged commit 82d0442 into rust-lang:master Jul 18, 2015
@steveklabnik steveklabnik deleted the gh27014 branch June 19, 2016 20:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants