Re: [Boost-users] Wave: how to recover after errors?

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2005-12-06 10:23:41

Max Motovilov wrote:
 
> > That's a very good point. I've added it to the exception classes.
> 
> But that's not in the CVS yet, right? 'Cause I didn't see it there :)

It should be there. Perhaps you were hit by the delay of the anonymous
access to the CVS?

> > these. Just use the following code snippet instead of the simple 
> > "while (first != last) { ++first; }" loop. The following snippet is 
> > taken from
> the
> > wave driver, where I've implemented the new techniques:
> 
> Not sure what's the point of storing the current_position in 
> this snippet as I don't see you using it anywhere at the time 
> of error recovery. In any case, I didn't see any suggestion 
> of being able to position the scanner directly using 
> position_type (and I doublt that's feasible considering that 
> every logical position in the file has semantic state of the 
> preprocessor associated with it). I was thinking of achieving 
> recovery with a copy of the _iterator_ but it doesn't look 
> like this does what I expected it to.

The current position is used by the error reporting in the wave driver in
case of unexpected exceptions et.al. (see cpp.cpp of the wave applet). It
does not relate to the error recovery as discussed. I should have removed it
from the code in my last mail.

> I have half-expected it to go into an infinite loop (as 
> returning back to the failure point should cause the same 
> error to repeat itself) then I realized that tokens that 
> would NOT normally be returned to the user (bosy of the 
> re-defined macro, in my case) may not be part of the state 
> associated with the iterator. 

That was my first expectation as well. But as I pointed out in my last mail,
there are two different kinds of errors, error reproted from preprocessing
stages not going to produce any tokens and errors from processing stage
supposed to produce tokens. These are very different in terms of error
recovery.

> Yet something fishy happens 
> with the state I can't quite put my finger on. Here's my 
> example input:
> 
> =============
> #define Foo(x) bar##x
> Foo(foo1)
> #define Foo(x) x##bar
> #define Bar(x) x##foo
> Foo(foo2)
> Bar(bar1)
> 
> =============

[snip]

Yes, I'll have to look into this. My current implementation was a first shot
and Ive expected to get problems. Wave is not written for error recovery,
I'll have to invest some time to insert reliable synchronisation points.

> So the newline was indeed consumed irrecoverably [no pun 
> intended!] and recovery failed.

It's a problem of internal lookahead. The newline is not the problem but the
#define. It already was consumed by the preprocessor.

> But, that's NOT the most interesting part. The most 
> interesting part is that when I commented out all use of 
> last_known_good from the above snippet, the code behaved 
> EXACTLY THE SAME in both cases. Which makes me doubt very 
> much that state has indeed been preserved within the copy of 
> the iterator.

Yes, I expected that.

> Perhaps Wave iterator has shallow copy? I'd deduce that from 
> the code but it's been a long day... maybe tomorrow.

Yes, the Wave iterators shallow copied. To do a deep copy would be too
expensive.

But I'll try to look into your issue asap.

Regards Hartmut