Work towards a non-panicing parser (libsyntax) #23857
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see CONTRIBUTING.md for more information. |
|
squeeeeeee |
|
Wow, nifty! |
| @@ -88,13 +89,13 @@ pub struct SpanHandler { | |||
| } | |||
|
|
|||
| impl SpanHandler { | |||
| pub fn span_fatal(&self, sp: Span, msg: &str) -> ! { | |||
| pub fn span_fatal(&self, sp: Span, msg: &str) -> FatalError { | |||
There was a problem hiding this comment.
Hmm, it's not so clear to me why these methods continue to exist. The distinction about span_fatal was traditionally that they panicked. Perhaps as I read more it'll become clearer.
There was a problem hiding this comment.
Hi Niko! I wasn't very familiar with the inners of libsyntax, so I tried to leave everything as it was and just substitute PResult<> for panics. 'span_fatal' is still intended to be 'fatal' in the parsing sense.
I initally had span_fatal() returning PResult<()>, but I thought callers returning Err(s.fatal()) was clearer than try!(s.fatal()). Is there a better way?
|
☔ The latest upstream changes (presumably #23963) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Sorry -- in the push to beta this fell off the radar. I just re-read the patch. I think I might prefer to find another name besides fatal, but I see where you're going with those and I think it makes sense. r+ if rebased and the comments are added. |
|
Thanks for the feedback. I rebased my branch and added a commit with the comments https://github.com/phildawes/rust/tree/libsyntax_nopanic |
- Functions in parser.rs return PResult<> rather than panicing - Other functions in libsyntax call panic! explicitly for now if they rely on panicing behaviour. - 'panictry!' macro added as scaffolding while converting panicing functions. (This does the same as 'unwrap()' but is easier to grep for and turn into try!()) - Leaves panicing wrappers for the following functions so that the quote_* macros behave the same: - parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt
phildawes
force-pushed
the
libsyntax_nopanic
branch
from
b2fe740
to
e3427c3
Compare
|
@phildawes indeed, it does. |
Hello! I've been working towards a libsyntax without panics. See: http://internals.rust-lang.org/t/changing-libsyntax-to-use-result-instead-of-panic/1670 This patch changes the internals of parser.rs to use Result<> rather than panicing. It keeps the following old-style panicing functions as a facade: parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt I left these functions because I wasn't sure what to do about the quote_* macros or how many syntax-extensions would break if these and quoting macros returned Result. The gyst of the rest of the patch is: - Functions in parse/parser.rs return PResult<> rather than panicing - Other functions in libsyntax call panic! explicitly if they rely on panicing behaviour. - I added a macro 'panictry!()' to act as scaffolding for callers while converting panicing functions. (This does the same as 'unwrap()' but is easier to grep for and turn into try!()). Am I on the right track? I'd quite like to get something merged soon as keeping this rebased in the face of libsyntax changes is a lot of work. Please let me know what changes you'd like to see to make this happen. Thanks!, Phil
Hello!
I've been working towards a libsyntax without panics. See:
http://internals.rust-lang.org/t/changing-libsyntax-to-use-result-instead-of-panic/1670
This patch changes the internals of parser.rs to use Result<> rather than panicing. It keeps the following old-style panicing functions as a facade:
parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt
I left these functions because I wasn't sure what to do about the quote_* macros or how many syntax-extensions would break if these and quoting macros returned Result.
The gyst of the rest of the patch is:
Am I on the right track? I'd quite like to get something merged soon as keeping this rebased in the face of libsyntax changes is a lot of work. Please let me know what changes you'd like to see to make this happen.
Thanks!, Phil