Improving output of syntax errors

From: 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]

« previous php.internals (#110761) next »