On Fri, 19 May 2006, Derek M Jones wrote: > > > I may think I have caught all the ambiguities/conflicts that can occur. > > > > You can be sure by declaring the same %merge on every rule that has the same > > LHS symbol. > > Not very elegant and it would clutter up the .y file.
I accept that it's a lot to write. Even so, can you achieve your desired functionality that way? > > Define the interface of this new function and how it should be declared. > > The current definition of yyreportAmbiguity + the necessary changes > to implement the functionality of a merge. Can you be more specific? Would it be declared in the definitions section or alongside specific rules? Can you give an example declaration demonstrating both the yyreportAmbiguity and merge functionality? > > Originally, we were discussing conflict time, and now we're back to merge > > time. What happened? > > I'm being non-conflictional and trying to work out a friendly merge'er :-) > > I will have a think about the conflict question you asked. OK. > I have just spent ages trying to isolate what looks like an > uninitialized variable that causes the line > yynewItem->yyisState = yyfalse; > in yyaddDeferredAction to dereference a null pointer. > It occurs when lots of reductions (124+) are deferred. > Now I cannot get it to happen on the full grammar, let alone the > cut down one :-( > Suggestions welcome. There have been some fixes in this area since 2.1. It might be more fruitful to wait for 2.2 to worry about tracking this down. Joel _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
