_AT_UNUSED_VALUES_DECLARATIONS])
)
-AT_CHECK([bison input.y], [0], [],
+AT_CHECK([bison]m4_ifval($2, [ --warnings=midrule-values ])[ input.y], [0], [],
[[input.y:11.10-32: warning: unset value: $]$[
input.y:11.10-32: warning: unused value: $]1[
input.y:11.10-32: warning: unused value: $]3[
input.y:11.10-32
On 27 Oct 2006, at 07:59, Joel E. Denny wrote:
I'd rather choose a global default (mid-rule warnings on or off)
and then
let the user specify otherwise either globally (-W) or case-by-case
(USE).
The way I reason is that a package distribution should normally not
issue any warnings -
On Fri, 27 Oct 2006, Hans Aberg wrote:
On 27 Oct 2006, at 07:59, Joel E. Denny wrote:
I'd rather choose a global default (mid-rule warnings on or off) and then
let the user specify otherwise either globally (-W) or case-by-case (USE).
The way I reason is that a package distribution
On Thu, 26 Oct 2006, Hans Aberg wrote:
On 26 Oct 2006, at 02:03, Joel E. Denny wrote:
I don't know the plans for the C++ skeletons. However, the Open Group
specifies that $0 and $-n should be supported by Yacc, so this should not
go away for the C skeletons at least.
If says that $0
Hans == Hans Aberg [EMAIL PROTECTED] writes:
[Just passing by, no time for more :( ]
It was before I recalling you showing up on the list. Probably Bug-
Bison. Perhaps Akim or Paul can inform the truth about $0.
I did suggest it would be nice to be able to name them, and actually
to
On Thu, 26 Oct 2006, Akim Demaille wrote:
Hans == Hans Aberg [EMAIL PROTECTED] writes:
[Just passing by, no time for more :( ]
It was before I recalling you showing up on the list. Probably Bug-
Bison. Perhaps Akim or Paul can inform the truth about $0.
I did suggest it would be
On Wednesday 25 October 2006 23:35, Hans Aberg wrote:
be guaranteed, in view of that Bison is switching to other types of
containers than an underlying array.
but should the container still support the $0 notation ?
that did not come out right, should have read
...but surely the new
On Thursday 26 October 2006 10:41, Akim Demaille wrote:
Hans == Hans Aberg [EMAIL PROTECTED] writes:
[Just passing by, no time for more :( ]
It was before I recalling you showing up on the list. Probably Bug-
Bison. Perhaps Akim or Paul can inform the truth about $0.
I did suggest it
On Thursday 26 October 2006 21:35, Joel E. Denny wrote:
On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
On Thursday 26 October 2006 20:45, Joel E. Denny wrote:
On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
On Thursday 26 October 2006 02:27, Joel E. Denny wrote:
That's nice. I'm
On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
That is, do you believe this warning is too much trouble to be
worthwhile?
The warning would be ok, if it was only true.
It's true inasmuch as we specifically intended to warn about the current
rule's actions without regard to other rules.
On Thursday 26 October 2006 22:55, Joel E. Denny wrote:
On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
That is, do you believe this warning is too much trouble to be
worthwhile?
The warning would be ok, if it was only true.
It's true inasmuch as we specifically intended to warn about
On 26 Oct 2006, at 16:49, [EMAIL PROTECTED] wrote:
be guaranteed, in view of that Bison is switching to other types of
containers than an underlying array.
but should the container still support the $0 notation ?
that did not come out right, should have read
...but surely the new containers
On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
in semantic actions at any level in the parse tree. Bison would have to
check every possible expansion of every possible RHS symbol. That
implementation seems like more work than I want to do.
... but how hard would it be to check just one
On Thu, 26 Oct 2006, Hans Aberg wrote:
On 26 Oct 2006, at 22:55, Joel E. Denny wrote:
What if we simply add an option to turn this warning off globally?
It was this warning tricking me into believe there was something funny about
$0. So I think it should by default be off, unless one is
On Friday 27 October 2006 00:12, you wrote:
On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
in semantic actions at any level in the parse tree. Bison would have
to check every possible expansion of every possible RHS symbol. That
implementation seems like more work than I want to do.
Hi Bison list,
using bison version 2.2.
Message from bison:
pl1-parser.y:873.17-63: warning: unused value: $3
This warning I find a bit confusing...
Line 873 contains: |procoptionlist ',' {$$=$1;} procoption {$$=$1;}
$3 refers to the embedded action after the comma.
My grammar set
On 25 Oct 2006, at 17:05, [EMAIL PROTECTED] wrote:
Hi Bison list,
using bison version 2.2.
Message from bison:
pl1-parser.y:873.17-63: warning: unused value: $3
This warning I find a bit confusing...
Line 873 contains: |procoptionlist ',' {$$=$1;} procoption {$$=$1;}
$3 refers
On 25 Oct 2006, at 22:13, [EMAIL PROTECTED] wrote:
On Wednesday 25 October 2006 21:22, Hans Aberg wrote:
On 25 Oct 2006, at 17:05, [EMAIL PROTECTED] wrote:
My grammar set a number of attributes in an allocated structure
using $0 to
reference the structure on the stack. The full rules are as
On Wed, 25 Oct 2006, Hans Aberg wrote:
be guaranteed, in view of that Bison is switching to other types of
containers than an underlying array.
but should the container still support the $0 notation ?
My memory is hazy, so you will have to wait for the developers with the full
story.
19 matches
Mail list logo
