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

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

Merged
merged 2 commits into from Apr 7, 2015

Conversation

Projects
None yet
5 participants
@phildawes
Contributor

phildawes commented Mar 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Mar 30, 2015

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.

Collaborator

rust-highfive commented Mar 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Mar 30, 2015

Member

squeeeeeee

Member

Manishearth commented Mar 30, 2015

squeeeeeee

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Mar 30, 2015

Contributor

Wow, nifty!

Contributor

nikomatsakis commented Mar 30, 2015

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 {

This comment has been minimized.

@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.

@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.

This comment has been minimized.

@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?

@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

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 2, 2015

Contributor

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

Contributor

bors commented Apr 2, 2015

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

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Apr 4, 2015

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.

Contributor

nikomatsakis commented Apr 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@phildawes

phildawes Apr 5, 2015

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!)

Contributor

phildawes commented Apr 5, 2015

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

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
@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Apr 6, 2015

Contributor

@phildawes indeed, it does.

Contributor

nikomatsakis commented Apr 6, 2015

@phildawes indeed, it does.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis
Contributor

nikomatsakis commented Apr 6, 2015

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 6, 2015

Contributor

⌛️ Testing commit e3427c3 with merge b49a5ef...

Contributor

bors commented Apr 6, 2015

⌛️ Testing commit e3427c3 with merge b49a5ef...

bors added a commit that referenced this pull request Apr 6, 2015

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

@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

@jonas-schievink jonas-schievink referenced this pull request Apr 8, 2015

Closed

Build is broken #75

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment