Hi Vince,
> Le 22 août 2021 à 22:14, Vince Huffaker <vi...@vincejulie.com> a écrit :
>
> That macro doesn't seem to exist, but the _MSC_VER does, so this line:
>
> #ifndef _MSC_VER
>
> fixes the issue.
Yes, of course, sorry about that...
>> Also, do you really need to specify the numbers for all the tokens? It is
>> because you gave these numbers that the assertion is long. If bison had
>> numbered itself, there wouldn't be holes, and the assertions is short. Why
>> do you provide the token numbers?
> We use the Bison parser for reading our native file format. So, we need to
> make sure that the token values never change, otherwise we would not be able
> to read legacy files. Therefore, we specifically define the values for each
> token. Each new version of each object type has its own token value, so the
> numbers keep going up.
Makes perfect sense.
> But, maybe there's some alternative approach for bison in the future? Maybe
> we could reserve a range of token values... or somehow indicate to Bison that
> our token values are not truly 'custom', but are sequential numbers... maybe
> that would help? Don't know -- just trying ideas..
Your numbers are not consecutive, there are gaps. Hence the number of clauses:
one per (contiguous) range.
> Is there something I can add to the Bison distribution to automatically add
> that #ifndef line? Or do I need to wait for a new version?
I'll wrap a fix for the next release. Meanwhile, you can just disable
parse.assert, and the assertion will no longer be emitted.
Or change your installation of Bison. In ..../data/skeleton/variant.hh, look
for
{]b4_parse_assert_if([[
]b4_assert[ (]b4_tok_in($@)[);
]])[}
That's where you want to add the #if lines. Something like
{]b4_parse_assert_if([[
#if !defined _MSC_VER || defined __clang__
]b4_assert[ (]b4_tok_in($@)[);
#endif
]])[}
