Fixed bug #75218

[nikic]

I've introduced a new CompileError type, from which ParseError inherits. These errors are not parse errors in the narrow sense of the term, even though they happen to be generated during parsing in our implementation. Additionally reusing the ParseError class for this purpose would change existing error messages (if the exception is not caught) from a "Fatal error:" to a "Parse error:" prefix, and also the error kind from E_COMPILE_ERROR to E_PARSE.

Bug #75218

[nikic]

I'd mainly like to have feedback on the change to the exception hierarchy.

[TysonAndre]

I'd love to get this into 7.3. Do you have anyone in mind as a reviewer? (I don't see any obvious issues, but I'm not a maintainer)

Something I didn't know about when filing the bug: This could also test token_get_all('<?php abstract final class X { }', true)) to test token_get_all having proper error handling, even if the implementation is refactored later.
(true indicating that it additionally validates the AST.)

Thoughts on the change to the exception hierarchy (Unimportant to me compared to avoiding the fatal error):

• Some other checks are technically not parse errors in the AST, but post-parsing validation errors (e.g. verifying that the default value of a property is not a dynamic value (e.g. public $x = self::$y;)). Making those CompileError as well might make an error hierarchy more consistent.
• I'm also fine with making everything a ParseError to start with, since I can't think of many differences in how a CompileError and a ParseError would be handled, even in applications such as analyzers, code style fixers, etc.

[nikic]

Merged as d04917c, with a note in UPGRADING.

I stuck with CompileError here to make sure error types & messages stay the same, and because I expect that we'll need this anyway when converting the compiler to exceptions.

[TysonAndre]

There's a surprising consequence of this: CompileError gets treated like a "Fatal error" instead of a "Catchable fatal error" when running with php -a.

the CompileError thrown by token_get_all() also terminates php -a

Perhaps E_COMPILE_ERROR can be treated the same way E_PARSE is in the below block. I'm not sure how to differentiate zend_error_helper from zend_error_noreturn and other similar functions.

// in main/main.c
			case E_ERROR:
			case E_CORE_ERROR:
			case E_COMPILE_ERROR:
			case E_USER_ERROR:
				error_type_str = "Fatal error";
				syslog_type_int = LOG_ERR;
				break;

php > throw new ParseError('x');
Parse error: x in php shell code on line 1
php > throw new CompileError('x');
Fatal error: x in php shell code on line 1
.... This terminates php -a

php > try {throw new CompileError('x');} catch (Throwable $_) { var_export($_); }
CompileError::__set_state(array(...

---

Filed https://bugs.php.net/bug.php?id=78489&thanks=4