Improving output of syntax errors
| From: | Rowan Tommins | Date: | Sun, 28 Jun 2020 18:53:21 +0000 |
| Subject: | Improving output of syntax errors | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-110761@lists.php.net to get a copy of this message | ||
Hi all,
During the discussion of "T_PAAMAYIM_NEKUDOTAYIM", there was broad agreement that internal token names should not be included in errors shown to users. I now have an implementation of this.
Note that we currently only customise the token descriptions placed into Bison's hard-coded template, so the format remains "syntax error, unexpected %s, expecting %s or %s or %s".
I have distinguished between two types of token:
* Tokens which always represent the same text (e.g. keywords and
operators) are represented by their standard form, e.g. 'unexpected
token "static", expecting "function" ...'
* Tokens which have variable content are given a user-friendly name,
shown as well as the actual text when possible, e.g. 'unexpected
identifier "foo", expecting quoted string ...'
As a special-case, quoted strings show the string's *content* in double quotes, e.g. 'unexpected quoted string "foo" ...' rather than 'unexpected quoted string ""foo"" ...' or 'unexpected quoted string "'foo'" ...'.
A "..." is also included if the text is longer than 30 bytes (where previously it would have been silently truncated).
For example, given the following:
<<<<<<<<<<<<
The current 8.0 alpha will show this:
Parse error: syntax error, unexpected '<<' (T_SL), expecting identifier (T_STRING) or static (T_STATIC) or namespace (T_NAMESPACE) or \\ (T_NS_SEPARATOR) in filename.php on line N
The proposed patch will instead show this:
Parse error: syntax error, unexpected token "<<", expecting identifier or "static" or "namespace" or "\" in filename.php on line N
For more examples, see: https://rwec.co.uk/x/php-parse-errors/comparison.html
The patch can be reviewed at: https://github.com/php/php-src/pull/5722
I am happy to post a small RFC if people think this requires a vote.
Any other feedback is welcome.
(As an aside, the other commonly requested change was to include column numbers; this appears to be feasible, but definitely more complex, and with potential performance trade-offs. I hope to re-visit this later.)
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]