WIP: Add scanning using symbols

[icanhazstring]

Work in Progress

This will rework how dependencies and usages are handled.
Previously only Namespaces were checked, which doesn't work well for constants or functions that are provided by a dependency but don't have a namespace.

More information see #85

---

How to test:

$ composer require --dev icanhazstring/composer-unused:dev-feature/symbol-scanning

Then run

$ composer unused -x

Current state:

• suggest/provide not implemented in experimental mode
• error handling not working correctly
• should be able to scan psr0/4, classmap and file packages

[icanhazstring]

Goto logic to load symbols from required dependencies:

$rootPackage = $composer->getPackage(); // self
$rootSymbolLoader = new RootSymbolLoader();
$dependencySymbolLoader = new DependencySymbolLoader(...);
$providedSymbols = [];

foreach ($rootPackage->getRequires() as $requiredPackage) {
    $composerPackage = $this->resolvePackage(...); // Create package for extension or find actual installed package
    $providedSymbols[] = $dependencySymbolLoader->load($package); // Get single generator for each dependency
}

$usedSymbols = $rootSymbolLoader->load($rootPackage); // Load add external symbols, ignoring symbols having name rootnamespace

// TODO: compare used against provided

[icanhazstring]

Working example to compare a single Symbol against a required package:

$rootPackage = $composer->getPackage(); // self
//$rootSymbolLoader = new RootSymbolLoader();
$dependencySymbolLoader = new DependencySymbolLoader(
    new FunctionConstantSymbolProvider(
        new SymbolNameParser(
            (new ParserFactory())->create(ParserFactory::ONLY_PHP7),
            new SymbolNodeVisitor()
        ),
        new FileContentProvider()
    ),
    new SymbolLoader()
);

$requiredDependencies = [];

foreach ($rootPackage->getRequires() as $require) {
    $composerPackage = $resolvePackage($require);

    if ($composerPackage === null) {
        continue;
    }

    $requiredDependencies[] = new RequiredDependency(
        $composerPackage,
        (new SymbolList())->addAll(
            $dependencySymbolLoader->load($composerPackage)
        )
    );
}

$usedSymbols = [new Symbol(PackageInterface::class)];

foreach ($requiredDependencies as $requiredDependency) {
    foreach ($usedSymbols as $usedSymbol) {
        if ($requiredDependency->provides($usedSymbol)) {
            $requiredDependency->markUsed();
            continue 2;
        }
    }
}

[icanhazstring]

Current having a problem with nested yield from of simple array. Might be related to php 7.4.6 bug with yield from.

Todo:

• check against 7.4.7
• reduce nesting of generators

[icanhazstring]

TIL: you can't reuse a generator 😅

That was the problem. Using yield from on an already used generator leads to an error. So I currently used iterator_to_array as a quick fix to further implement the symbol scan. Which works fine for now.

[Jean85]

Quick question: do you expect performance decrease from this change?

[icanhazstring]

Hi @Jean85. Good question. For the most part there would be not much difference.

The following steps are done

• check on namespace (psr0/4)
• scan files for symbols

With this in mind, most packages I could find are defining a namespace they provide. Only for special packages that only define a classmap or simply files, they would have more impact.

But I am trying to avoid that impact using generators. So the files will be only parsed when needed.

[icanhazstring]

Also, the current idea is to have an option in place to activate the new behavior for people to try it out. So everything else works as before.

This way I can optimize the new implementation in different scopes.

[icanhazstring]

Noticed another problem that might come up and should be considered:
According to the composer documentation (https://getcomposer.org/doc/04-schema.md#classmap) autoload.classmap can have not only folders but files and folders with wildcards.

So the current implementation on src/Symbol/Loader/FileSymbolLoader.php does not cover all possibilities and should be covered by tests for these cases. One consideration might be to use glob to resolve the files and parse them all. But there might be a problem with glob and phar execution (which I had before)

[icanhazstring]

Merged the current work into 0.8.x dev branch.
I will create some issues that need to be resolved before this feature can go silent live.