Re: Help with new test case.

[Kaz Kylheku]

On 2020-09-06 00:52, Akim Demaille wrote:
> Kaz,
>
> > Le 5 sept. 2020 à 21:41, Kaz Kylheku <kaz@kylheku.com> a écrit :
> >
> > On 2020-09-05 00:59, Kaz Kylheku wrote:
> > > Hi,
> > > I'm trying to add a test case in the form of a new entry in 
> > > examples/c.
>
> Examples are show cases, they are no tests.  They are there to serve
> as a starting point for people who want to understand how Bison
> works.

I understand that there is a separate test suite area driven
by M4 macros.

However, the examples are added to CHECK_progs, have test scripts
and have test cases which are reported as succeeding or failing.
So *de facto*, they are test cases; Bison wants to keep them working.
If an example use of Bison doesn't build and work, that's
obviously no good.

The particular test case I'm working on demonstrates a possible
structure for a program that incorporates a parser.

The examples area is a much better fit for the structure of the
that test case than the main test suite. This is because the inputs
are specified in an ordinary way, as project files, and the
examples even have Makefiles for building them outside of the
Bison tree.

> > local.mk follows.
>
> I can't debug your stuff this way. If you have some fork with a branch,
> I could check that.

That is understandable. I just posted that work-in-progress file
in case someone might recognize that I'm doing something obviously wrong
in that make include file.

Anyway, I got it to work.

I'm going to post it as a patch to the bison-patches mailing list.

> > buildscenario_CFLAGS = $(TEST_CFLAGS) \
> >                       -W -Wall -ansi -pedantic \
> >                       -Werror=implicit-function-declaration \
> >                       -Werror=missing-prototypes \
> >                       -Werror=strict-prototypes
>
> You are free to do whatever you want in your fork of Bison, but Bison
> itself can't afford to assume that these flags are supported by the
> compiler.

It is clear that Bison builds on numerous non-GNU systems with
compilers that do not have GCC-compatible drivers.

Now that the test case works, I will look for ways to address it.
I'd like to have that solved before sending the patch.

One possibility is to disable that case entirely if the compiler is
not GCC. It is not necessary for that test case to be exercised
on every target. It's not probing anything that is related to
platform portability.

The compiler options are important because they test for
functions not being declared properly, which could otherwise
pass with warnings.

One reason why that is important is that the program from which
this test case is derived can be compiled as C or C++. In C++,
you cannot get away with calling undeclared functions.

> > %D%/y.tab.c: %D%/parser.y
> >        $(buildscenario_BISON) $(buildscenario_BISONFLAGS) -v -d $<
> >        @# workaround for Bison 3.x: yyparse declared in y.tab.h
> >        sed -e /yyparse/d < y.tab.h > y.tab.h.tmp
>
> What problem is this solving?

This logic comes from a real-world program which solved a breakage
that way. If we take that out, the test case will not compile.

It will become clearer (not to mention directly testable) when I
publish the test case.