Future/bison
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/bison.git synced 2026-03-09 04:13:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

glr2.cc: disable incorrect warnings from GCC6 to 9

Browse Source 
For instance with GCC8:

    616. regression.at:1560: testing Lex and parse params: glr2.cc ...
    tests/regression.at:1560: COLUMNS=1000; export COLUMNS; NO_TERM_HYPERLINKS=1; export NO_TERM_HYPERLINKS;  bison --color=no -fno-caret  -o input.cc input.y
    tests/regression.at:1560: $CXX $CXXFLAGS $CPPFLAGS  $LDFLAGS -o input input.cc $LIBS
    stderr:
    input.cc: In member function 'YYRESULTTAG glr_stack::yyresolveValue(glr_state*)':
    input.cc:1796:10: error: potential null pointer dereference [-Werror=null-dereference]
       return yypred ? &(asItem(this) - yypred)->getState() : YY_NULLPTR;
              ^~~~~~
    input.cc:1796:10: error: potential null pointer dereference [-Werror=null-dereference]
       return yypred ? &(asItem(this) - yypred)->getState() : YY_NULLPTR;
              ^~~~~~
    cc1plus: all warnings being treated as errors

It complains that the implicit this in yypred might be null.  It fears
it because of loops such as

    for (glr_state* yys = firstTopState();
         yys != yystateStack.yysplitPoint;
         yys = yys->pred())
      yyn += 1;

that could possibly set yys to null, since yys->pred might return
null.  However, the warning is incorrect, since in C++ `this` cannot
be null.  GCC 10 no longer emits this warning.

GCC 7 also complains many times about glr_stack::yyresolveLocations
when NDEBUG is enabled (when it is not, YYASSERT (yyoption !=
YY_NULLPTR) is probably enough to pacify GCC):

    616. regression.at:1560: testing Lex and parse params: glr2.cc ...
    tests/regression.at:1560: COLUMNS=1000; export COLUMNS; NO_TERM_HYPERLINKS=1; export NO_TERM_HYPERLINKS;  bison --color=no -fno-caret  -o input.cc input.y
    tests/regression.at:1560: $CXX $CXXFLAGS $CPPFLAGS  $LDFLAGS -o input input.cc $LIBS
    stderr:
    input.cc: In member function 'void glr_stack::yyresolveLocations(glr_state*, int)':
    input.cc:3061:46: error: potential null pointer dereference [-Werror=null-dereference]
                     yyrhsloc[0].getState().yyloc = yyoption->state()->yyloc;
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    input.cc:3061:46: error: potential null pointer dereference [-Werror=null-dereference]
                     yyrhsloc[0].getState().yyloc = yyoption->state()->yyloc;
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    input.cc:3061:46: error: potential null pointer dereference [-Werror=null-dereference]
                     yyrhsloc[0].getState().yyloc = yyoption->state()->yyloc;
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    input.cc: In member function 'YYRESULTTAG glr_stack::yyresolveValue(glr_state*)':
    input.cc:3061:46: error: potential null pointer dereference [-Werror=null-dereference]
                     yyrhsloc[0].getState().yyloc = yyoption->state()->yyloc;
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    input.cc:3061:46: error: potential null pointer dereference [-Werror=null-dereference]
                     yyrhsloc[0].getState().yyloc = yyoption->state()->yyloc;
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    input.cc:3061:46: error: potential null pointer dereference [-Werror=null-dereference]
                     yyrhsloc[0].getState().yyloc = yyoption->state()->yyloc;
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    input.cc:3061:46: error: potential null pointer dereference [-Werror=null-dereference]
                     yyrhsloc[0].getState().yyloc = yyoption->state()->yyloc;
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    input.cc:3061:46: error: potential null pointer dereference [-Werror=null-dereference]
                     yyrhsloc[0].getState().yyloc = yyoption->state()->yyloc;
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
    input.cc:3061:46: error: potential null pointer dereference [-Werror=null-dereference]
                     yyrhsloc[0].getState().yyloc = yyoption->state()->yyloc;
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~

* data/skeletons/glr2.cc (YY_IGNORE_NULL_DEREFERENCE_BEGIN)
(YY_IGNORE_NULL_DEREFERENCE_BEGIN): New.
(glr_state::pred, glr_stack::yyresolveLocations): Use them.
This commit is contained in:
Akim Demaille
2020-09-13 09:52:53 +02:00
parent 2bc886dc02
commit cf8f805d36
2 changed files with 33 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
TODO
View File

@@ -158,9 +158,12 @@ Les catégories d'avertissements incluent :
Line -1 and -3 should mention CATEGORIE, not CATEGORY.
* Bison 3.8
** Rewrite glr.cc
*** glr.c
Get rid of scaffolding in glr.c.
** Rewrite glr.cc (currently glr2.cc)
*** Remove jumps
We can probably replace setjmp/longjmp with exceptions. That would help
tremendously other languages such as D and Java that probably have no
similar feature. If we remove jumps, we probably no longer need _Noreturn,
so simplify `b4_attribute_define([noreturn])` into `b4_attribute_define`.
*** Coding style
Move to our coding conventions. In particular names such as yy_glr_stack,
@@ -178,6 +181,10 @@ There are many places where pointers should be replaced with references.
Don't use YYSTYPE and YYLTYPE but parser::semantic_type and
parser::location_type. Undefine YYSTYPE and YYLTYPE.
*** glr.c
When glr2.cc fully replaces glr.cc, get rid of the glr.cc scaffolding in
glr.c.
* Chains
** Unit rules / Injection rules (Akim Demaille)
Maybe we could expand unit rules (or "injections", see