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
Fix hanging on some invalid php code #358
Conversation
When running on a file with the following input <?php
class MyClass extends Illuminate\Database\Eloquent\Model; {} It is stuck in an infinite loop, where the console keeps spamming
Looks like it cannot break out of this |
@olivernybroe It is exactly what's happening. That infinite loop is causing a problem because of invalid token. Now if you remove "@" and use my solution with Try{} and empty catch, insights will work perfectly and you can see this bad code report at the end of process ("Unparsable php code: syntax error or wrong phpdocs.") |
@50bhan Yes, but I am actually still getting this error when using your branch. |
@50bhan I Just added a test for it, so you can see what I mean with it is still failing for me. |
@olivernybroe Thanks! I'm working on it :) |
@olivernybroe After couple of hours struggling, following result achieved:
And in that library E-NOTICE errors somehow are suppressed, so code will stuck in an infinite loop. But in actual project, we run insight from CLI and code flow is much different from our test and we can catch errors with my solution. So I changed test in two independent ways (just for demonstration). We can change analyzer to detect this kind of bad code, but it will be beneficial just for testing purposes. Another way was activate error reporting to catch occurred exception! I don't know which one (or no one) of them is good, so please share your opinion. |
@50bhan Oh wauw, sorry about that, I totally forgot that, that method is actually running the phpcs library directly Option 1 (change analyzer): This is nice, but could result in extending the analyzer with a lot of edge cases, which makes extending the analyzer harder (which already is kinda hard). However I think we can benefit other places than in test only from this, but primarily it will prob. affect tests. Option 2 (Error reporting): I think this makes a lot of sense. Looking into it this is also what phpstan does I think I'll prefer option 2, even though how you implemented option 1 is nice. @Jibbarth @nunomaduro Could we get a third opinion from one of you? |
@olivernybroe Actually changing analyzer is nice but if we can really benefit from it (at this moment I couldn't find any specific use case beside one we have). But using error reporting has less trouble and we can use it in such scenarios. So if we can't find another way, we should go with error reporting, unless we can gain much from analyzer change. I appreciate if any of guys has a third option or any opinion on current ones. |
I have no really opinion on this, I follow yoy @olivernybroe, I'm |
@Jibbarth Thanks for the review! Actually I wrote them just for the demo to choose between two options or even a new one. I believe if there is no third option at this point, error reporting is a better way, unless @olivernybroe has a different opinion. |
@50bhan Alright, let's go error reporting Thanks for the amazing research here and examples of how to code will look like. |
@olivernybroe As a recap, for fixing this bug, I just removed "@" to avoid suppressing errors and receive all of them (and avoid hangs on bad codes). Then insight will log the error and pass the file to the fixer and because of bad token, fixer will fail. So I added an empty exception handling block just to avoid failing. Regarding error reporting, because of removing "@", it is not needed unless in testing which I decided to change it. I just tested the file fixer, because second point of failure was there and testing via analyzer was not a choice anymore. P.S. I couldn't find a better way to test the file fixer! Let me know if there's room for improvement. |
@50bhan Sounds cool! Hmm, so I just tried running it locally on the test fixture file and it still gives the infinite recursion result showing these two lines
|
@olivernybroe I added an error handler to "SniffDecorator" to active error reporting and catch fatal errors, then convert the errors to exception so it become catch-able via try/catch block. This is the result after this change:
|
Amazing work @50bhan!
Thanks for spending all this time debugging the error and finding a suitable solution.
Alright, so @50bhan when the tests are fixed, I'll say we are ready to merge this in |
@olivernybroe It's my pleasure! It was a nasty bug |
Last question, promise.
In our phpstan.neon.dist, line 33, we have '#Error suppression via "@" should not be used.#'
As we remove the @
, could we remove this line in phpstan.neon.dist ?
@Jibbarth Nice catch |
@50bhan Sorry, but removing that other one will cause new errors
I have added a test case for you The places where the php warning is happening is |
@olivernybroe So should I put |
@olivernybroe I suggest to put than one back, unless we can catch errors which we couldn't catch already! |
@50bhan Actually adding that back in won't fix it, you would have to add it back in and add it to If you are up for finding a solution then let's do that. If you wanna wait or want this fix rolled out, then let's just make the solution for this other problem in another PR. |
Oops forgot to change my commit message to this branch Oh well, we squash merge anyways |
@olivernybroe Sounds like a plan! Let's make this one work and I will work on other one as well. |
@50bhan Cool! Thanks a lot for the work on this btw, really nice to get the internals cleaned up and more stable. |
@olivernybroe Any time :) Tests are failing because of low code quality?! Any ideas? |
@50bhan I have taken care of it, just waiting for travis and then I'll merge it |
This PR will close issue #322.
Due to suppressing errors with "@", process will hangs without any prompt. With this changes, errors will be considered but user will not see them during process. At the end of process, "insight" report will be contains of occurred errors as parse errors.