Re: Bison 3.6 requires runtime type information?

[Adrian]

Hi Akim,

Now that you mention it, I did add parse.assert at the same time I
upgraded to 3.6.
I had totally forgotten about that change.
Removing parse.assert indeed makes it compile fine without rtti.
So I guess that explains everything.

It would be nice if it were possible to enable parse.assert without rtti,
but I understand if it's difficult/impossible and that it's a very
minor use case.
However, just for discussion, if I understood the docs bison's variant
does not store a type tag
because it already knows what type the semantic value is?
And I'm guessing it does so for assert, using rtti?
If so, it should be possible to implement the tagging without rtti,
the way c++17's variant works.
I believe the standard library variant does something like defining a
templated function for each variant type,
so each address of this templated function corresponds 1-1 with one of
the variant types,
and can be used to store/check the type.
I believe that a new function is not even necessary;
the address of the "as" method on bison's variant satisfies the requirements
(but maybe depending on an existing function with another purpose is
not a good idea).
If this (removing rtti dependency for parse.assert) is something you'd
be interested in,
I may give making a patch a shot sometime in the future.

Anyways, thank you very much for your time and help!

Kind regards,
Adrian

On Sat, Jun 27, 2020 at 4:36 AM Akim Demaille <akim@lrde.epita.fr> wrote:
>
> Hi Adrian,
>
> > Le 27 juin 2020 à 10:21, Adrian <withoutpointk@gmail.com> a écrit :
> >
> > Hi,
> >
> > The exact error message I'm getting is:
> >
> > In constructor 'Parser::semantic_type::semantic_type(T&&)’:
> > error: cannot use typeid with -fno-rtti
>
> So your skeleton is lalr1.cc (variants are not supported by glr.cc).
>
> > I'm just specifying %language "c++".
> > What's the difference between using that declaration and using the
> > skeleton declaration?
>
> From the language and directives such as %glr-parser, a skeleton is
> chosen.
>
> > Should I be doing both (but everything seemed to work fine with C++
> > and bison 3.4.2 without the skeleton declaration)?
>
> No, what you did is fine.
>
> > I'm not sure exactly what command I'm running as I'm using the cmake module.
> > But I would guess the only flags it passes are for setting the output files.
> >
> > When I grep the bison 3.6.4 source for "typeid", I find references
> > inside data/skeletons/variant.hh.
> > Indeed, I am using variants along with api.token.constructor.
> > However, strangely when I grep the 3.4.2 source, I also find
> > references to typeid (in that same file),
> > so I'm not sure why I'm only getting a compilation error now.
> >
> > Hopefully this provides more useful information.
> > Please let me know if I can provide anything else.
>
> We don't _need_ rtti, we just use it when Bison's assertions are
> enabled, via
>
> %define parse.assert
>
> in which case you should not pass -fno-rtti to the compiler, indeed.
>
> I'll add the commit below to the documentation.  Note that I don't
> think anything changed on this regard since 3.4, the problem might be
> elsewhere.
>
> Cheers!
>
>
> commit 4efb2f7bd27d496e2aacb8867b53f7d22d8dfeda
> Author: Akim Demaille <akim.demaille@gmail.com>
> Date:   Sat Jun 27 10:31:59 2020 +0200
>
>     doc: parse.assert in C++ requires RTTI
>
>     * doc/bison.texi (%define Summary): Say it.
>
> diff --git a/doc/bison.texi b/doc/bison.texi
> index ac71fe6d..41461d29 100644
> --- a/doc/bison.texi
> +++ b/doc/bison.texi
> @@ -6658,7 +6658,10 @@ In C, some important invariants in the implementation 
> of the parser are
>  checked when this option is enabled.
>
>  In C++, when variants are used (@pxref{C++ Variants}), symbols must be
> -constructed and destroyed properly.  This option checks these constraints.
> +constructed and destroyed properly.  This option checks these constraints
> +using runtime type information (RTTI).  Therefore the generated code cannot
> +be compiled with RTTI disabled (via compiler options such as
> +@option{-fno-rtti}).
>
>  @item Accepted Values: Boolean
>
>