-
Notifications
You must be signed in to change notification settings - Fork 109
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
Function call depth is higher than 'maxfuncdepth' #125
Comments
Hi, thanks for the report... Do you by any chance have a section of code that causes this we could isolate? Tell me more about the codebase. From the stacktrace itself, it seems it's trying to get the content of a class you are extending for (building a list of all that it extended, all the traits loaded in to it). It's a recursive process (calls itself until it runs out of parent classes). Sine the last element on the stack-trace is not the same method (so not just blindly stuck inside the recursion), not sure what to make of it. Either something funky is going on (most likely), or there's some excessively deep class structures 😅 |
The codebase is a Laravel 5.4 project (on php 5.6... yes, post-EOL is painful) in a private repo. I thought for some reason that To push on the possibility that the complexity of my own interdependent packages were the culprit, I switched to a unit test file with a class directly extending Illuminate\Foundation\Testing\TestCase with no outside references in it and got the same maxfuncdepth behavior when I tried completing from I tried switching to a comparatively simple non-Laravel codebase and found that it would come up with search results, but only from things defined within the current file (not from any of the classes being extended). Could it be that I have something misconfigured? I’m running the latest head of universal-ctags. I’m invoking ctags with this command: Per your comment on issue #112, I checked the output of |
Sounds like somewhere where it tries to find a parent class it ends up looping on itself and re-including the same class over and over again. Could you try switching to this branch and see if it changes anything? I've left in an |
Thank you for your work on this. The good news is that it DOES terminate instead of hanging, but it didn't spit out any file names in the messages; it instead just echoed "0" (zero) 20 different times when trying to complete on a class extending the test class. |
I found where you left |
Ah, I've made a mistake there (string concat is My excuse is that I don't have access to my usual machine at hand (damned borders and international lockdowns 😅). I'll try to get some test environment with laravel testing in place. |
OK, so with that, I can see that it is the traits that are mentioned in the When attempting to complete from a type-hinted class, I got results, but the results were NOT from the type-hinted class. They were, instead, from the file I was in. |
I just noticed some oddities in the search results on the type-hinted class scenario: A perhaps important note about the above scenario is that it did log a trait (albeit from the current class) as a circular load. EDIT: I was mistaken about misattribution—I was looking at the return type. |
I'm getting this error when attempting to trigger completions on objects:
Version of phpcomplete:
ff5b5ef
My Vim build info:
I've rebuilt my tags file several times (I even added the
--output-format=e-ctags
, which I had not done previously).I've tried it with
let g:phpcomplete_parse_docblock_comments = 0
andlet g:phpcomplete_parse_docblock_comments = 1
.I know that the completion has worked for me in the past, so wanted to bring it to your attention.
Thank you for all of your hard work in maintaining this project—I use the jump to definition feature frequently.
If I've left out any relevant details, please let me know.
The text was updated successfully, but these errors were encountered: