-
Notifications
You must be signed in to change notification settings - Fork 892
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
Catch possible tokenizer panics #3240
Conversation
…r=petrochenkov Add non-panicking `maybe_new_parser_from_file` variant Add (seemingly?) missing `maybe_new_parser_from_file` constructor variant. Disclaimer: I'm not certain this is the correct approach - just found out we don't have this when working on a Rustfmt PR to catch/prevent more Rust parser panics: rust-lang/rustfmt#3240 and tried to make it work somehow.
6d441ce
to
c7ee2a2
Compare
let krate = match parse_crate(input, &parse_session, config, &mut report) { | ||
Ok(krate) => krate, | ||
// Surface parse error via Session (errors are merged there from report) | ||
Err(ErrorKind::ParseError) => return Ok(report), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed this to return report here for parse errors, otherwise we eagerly ?
-return an Err
here:
Line 76 in 66c98db
let krate = parse_crate(input, &parse_session, config, &mut report)?; |
but we only add errors to
Session
if we have Ok(FormatReport)
Lines 49 to 57 in 66c98db
format_result.map(|report| { | |
{ | |
let new_errors = &report.internal.borrow().1; | |
self.errors.add(new_errors); | |
} | |
report | |
}) | |
}) |
I changed this because I expected session.has_parsing_errors()
call to work:
https://github.com/rust-lang/rustfmt/pull/3240/files#diff-382d140f826c9bd99f62116b9712fad3R299
and it seemed like a special case that it didn't.
However, for IO errors we still will get Err(_)
from Session::format(...)
and session.has_operational_errors()
will return false
(should we also change that?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, for IO errors we still will get Err(_) from Session::format(...) and session.has_operational_errors() will return false (should we also change that?).
I think so, but that can be done in a separate PR. I would rather fix this via refactoring the whole error handling around Session
, as currently it is error prone.
This should be ready to review now |
…r=petrochenkov Add non-panicking `maybe_new_parser_from_file` variant Add (seemingly?) missing `maybe_new_parser_from_file` constructor variant. Disclaimer: I'm not certain this is the correct approach - just found out we don't have this when working on a Rustfmt PR to catch/prevent more Rust parser panics: rust-lang/rustfmt#3240 and tried to make it work somehow.
…r=petrochenkov Add non-panicking `maybe_new_parser_from_file` variant Add (seemingly?) missing `maybe_new_parser_from_file` constructor variant. Disclaimer: I'm not certain this is the correct approach - just found out we don't have this when working on a Rustfmt PR to catch/prevent more Rust parser panics: rust-lang/rustfmt#3240 and tried to make it work somehow.
…r=petrochenkov Add non-panicking `maybe_new_parser_from_file` variant Add (seemingly?) missing `maybe_new_parser_from_file` constructor variant. Disclaimer: I'm not certain this is the correct approach - just found out we don't have this when working on a Rustfmt PR to catch/prevent more Rust parser panics: rust-lang/rustfmt#3240 and tried to make it work somehow.
Thank you! |
Hello, I'm running "$ cargo test stdin_parser_panic_caught" in nightly Rust, Windows 10. thanks,
|
When using
new_parser_from_source_str
sometimes it can panic on incomplete input (e.g. bare}
), so here we use theResult
-returningmaybe_new_parser_from_source_str
variant to catch possible errors and diagnostics to emit later.Closes #3239
related #753
cc @topecongiro