bug-bison
[Top][All Lists]
Advanced

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

Suggested Fix/Change


From: Jot Dot
Subject: Suggested Fix/Change
Date: Fri, 18 Dec 2020 02:16:05 -0700 (MST)

Tools Used:  bison (GNU Bison) 3.7.1

I was attempting to convert my lalr(1) code to glr.
I know that the current glr version only uses POD.
I was using variants and lalr(1). When changing the
source to use glr I completely missed removing one line:

%define api.token.constructor

Naturally it must be removed for glr.

ISSUE:

With the %define in the code, Bison still processes the
grammar and outputs a report that is exactly the same
as when that %define is not in the source, and then silently
fails with an error code 1 and leaves two temporary
files around.

The problem is that (visually) it appears there is
no issue at all! Even the --verbose option has no effect.

My Visual Studio report:
1>parser.y : warning : 4 shift/reduce conflicts [-Wconflicts-sr]
1>parser.y : warning : 5 reduce/reduce conflicts [-Wconflicts-rr]
1>    2 Warning(s)
1>    0 Error(s)

The command line shows no difference in output (good vs fail).
Even with --verbose.

I consider this almost a silent failure since there is no real
visual clue anything is wrong. Heck, my first clue was
simply that Bison was "a bit too quick" on the command line.

My Request:

It would be real nice if Bison would check for this invalid option
and output an error instead of making it look like it worked.
Actually, any visual clue would be appreciated!

It should also clean up and remove the temp files it generated
when it does fail.

Thanks.



reply via email to

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