bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: symbol_type::token () removed?


From: Akim Demaille
Subject: Re: symbol_type::token () removed?
Date: Sun, 3 May 2020 08:33:27 +0200

Hi Pramod,

> Le 2 mai 2020 à 20:39, pramod kumbhar <address@hidden> a écrit :
> 
> Hello All,
> 
> I haven't looked at what is changed with 3.5.91 but our CI
> <https://travis-ci.org/github/BlueBrain/nmodl/jobs/682367580> started
> failing with following errors:
> 
> [ 27%] Building CXX object
> src/lexer/CMakeFiles/lexer_obj.dir/__/parser/diffeq_context.cpp.o
> 1321/Users/travis/build/BlueBrain/nmodl/src/parser/diffeq_context.cpp:81:41:
> error: no member named 'by_type' in 'nmodl::parser::DiffeqParser'
> 1322        if (token_type ==
> DiffeqParser::by_type(DiffeqParser::token::END).type_get()) {
> 1323
> 
> This is after homebrew started shipping <goog_590446785>bison-3.5.91
> <https://github.com/Homebrew/homebrew-core/blob/master/Formula/bison.rb>
> since yesterday.

W00t???  Home brew ships betas???  That sounds to me like a very silly
idea.  It's good that it helps us in the present case, but honestly I
think it's a very bad idea.

> I will take a look at the details tomorrow. Here was the previous thread
> <https://lists.gnu.org/archive/html/bug-bison/2020-03/msg00015.html>.

I'm installing this in master.  Which, I guess, will appear in brew
with the next beta...

commit 20725d57d1805078777ac642de3f6641b6e05af7
Author: Akim Demaille <address@hidden>
Date:   Sun May 3 08:17:05 2020 +0200

    c++: provide backward compatibility on by_type
    
    To write unit tests for their scanners, some users depended on
    symbol_type::token():
    
        Lexer lex("12345");
        symbol_type t = lex.nextToken();
        assert(t.token() == token::INTLIT);
        assert(t.value.as<int>() == 12345);
    
    But symbol_type::token() was removed in Bison 3.5 because it relied on
    a conversion table.  So users had to find other patterns, such as
    
        assert(t.type_get() == by_type(token::INTLIT).type_get());
    
    which relies on several private implementation details.
    
    As part of transitioning from "token type" to "token kind", and making
    this a public and documented interface, "by_type" was renamed
    "by_kind" and "type_get()" was renamed as "kind()".  The latter had
    backward compatibility mechanisms, not the former.
    
    In Bison 3.6 none of this should be used, but rather
    
        assert(t.kind() == symbol_kind::S_INTLIT);
    
    Reported by Pramod Kumbhar.
    https://lists.gnu.org/r/bug-bison/2020-05/msg00012.html
    
    * data/skeletons/c++.m4 (by_type): Make it an alias to by_kind.

diff --git a/data/skeletons/c++.m4 b/data/skeletons/c++.m4
index 8bc70fdf..59c94ce0 100644
--- a/data/skeletons/c++.m4
+++ b/data/skeletons/c++.m4
@@ -414,6 +414,9 @@ m4_define([b4_symbol_type_define],
       symbol_kind_type kind_;
     };
 
+    /// Backward compatibility for a private implementation detail.
+    typedef by_kind by_type;
+
     /// "External" symbols: returned by the scanner.
     struct symbol_type : basic_symbol<by_kind>
     {]b4_variant_if([[




reply via email to

[Prev in Thread] Current Thread [Next in Thread]