Hi Akim,
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.
Aha! I didn't quite understand why the YY_ASSERT looked like it did. I
now see the lack of contiguous ranges. So, as another short-term
workaround, I might be able to reduce the number of gaps (by adding
dummy token values) to reduce the length of the YY_ASSERT line.
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
]])[}
Thank you so much!!!!
--Vince--