Skip to content
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

Improve error handling in libsyntax #29285

Merged
merged 7 commits into from
Nov 3, 2015
Merged

Conversation

eefriedman
Copy link
Contributor

A set of commits which pushes some panics out of core parser methods, and into users of those parser methods.

@rust-highfive
Copy link
Collaborator

r? @nrc

(rust_highfive has picked a reviewer for you, use r? to override)

@eefriedman eefriedman force-pushed the libsyntax-panic branch 2 times, most recently from e8fe2ac to 113ee6f Compare October 24, 2015 23:14
handler.fatal(&format!("{}: {}",
&msg[..],
&err[..]));
panic!(handler.fatal(&format!("{}: {}", &msg[..], &err[..])));
Copy link
Member

Choose a reason for hiding this comment

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

Do we need to panic in these places? We're already declaring a fatal exception, what happens if we just carry on? Don't we exit any way?

Copy link
Member

Choose a reason for hiding this comment

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

Oh, you're changing fatal errors to not panic. That seems maybe not a good idea? Could you use non-fatal errors in libsyntax instead? Or maybe it is a good idea since it makes the panicking more explicit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, on master, we're in the slightly odd situation where fatal() panics, but span_fatal() doesn't panic; it probably doesn't make sense for it to stay that way.

In terms of how this should work long-term... libsyntax has basically settled on a "don't panic on fatal errors" approach, so it doesn't really make sense for libsyntax to provide a panicking fatal() method. On the other hand, libsyntax also provides the canonical implementation of fatal errors... so maybe fatal errors should panic, but libsyntax just shouldn't use the fatal() functions.

Copy link
Member

Choose a reason for hiding this comment

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

OK, this sounds reasonable, thanks for the explanantion

@nrc
Copy link
Member

nrc commented Oct 26, 2015

r+, but has some test fails which need fixing.

@eefriedman
Copy link
Contributor Author

@nrc Updated; 77f186a fixes the test failure.

@nrc
Copy link
Member

nrc commented Oct 28, 2015

@eefriedman still some tests failing

Rename parse_* to parse_*_panic, and add parse_attribute_panic.
@eefriedman
Copy link
Contributor Author

Tests fixed in e7d3ae6.

@eefriedman
Copy link
Contributor Author

@nrc Ping.

@nrc
Copy link
Member

nrc commented Nov 3, 2015

@bors: r+

(sorry @eefriedman I've been travelling)

@bors
Copy link
Contributor

bors commented Nov 3, 2015

📌 Commit e7d3ae6 has been approved by nrc

bors added a commit that referenced this pull request Nov 3, 2015
A set of commits which pushes some panics out of core parser methods, and into users of those parser methods.
@bors
Copy link
Contributor

bors commented Nov 3, 2015

⌛ Testing commit e7d3ae6 with merge b7fbfb6...

@bors bors merged commit e7d3ae6 into rust-lang:master Nov 3, 2015
dgrunwald added a commit to dgrunwald/interpolate_idents that referenced this pull request Nov 7, 2015
rust-lang/rust#29582 renamed `TtToken` to `Token`.
rust-lang/rust#29285 renamed `parse_expr` to `parse_expr_panic`.
kevinmehall added a commit to kevinmehall/rust-peg that referenced this pull request Nov 7, 2015
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