Hi,

2013/3/24 Rasmus Lerdorf rasmus@lerdorf.com:

While build of 5.5 snapshot works perfectly, beta1 ZTS build is broken

In file included from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:33:0:
/dev/shm/BUILD/php-5.5.0beta1/build-ztscli/Zend/zend_language_parser.h:331:5:
error: conflicting types for 'zendparse'
In file included from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals.h:28:0,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_compile.h:418,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_modules.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_API.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/main/php.h:38,
from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:25:
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals_macros.h:35:5: note:
previous declaration of 'zendparse' was here

Comparing the 201303201430 snapshot (very closed to beta1) and beta1 archive

201303201430, in bison generated files:
/* A Bison parser, made by GNU Bison 2.4.1. /
beta1:
/ A Bison parser, made by GNU Bison 2.6.1. */

So, it seems snapshot script don't use the same environment than the one
used to generate release.

Any idea how to fix this ?

I took a quick look at this. The Bison change causing this from their
NEWS file is:

*** Features deprecated since Bison 1.875
YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of
%parse-param and %lex-param, will no longer be supported.

I was hoping the fix would be as simple as doing:

-#define YYPARSE_PARAM tsrm_ls
-#define YYLEX_PARAM tsrm_ls
+%parse-param { tsrm_ls }
+%lex-param { tsrm_ls }

but that doesn't quite do the trick. Need to read up more on how
%parse-param and %lex-param work. If someone wants to do a little light
reading and report back it would be appreciated.

http://www.gnu.org/software/bison/manual/html_node/Parser-Function.html#Parser-Function

This page explain how to use it.

Sure, I see how they work, but the problem is that they can't be inside
the %{ ... %} code block there. They have to be outside and as such
won't have access to the #ifdef ZTS. So I don't think we can
conditionally create a reentrant parser like we did before without
refactoring things a bit.
if %parse-param defined, then the paramenter also is added to yyerror,
yydestroctor etc.

it will a little big change.

Right, but if we handle it like we do with TSRMLS_C throughout the code
and always set that %parse-param to this new magic macro we make up and
have it point to void *compiler_globals for zendparse() under ZTS mode
and void otherwise and make sure it is (re)defined correctly in other
places? It might mean we need to refactor zenderror() to take a dummy
first arg since it seems to prepend the parse-param type there. Messy.

Hmm, seems fine, a patch is attached:
https://bugs.php.net/patch-display.php?bug_id=64503&patch=bison_build.patch&revision=latest

but there must be some unused parameter term_ls while in non-zts build...
unused parameter warning I mean, :)
hmm, how stupid I was, hehe , simply:

#ifndef ZTS
(void)tsrm_ls;
#endif

Commit it to master so we can play with it. I think this is the right
approach and we can pull it into 5.5b2. It would be really nice to have
bison 2.6/2.7 support in 5.5.

-Rasmus

Hey:
after a deep look, it seems bison 2.7 still supports
YYPARSE_PARAM, the different is, it starts to write the declaration
of yyparse into parse.h

so,   we also needs the YYPARSE_PARAM defination into parse.h.

following patch also works:

diff --git a/Zend/zend_language_parser.y b/Zend/zend_language_parser.y
index ccbc9b1..3424fa7 100644
--- a/Zend/zend_language_parser.y
+++ b/Zend/zend_language_parser.y
@@ -38,16 +38,17 @@
#define YYSIZE_T size_t
#define yytnamerr zend_yytnamerr
static YYSIZE_T zend_yytnamerr(char*, const char*);

#define YYERROR_VERBOSE
#define YYSTYPE znode

+%}

+%code requires {
#ifdef ZTS

define YYPARSE_PARAM tsrm_ls

define YYLEX_PARAM tsrm_ls

#endif

-%}
+}

%pure_parser
%expect 3

could you verify it?

--
Laruence Xinchen Hui
http://www.laruence.com/