Re: Re: [RFC] Improved parser error message

From: Date: Thu, 23 Jun 2011 18:08:59 +0000
Subject: Re: Re: [RFC] Improved parser error message
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-53540@lists.php.net to get a copy of this message
2011/5/18 Gustavo Lopes <glopes@nebm.ist.utl.pt>: > Em Tue, 17 May 2011 17:49:53 +0100, Stas Malyshev <smalyshev@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

« previous php.internals (#53540) next »