php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #76753 'Warning: "continue" targeting switch' uncatchable
Submitted: 2018-08-16 17:33 UTC Modified: 2018-08-22 21:33 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: php at darkain dot com Assigned: cmb (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 7.3.0beta2 OS: all
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: php at darkain dot com
New email:
PHP Version: OS:

 

 [2018-08-16 17:33 UTC] php at darkain dot com 
Description:
------------
Using "continue" on a "switch" statement now throws a warning. However, this warning never triggers the function specified in "set_error_handler". My unit testing framework uses "set_error_handler" to log and report any issues, but is not being triggered with this new warning.

Test script:
---------------
<?php

// REPORT ALL ERRORS / WARNINGS / NOTICES
error_reporting(E_ALL);

// CATCH ERRORS / WARNINGS / NOTICES, AND THROW AN EXCEPTION IN THEIR PLACE
set_error_handler(function ($errno, $errstr, $errfile, $errline) {
	throw new ErrorException($errstr, $errno, 0, $errfile, $errline);
});


for ($x=0; $x<10; $x++) {
    switch ($x) {
        case 1:
            continue;
    }
}


Expected result:
----------------
Fatal error: Uncaught ErrorException: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"?

Actual result:
--------------
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-08-16 21:59 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2018-08-16 21:59 UTC] cmb@php.net 
These warnings[1] are compile time warnings, and as such cannot be
caught by an error handler.  Their type should be
E_COMPILE_WARNING instead of E_WARNING, though.

[1] <https://github.com/php/php-src/blob/php-7.3.0beta2/Zend/zend_compile.c#L4554-L4564>
 [2018-08-16 22:11 UTC] php at darkain dot com 
In my particular case, the code is split between two separate files. The first file has the set_error_handler, and then AFTER that statement, there is include('other.php'), so it should still be caught (general syntax errors and all other errors/warnings are caught this way)

You can see the full file here:
https://github.com/darkain/altaform-core/blob/master/test/cli.php

Results can be found here:
https://travis-ci.org/darkain/altaform-core/jobs/416134464

(in my particular case, I found this by manually reviewing the Travis-CI reports, but because the warning was never caught, it never generated the email report saying there was an issue in the code base)
 [2018-08-17 10:00 UTC] cmb@php.net 
If I split the code[1], the ErrorException is thrown if OPcache is
disabled.  If it is enabled, the ErrorException is not thrown, but
it is also not thrown for parse errors.  That is to be expected,
though; see bug #76535.

[1] <https://gist.github.com/cmb69/7a747837cd6e7e143ef0a3809e75d15d>
 [2018-08-20 12:04 UTC] nikic@php.net 
@cmb: Making it a compile warning would make it entirely uncatchable. I don't think that there is a technical reason to use compile warnings anymore, we should probably migrate away from them in general (it used to be that invoking error handlers during compilation was unsafe, but nowadays it's no longer an issue).

As already identified, the issue here is in opcache, though not quite the same as bug #76535, which is about warnings not being thrown on subsequent accesses. The reason why the error handler is not called on the first access either is that the error handler is being unset by opcache in https://github.com/php/php-src/blob/master/ext/opcache/ZendAccelerator.c#L1734.
 [2018-08-20 14:55 UTC] cmb@php.net 
Thanks for the explanation, Nikita.

Regarding E_COMPILE_WARNING: it's probably best to get rid of it
in PHP 8 (we're issuing that level only for a couple of things).

Regarding OPcache's temporary disabling of the error handler:
since it appears to happen for a reason, would it be possible to
store the issued warnings, and to raise them after compilation?
Otherwise this ticket should be closed as WONTFIX.
 [2018-08-20 18:02 UTC] php at darkain dot com 
I think it would be best to mark this as closed now. I was not aware that this particular warning should be issued at compile time rather than run time. Knowing this, my scripts have been updated accordingly and things are fine on my end now.
 [2018-08-22 21:33 UTC] cmb@php.net
-Status: Verified +Status: Closed -Assigned To: +Assigned To: cmb
 [2018-08-22 21:33 UTC] cmb@php.net 
Okay, closing then.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 14:01:32 2024 UTC