[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue in bison error format.

From: Akim Demaille
Subject: Re: Issue in bison error format.
Date: Wed, 25 Sep 2019 22:09:12 +0200

> Le 24 sept. 2019 à 20:53, Kaz Kylheku <address@hidden> a écrit :
> Hi all,

Hi Kaz,

> Errors from Bison look like this:
>  parser.y:876.63: invalid character: `}'
> This format differs in a small detail from the usual GCC one and so,
> for instance, the Vim editor doesn't understand it; it won't jump to
> the error location.

Funny, I had never realized GCC used colon.

> If we change it to:
>  parser.y:876:63: invalid character: `}'
>              ^
>              colon, not dot!
> then everything is cool. It now looks like a GNU C error message,
> and Vim jumps to line 876, putting the cursor on the offending
> closing brace.

Well, GCC does not comply with the GNU Coding Standards.


And I never realized, because I use Emacs, and it understands both formats ;-)

Neither GCC nor clang display the full location, with start and end boundaries, 
so I'm not sure how it would look like in that case.  Actually, I wouldn't be 
surprised if Bison had columns even before GCC: I remember in my early days of 
C++ that sometimes I would split long lines with \n to understand what part of 
the line was actually wrong.

> I understand that of course this can be worked around from the editor
> side. (Vim has quite a few entries in it default "errorformat" list of
> patterns. Maybe a new version than what I'm using has added the
> pattern for Bison.)
> Still, why have, in GNU Bison, a gratuitous difference in error
> reporting relative to GNU C.

Well, I agree it is not nice, but I am reluctant to change.
- this is the format we used for years (again, possibly before GCC had columns)
- this is the format recommended by the GCS
- this is the format used by the generated parsers too, and I don't
  see why Bison would depart from what it pushed onto the users
- I don't want to change the behavior of the generated parser, so
  I don't plan to change the format of the generated parsers

I fully agree with you that this is not nice, and I appreciate that you took 
the time to expose the problem, and proposed a solution.  However, I think it's 
best for Bison not to change this.  Really, teaching the format to Vim seems 
the best option to me.

*If* the GNU Coding Standards were to change, I would have to revise my 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]