-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unhandled RuntimeException: $stackPtr is not a class member var #2851
Comments
Ok, so this took some investigation, but the issue is actually caused by the The problem is here (last line):
They also change an The problem is that this: } elseif (true) {
self::$x = 1;
return;
} Becomes: }
} else if (true) {
self::$x = 1;
return;
} |
Thank you for the explanation, @jrfnl! The issue in the On the PHP_CodeSniffer side, would it make sense to run something like |
@morozov I think I may have tested with Running May I suggest closing this issue and #2852 ? |
Not reproducible on |
I understand. Would it still make sense to lint the state after the last attempt in the case of a |
@morozov An uncaught Or is that not what you meant ? |
@jrfnl it is what I mean. The question is, what prevents PHPCS from catching runtime exceptions at the runner level? Or at whatever level that schedules the attempts to fix the file: while (i < 50) {
try {
if (fix()) {
return
}
} catch (RuntimeException e) {
lint()
throw e
}
i++
} |
@morozov I see what you mean. PHPCS has no context on how to handle the error in the runner. I haven't looked at the code for the PHPCBF runner recently, but I imagine something similar could be done, but it would also need to prevent overwriting the file in that case (which is now prevented by the fatal error). I'd need to look into that more deeply to be sure what would actually be needed. |
I agree. But right now, a user who runs PHPCBF doesn't have a clue about where exactly the bug is and where to report it. If PHPCBF catches the exception, explicitly tells the user that there is a bug and provides all the needed context (e.g. the names of the sniff fixers applied at the last attempt), there's a higher chance that the bug will be reported in the correct repository. |
Well, to do that I think a lot more is needed than simply catching the exception as I don't think PHPCS keeps track of which fixers were applied before. Either way, I do think this is an interesting feature request. You may want to open a dedicated issue for the feature request "to provide more information to the end-user on a run without verbosity when PHPCBF encounters a fatal error". |
Unfortunately, I don't know how to reproduce this issue with the OOTB standards, but here's the minimal required setup:
The run results in the following error:
I’m filing it here because the stack trace doesn’t contain any non-squizlabs/php_codesniffer resources.
The text was updated successfully, but these errors were encountered: