Improved diagnostics

[bmewburn]

Diagnostics are currently limited to explicit parse errors reported by bmewburn/php7parser. The diagnostics provider could be improved by providing diagnostics on:

• Incorrect argument types or number of arguments in call expressions.
• Unused symbols
• Undefined variables
• Deprecated warnings 1.3
• Duplicate identifiers
• Unknown classes and methods Feature : Highlight uncertain class definitions #120 Feature Request: Report non existent methods #468 Highlight nonexistent classes or exceptions #474 1.3
• Strict null checking 1.3

[JapSeyz]

Is there anything we can do to help out?

[bmewburn]

@JapSeyz thanks for the offer! You're welcome to create a PR for this or any other issue. I have been meaning to put together a contributing guideline with an overview on how it works. The diagnostics provider is pretty simple right now. It just traverses over the parse tree and creates diagnostics from the parse error nodes in the tree.

There is also 2 derived trees - a symbol (definitions) tree and a references tree. For unused variables and parameters a simple rule might even be that if there is only a single reference to a variable or parameter in a given scope then it is either unused or undefined (a reference is created for the definition/declaration too). I haven't given much thought to how this could all be structured in the diagnostics provider.

[MichalSchwarz]

Hi Guys . Do you think that implement it from scratch is the best solution? I see a insane lot of work ahead... What about find and use some existing static analysis tool? Is possible to connect some tool written eg. in PHP?

[bmewburn]

@MichalSchwarz, you're right it is a lot of work and there are probably other tools out there. The benefit of implementing from scratch is that the syntax tree can be reused. A separate lib would come with it's own parser etc which means more resources needed.

[mindplay-dk]

FWIW, most of the actual inspections in existing static analysis tools are not that complex - typically the framework is the complex part.

@bmewburn in #60:

I haven't done much work on this as I'm considering moving to a representation of the syntax tree that is easier to work with (ast instead of parse tree), plus there are improvements to the type inference to be made in cases where phpdoc and type hints are not available for function return type

I know just enough parser theory to break everything, so I think I'll stay away from this one.

I would like to help with the actual inspections, but if you're planning to change the code representation, it's probably premature to start working on those?

[bmewburn]

@mindplay-dk, correct. The syntax tree representation will be largely the same but I think it needs a transform applied to make accessing FQN and type info simpler.

[Snake231088]

Two ideas from IntelliJ that you might consider:

• highlighting unused variables
• highlighting undeclared variables

[Thijzer]

Give me a sign if you need Guinea pig.

I'm a php developer on Arch Linux, most of my projects are Symfony based OO heavy, so a good working IDE is very important to me but I don't like to really to heavily on one tool "PhpStorm". I'm sure I can help if you can orchestrate something.

[altwohill]

Hi, I see that unused variables are listed as such when hovering over them, but there's nothing drawing me to it (no error shows for the line).

Is this on the roadmap for this ticket or should I create a new one?

[bmewburn]

1.3 will add deprecated, undefined classes and methods/functions, stricter type checking for nullable and union types. Further diagnostics will be added in future releases.