Work towards a non-panicing parser (libsyntax) #23857

Merged
merged 2 commits into from Apr 7, 2015

Projects

None yet

5 participants

@phildawes
Contributor

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

@rust-highfive
Collaborator

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.

@Manishearth
Member

squeeeeeee

@nikomatsakis
Contributor

Wow, nifty!

@nikomatsakis nikomatsakis commented on the diff Mar 30, 2015
src/libsyntax/diagnostic.rs
@@ -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 {
@nikomatsakis
nikomatsakis Mar 30, 2015 Contributor

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.

@phildawes
phildawes Mar 31, 2015 Contributor

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?

@bors
Contributor
bors commented Apr 2, 2015

☔️ The latest upstream changes (presumably #23963) made this pull request unmergeable. Please resolve the merge conflicts.

@phildawes phildawes referenced this pull request in phildawes/racer Apr 3, 2015
Closed

Use the new Thread API to sandbox libsyntax use #164

@nikomatsakis
Contributor

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.

@phildawes
Contributor

Thanks for the feedback. I rebased my branch and added a commit with the comments https://github.com/phildawes/rust/tree/libsyntax_nopanic
I haven't updated a branch referenced by a PR before - will this PR auto-update? (update: yes!)

phildawes added some commits Mar 28, 2015
@phildawes phildawes Work towards a non-panicing parser (libsyntax)
- 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
b2bcb72
@phildawes phildawes Add comments suggested by Niko
e3427c3
@nikomatsakis
Contributor

@phildawes indeed, it does.

@nikomatsakis
Contributor
@bors
Contributor
bors commented Apr 6, 2015

⌛️ Testing commit e3427c3 with merge b49a5ef...

@bors bors added a commit that referenced this pull request Apr 6, 2015
@bors bors Auto merge of #23857 - phildawes:libsyntax_nopanic, r=nikomatsakis
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
b49a5ef
@bors bors merged commit e3427c3 into rust-lang:master Apr 7, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment