Feature #96652
Updated by Oliver Hader almost 3 years ago
h2. h3. 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\Resource\Rendering\VimeoRenderer->render@ is "configured to be reported":https://github.com/TYPO3/typo3/blob/50d4e2c3c969d1951e88328a9f08e53913d52a07/typo3/sysext/install/Configuration/ExtensionScanner/Php/MethodArgumentDroppedMatcher.php#L390-L395. 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. h2. h3. 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 * invoking standalone scans another PHP class seems to be difficult (but somehow still possible) h2. h3. 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... --- !96652_bootstra_package_test.png!