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

Reply via email to