macro parser should back out of failed nonterminal parsing

[paulstansifer]

Currently, the following macro argument grammar will not successfully parse anything, complaining of a "local ambiguity":

 $( $t:ty )* #

The problem is that if it were to use the Rust parser to try to parse a type and fail, the whole task would be killed. This is easy to fix after that problem is resolved. There are two options:

1. Break parsing into a separate task, and see whether it survives. However, parse.rs requires a parse_sess, which is mutable state, and can't be shared. So the second option is probably more doable:
2. Allow the parser to safely return instead of killing the task. This works much like the Error monad. Ordinarily, this would require a lot of tedious wrapping and unwrapping, but we have a macro system! It should be relatively easy to make a notation like Haskell's do, and the parser would be able to stay in the standard imperative style.

[eholk]

+1

[nikomatsakis]

Is there an option (3)---require that the grammar be LALR(k) or something like that? Or does that fundamentally not work?

[nikomatsakis]

That said: we should do (2) anyway, because it's lame that we cannot recover what-so-ever from parse failures.

[paulstansifer]

The macro parser doesn't do any lookahead at all, and LR(0) is probably too
restrictive. So it's probably not a good idea to build in such a
restriction.

[graydon]

non-critical for 0.6, de-milestoning

[graydon]

nominating for backwards-compatible milestone. though if we agree to do (2) here maybe we can push this to production ready.

[catamorphism]

Adding nominated label, since I assume @graydon intended to nominate it to change the milestone.

[graydon]

accepted for production-ready milestone

[vadimcn]

Option (4): Break parsing into a separate task and pass parse_sess to it unsafely.

[pnkfelix]

`accepted for P-low.