Feature #96652
open
Reduce amount of weak matches in Extension Scanner
0%
Description
Scenario¶
Just as an example, analyzing ext:bootstrap_package in the Extension Scanner results in a bunch of weak matches concerning calling method ->error - which happens since TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser->error is configured to be reported. Attached screenshot shows a bunch of false-positives (for $this instead of expected TypoScriptParser).
The scope of this issue is to reduce the amount of weak matches that do not consider the proper instance type when invoking methods.
Investigation in using PhpStan¶
It seems to be possible to resolve those symbols and their type with PhpStan (using a custom rule and basically their Scope object), however there are some aspects that make it difficult for the Extension Scanner:
- all used/called classes need to be available or to be stubbed
- this requirement raises memory consumption (had to raise limits to 96M for a single file to be analyzed)
- invoking standalone scans another PHP class seems to be difficult (but somehow still possible)
Investigation in extending current custom PHP Parser¶
In order to keep track of types that are exposed in a particular variable (or class property, or array-dim, or return-type of another function/method call, ...) an own call-graph and scope needs to be maintained. It is just relevant for this feature to fetch the class-type (if any), not the actual value to keep memory consumption low.
In particular the Extension Scanner would first have to scan all symbols, maintain the call-graph and scope and then start analyzing symbols and compare them with corresponding configuration files. That's some work...
General question¶
Concerning potential implications of using another tool, the main question is, whether the Extension Scanner shall stay accessible via Install Tool in browser, or whether that component is supposed to be a development tool that is invoked via CLI only.
Files
Updated by Oliver Hader over 2 years ago
- File 96652_bootstra_package_test.png 96652_bootstra_package_test.png added
- Description updated (diff)
Updated by Oliver Hader over 2 years ago
- File test.neon test.neon added
- File test.php test.php added
- File TestingRule.php TestingRule.php added
Example run with PhpStan 0.12.99 (that's what we have in Core currently)
------ ------------------------------------------------------------------------------------------------ Line test.php ------ ------------------------------------------------------------------------------------------------ 23 Avoid using more than 4 args in TYPO3\CMS\Core\Resource\Rendering\VimeoRenderer->render, got 5 ------ ------------------------------------------------------------------------------------------------
See test.neon, tested subject test.php and corresponding custom rule producing the output above TestingRule.php.
Updated by Oliver Hader over 2 years ago
I just had a call with Lolli concerning PhpStan in general and potential possibilities for the Extensions Scanner and would like to share the outcome:
- keeping the UI interface of Extension Scanner totally makes sense (CLI tools etc. are totally a different story and scope)
- PhpStan is kind of a "black-box" (changes from 0.12.x to 1.x have shown that in terms of API) - this has an implication on using internal
Analysisof PhpStan - which is not public API - using PhpStan in Extension Scanner would move the current dev-dependency to be a 1st level dependency - thus PhpStan would be bundled with every core release - however, we don't want that, I is and shall stay a dev-tool
Conclusion: Corresponding aspects (and only those that are really required) in order to enhance AST nodes would have to be re-implemented for TYPO3 Extension Scanner. This is some work, yes - but it also avoids a hard dependency on PhpStan as a "black-box"...
Updated by Oliver Hader over 2 years ago
- Status changed from New to Accepted
- PHP Version set to 8.1