2011/5/18 Gustavo Lopes <glo...@nebm.ist.utl.pt>: > Em Tue, 17 May 2011 17:49:53 +0100, Stas Malyshev <smalys...@sugarcrm.com> > escreveu: > >> I think we need to keep token name in the message, since it makes it >> easier to understand what parser expected if you need to debug the parser >> (as opposed to your code). So I think we need to have both the >> human-readable name and the token name, as Andi suggested. > > I think this alternative has very little value for debugging the parser. > There are no repeated labels for the tokens, so even if you don't know the > token name by heart, you can look it up in 10 seconds. > > Keeping the token name will only perpetuate the confusion it has caused. I > think it ought to be dropped, but if no consensus can be reached, this would > be better than the status quo. > > -- > Gustavo Lopes > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
So, following some suggestion I made a patch wich displays such messages: $ sapi/cli/php -r 'class ' Current: Parse error: syntax error, unexpected $end, expecting T_STRING Patched: Parse error: syntax error, unexpected end of file, expecting 'identifier' (T_STRING) $ sapi/cli/php -r 'class abc foo' Current: Parse error: syntax error, unexpected T_STRING, expecting '{' in Command line code on line 1 Patched: Parse error: syntax error, unexpected 'foo' (T_STRING), expecting '{' in Command line code on line 1 As can be noticed, I added the actual scanned string in the "unexpected" part. This might be useful for finding really which makes the parser error. (It was a bit tricky though :D) Any thoughts? https://wiki.php.net/rfc/improved-parser-error-message -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php