[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] use "unresolved reference" message
From: |
Joel E. Denny |
Subject: |
Re: [PATCH] use "unresolved reference" message |
Date: |
Sat, 5 Sep 2009 20:20:03 -0400 (EDT) |
User-agent: |
Alpine 1.00 (DEB 882 2007-12-20) |
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.
- [PATCH] use "unresolved reference" message, Alex Rozenman, 2009/09/05
- Re: [PATCH] use "unresolved reference" message, Joel E. Denny, 2009/09/05
- Re: [PATCH] use "unresolved reference" message, Alex Rozenman, 2009/09/05
- Re: [PATCH] use "unresolved reference" message,
Joel E. Denny <=
- Re: [PATCH] use "unresolved reference" message, Alex Rozenman, 2009/09/06
- Re: [PATCH] use "unresolved reference" message, Joel E. Denny, 2009/09/06
- Re: [PATCH] use "unresolved reference" message, Alex Rozenman, 2009/09/10
- Re: [PATCH] use "unresolved reference" message, Joel E. Denny, 2009/09/10
- Re: [PATCH] use "unresolved reference" message, Alex Rozenman, 2009/09/11
- Re: [PATCH] use "unresolved reference" message, Joel E. Denny, 2009/09/11
- Re: [PATCH] use "unresolved reference" message, Akim Demaille, 2009/09/16