Re: [PATCH] use "unresolved reference" message

[Joel E. Denny]

Hi Alex.

On Mon, 7 Sep 2009, Alex Rozenman wrote:

> > Maybe the trouble is that you really just want to tell the user what
> > symbol name Bison extracted from the reference so that he knows what Bison
> > was looking for and didn't find.  Maybe that doesn't seem as necessary to
> > you when Bison has suggestions.  But I think the user may then be misled
> > by the inconsistency.  So, to satisfy us both, I'd be fine with:
> >
> >  test.y:24.36-41: invalid reference: $cond1
> >  test.y:24.36-41:   symbol not found in production: cond1
> >
> 
> Looks very clear.  So what about the following:

Great!  We're converging.

> test.y:24.36-41: invalid reference: $cond1.field
> test.y:24.36-41:   symbol not found in production: cond1
> 
> Should I cut the ".field" from the first line ? Seems I shouldn't. It just
> passes all the possible information to user.

I agree.  (I copied from an example that I thought didn't have a field, 
but maybe I made a mistake.)

> >  test.y:26.43-53: invalid reference: $stmt.field
> >  test.y:24.36-41:   symbol not found in production: stmt
> >  test.y:25.35-38:   possibly meant: $then.field, hiding $stmt.field at $4
> >
> It looks redundant.

I agree that it will look redundant for some invalid references, but it's 
correct for all invalid references, so I think it should always be there 
for consistency.

> However, in this specific case it really adds a piece of
> useful information to the output. It actually shows what symbol bison was
> looking for and would compile without complains.

Agreed.

> Another possible situation
> is when a symbol is invisible from mid-rule actions. In this case, it can be
> suggested to extend the message to something like this:
> 
> test.y:26.43-53: invalid reference: $stmt.field
> test.y:24.36-41:   symbol not found in sub-production before $3: stmt

Good point.

> Could you suggest more appropriate error message ?

I'd just drop "sub-".

> I'll try to implement it and check more situations.
> 
> In addition, I am going to add an item to the NEWS file. I wrote the
> following text, please help me to improve it:
> 
> ** Symbolic References Support

Why not "named references"?

>   Historically, Yacc and Bison have supported positional references ($n, $$)
>   to allow access to symbol values from inside of semantic actions code.
>
>   Starting from this version, Bison can also accept symbolic references.
>   When no ambiguity possible, original symbol names may be used as symbolic

s/possible/is possible/

>   references:
> 
>     if_stmt : 'if' cond_expr 'then' then_stmt ';'
>     { $if_stmt = mk_if_stmt($cond_expr, $then_stmt); }
> 
>   In more common case, explicit symbolic names may be declared:

s/more/the more/

>     stmt[result] : 'if' expr[cond] 'then' stmt[then] 'else' stmt[else] ';'
>     { $result = mk_if_stmt($cond, $then, $else); }
> 
>   Location information is also accessible using @name syntax. When accessing
> 
>   symbol names containing dots or dashes, an explicit bracketing ($[sym.1])
> must
>   be used.

s/an explicit/explicit/

>   These features are experimental in this version. More user feedback will
>   help to stabilize them.

Thanks for your work, Alex!