Use PsiReference list to determine if "missing" inspections apply

[adrolter]

Instead of using static signature lists to check if the route, service, and template "missing" inspections apply, we can instead check if the element's PsiReference list contains the relevant reference type. This change allows these inspections to operate in the same contexts as auto-completion, such as when the reference was tagged with a PhpDoc hash (e.g., #Route) or configured through the settings panel.

Thanks!

Fixes #2255

[Haehnchen]

:+1:

[adrolter]

Thank you!

[adrolter]

@Haehnchen Looks like this patch is causing a "too many element types registered" issue, as you've also discovered per your revert. Do you have any insight as to why my approach resulted in superfluous registration of IElementTypes? I'm assuming I need to be doing some caching that I'm not, so I'll reimplement properly once I understand where I went wrong.

[Haehnchen]

thank for reaching out, but i would better leave it as it was:

• the many issue looks the removal of the method checks, which filter the possible code triggering
• references are provide an target, which dont needed in inspections, there is just a bool flag needed (which why the code behind is different and optimized)
• it looks like the references are fetched live for each possible char typed, resolving it 100 of times; so lot of hidden external references.

too many element types registered

i dont think its directly related, to this changes. but i still need to check, as i also had problems on daily basis on a project. for now guessing that it was called too often, too frequently for "bigger files". I hade problems writting queryies in repo classes and exception came from template checking. :)

Maybe there were changes in PhpStorm itself on lexer / ast node, in which maybe a route name is resolved to an object and cached, but i found no reproducible way, so i reverted the changes for the next release as a first step.

[adrolter]

Understood, but then what is to be done about the "missing" inspections not recognizing custom references? With this revert my team and I are going to lose all visibility of broken routes in our project, for instance, and I don't know what I'm going to do about that now.

Is it not expected that custom references will be inspected? Are people supposed to know they're making a tradeoff when using custom references that will lead to broken references all over their code over time?

Thanks!

[adrolter]

@Haehnchen not to be a pain, but could you please advise so that I can determine how to proceed? Thank you

[Haehnchen]

@adrolter i will add this in the next release, in the end the "configured reference methods" should be considered. mainly it should just extend the already arraylist.

[adrolter]

I see, that makes sense. I'll hold off updating until the next release, then. Thank you very much!

On Wed, Jan 24, 2024, 10:43 Daniel Espendiller @.***> wrote:

@adrolter https://github.com/adrolter i will add this in the next release, in the end the "configured reference methods" should be considered. mainly it should just extend the already arraylist.

— Reply to this email directly, view it on GitHub https://github.com/Haehnchen/idea-php-symfony2-plugin/pull/2256#issuecomment-1908391479, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBN42WGLZEW2IPK3NK6BTYQETZZAVCNFSM6AAAAABADTD6UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBYGM4TCNBXHE . You are receiving this because you were mentioned.Message ID: @.***>