Bug 67354 - glsl_parser.cpp is broken with bison 3.0
Summary: glsl_parser.cpp is broken with bison 3.0
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Kenneth Graunke
QA Contact:
URL:
Whiteboard:
Keywords:
: 67398 (view as bug list)
Depends on:
Blocks: 67224
  Show dependency treegraph
 
Reported: 2013-07-26 14:05 UTC by Laurent carlier
Modified: 2013-07-31 19:03 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
build log (24.98 KB, text/plain)
2013-07-26 14:05 UTC, Laurent carlier
Details
glsl_parser.cpp file (219.68 KB, text/plain)
2013-07-26 14:06 UTC, Laurent carlier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent carlier 2013-07-26 14:05:26 UTC
Created attachment 83037 [details]
build log

bison 3.0 with mesa from git (probably the same problem with mesa 9.1 and 9.2)
Comment 1 Laurent carlier 2013-07-26 14:06:41 UTC
Created attachment 83038 [details]
glsl_parser.cpp file
Comment 2 Laurent carlier 2013-07-29 08:39:41 UTC
*** Bug 67398 has been marked as a duplicate of this bug. ***
Comment 3 Nikita Malyavin 2013-07-29 13:12:54 UTC
Hello, I'm issuing the same problem and asked bison developers for help (https://lists.gnu.org/archive/html/bug-bison/2013-07/msg00007.html).

Akim Demaille <akim@lrde.epita.fr> wrote:
>The problem here is that this file is using YYLEX_PARAM, whose support was
>removed in favor of %parse-param, %lex-param, and %param.
>The latter is introduced by Bison 3.0, but %parse-param and %lex-param have
>existed for a long time now.
>
>The file looks like this currently:
>
>#define YYLEX_PARAM state->scanner
>…
>%lex-param   {void *scanner}
>%parse-param {struct _mesa_glsl_parse_state *state}
>
>It should rather look like this now:
>
>%lex-param   {struct _mesa_glsl_parse_state *state}
>%parse-param {struct _mesa_glsl_parse_state *state}
>
>and use 'state' instead of 'scanner' in the scanner.  Unfortunately
>there is no way to pass state->scanner to the scanner.
Comment 4 Kenneth Graunke 2013-07-31 19:03:30 UTC
Fixed on master by:

commit 5ffa28df4e4cc22481b4ed41c78632f35765f41d
Author: Laurent Carlier <lordheavym@gmail.com>
Date:   Wed Jul 31 15:18:52 2013 +0200

    mesa/program: remove useless YYID
    
    This fixes the build with Bison 3.0. Also works with Bison 2.7.1.
    
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

commit 6d2a9220b832d9a0c0cf35fcc5b9de1542af267d
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Mon Jul 29 16:03:46 2013 -0700

    mesa/program: Switch from the deprecated YYLEX_PARAM to %lex-param.
    
    YYLEX_PARAM is no longer supported as of Bison 3.0.  Instead, the Bison
    developers recommend using %lex-param.
    
    %lex-param takes a type and variable name, similar to %parse-param,
    so you can't pass an arbitrary expression like state->scanner.  But Flex
    insists on passing the actual scanner object, not an arbitrary object
    like state.
    
    To solve this, the parser defines a wrapper lex() function which accepts
    "state," and calls Flex's lex() function with state->scanner.
    
    Fixes the build with Bison 3.0.  Also works with Bison 2.7.1.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Tested-by: Laurent Carlier <lordheavym@gmail.com>
    Cc: "9.2" mesa-stable@lists.freedesktop.org

commit de917b4c4c4dfc949d5f8e3d9eb2dd48b63a3de5
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Mon Jul 29 15:55:06 2013 -0700

    mesa/program: Change the program parser's namespace.
    
    Bison 3.0 removes the YYLEX_PARAM macro.  In preparation for handling
    this using %lex-param, the parser needs a wrapper function for the
    actual Flex lex() function.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Tested-by: Laurent Carlier <lordheavym@gmail.com>
    Cc: "9.2" mesa-stable@lists.freedesktop.org

commit f043381334a0760ec118d07b6fb7785b5692572a
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Mon Jul 29 15:28:59 2013 -0700

    glsl: Switch from the deprecated YYLEX_PARAM to %lex-param.
    
    YYLEX_PARAM is no longer supported as of Bison 3.0.  Instead, the Bison
    developers recommend using %lex-param.
    
    %lex-param takes a type and variable name, similar to %parse-param,
    so you can't pass an arbitrary expression like state->scanner.  But Flex
    insists on passing the actual scanner object, not an arbitrary object
    like state.
    
    To solve this, the parser defines a wrapper lex() function which accepts
    "state," and calls Flex's lex() function with state->scanner.
    
    Fixes the build with Bison 3.0.  Also works with Bison 2.7.1.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Tested-by: Laurent Carlier <lordheavym@gmail.com>
    Cc: "9.2" mesa-stable@lists.freedesktop.org

commit eb7c8c7fb6e49a04f3fe84a6d438160dc4a14ac0
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Mon Jul 29 15:27:46 2013 -0700

    glsl: Change the lexer's namespace.
    
    Bison 3.0 removes the YYLEX_PARAM macro.  In preparation for handling
    this using %lex-param, the parser needs a wrapper function for the
    actual Flex lex() function.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Tested-by: Laurent Carlier <lordheavym@gmail.com>
    Cc: "9.2" mesa-stable@lists.freedesktop.org

Hopefully these will be backported to 9.2 soon.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.