Re: [PATCH] use "unresolved reference" message

[Joel E. Denny]

Hi Alex.

On Sat, 5 Sep 2009, Alex Rozenman wrote:

> On Sat, Sep 5, 2009 at 10:14 PM, Joel E. Denny <address@hidden> wrote:

> > > to "unresolved reference"
> > For the case where there are no valid referents, I think Bison should
> > consistently report "invalid reference".  I don't see how "unresolved
> > reference" describes the subcase of no suggestions any better.  A
> > suggestion is not a resolution, in my view.
> >
> 
> I have strong feeling that we must pay user's attention to the fact that the
> reference is not just "invalid" which is very common word, but it is invalid
> because it has an undeclared component.

I don't see how "undeclared component" describes the distinction we're 
discussing.  The distinction is whether Bison was able to come up with 
suggestions for what the user might have meant.  Regardless of whether 
there are suggestions, the symbol name component of the reference is "not 
declared in this scope".

> For example, in gcc we can see:
> 
> int func() { return a + 1; }
> func.cpp:4: error: ‘a’ was not declared in this scope
> 
> Suppose that instead of this gcc would print:
> func.cpp:4: error: invalid reference: ‘a’.
> I think this messages is unacceptable common, and allows tens of possible
> reasons.

Certainly the second is worse for C++ because the term "reference" has a 
very different meaning in C++.  The first is slightly misleading because 
it implies a scoping issue when, in fact, "a" may never have been declared 
anywhere.

But your gcc analogy doesn't show why "invalid reference" is the wrong 
message only when Bison has no suggestions to give.  If you dislike the 
phrase "invalid reference", then let's discuss an alternative but use it 
consistently regardless of whether Bison has suggestions.

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

In the cases of ambiguous references and misleading references, the 
existing "refers to" submessages can replace the "symbol not found" 
message as they are probably sufficient to indicate what symbol was sought 
and, in those cases, actually found.