TYPO3 Core

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.