Re: symbol_type::token () removed?

[pramod kumbhar]

Hello Akim,

As mentioned by Wolfgang in the original thread[1], we also use this mostly
for testing purpose and implementing some debug utilities.
In [2] we have some tests which looks like:

TokenType token_type(const std::string& name) {
    // some glue code
    SymbolType sym = scanner.next_token();
    retun sym.token();
}

and then we test stuff as:

   REQUIRE(token_type(" h' = (hInf-h)/hTau\n") == Token::PRIME);
   REQUIRE(token_type("while") == Token::WHILE);
   REQUIRE(token_type("if") == Token::IF);

Also, we have code like below for some lexer debugging utility [3]:

   switch (token) {
       /// token with name ast class
       case Token::NAME:
       case Token::METHOD:
       case Token::SUFFIX:
       case Token::VALENCE:
       case Token::DEL:
       case Token::DEL2: {
                             auto value = sym.value.as<ast::Name>();
                             std::cout << *(value.get_token()) << std::endl;
                             break;
                         }
        ...

With 3.5, we have to change above code like this [4] which seems bit
verbose ( / ugly).

If you have any suggestions to do this more cleanly, please let me know and
I will be happy to try / test.

Regards,
Pramod

[1] https://lists.gnu.org/archive/html/bug-bison/2020-01/msg00001.html
[2]
https://github.com/BlueBrain/nmodl/blob/c763cfadb71a736dafc00ceaa6ad2803b0cc9169/test/lexer/tokens.cpp
[3]
https://github.com/BlueBrain/nmodl/blob/c763cfadb71a736dafc00ceaa6ad2803b0cc9169/src/lexer/main_nmodl.cpp
[4] https://github.com/BlueBrain/nmodl/pull/270/files

On Sun, Mar 8, 2020 at 6:55 AM Akim Demaille <address@hidden> wrote:

> Hi!
>
> > Le 7 mars 2020 à 19:16, pramod kumbhar <address@hidden> a
> écrit :
> >
> > Hello All,
> >
> > I am posting first time on this list, specifically in response to the old
> > thread here :
> > https://lists.gnu.org/archive/html/bug-bison/2020-01/msg00001.html
> >
> > Just want to highlight that our parsers also use symbol_type::token() and
> > they started failing with v3.5.
>
> Could you tell us more about your own use case?  It is still not clear to
> me what is actually needed.
>
> Cheers!