Support tag for AutowireLocator

[pkly]

Hey, I just noticed in our codebase after disabling tests marking code as used that a bunch of classes implementing interfaces no longer show as used, even though they are.

I traced it back to here

dead-code-detector/src/Provider/SymfonyUsageProvider.php

Line 547 in 021aa21

if (!isset($arguments['services']) || (!isset($arguments['defaultIndexMethod']) && !isset($arguments['defaultPriorityMethod']))) {

This bit doesn't support services by indexes. A combination of tag + indexAttribute (or no indexAttribute) can be used here to search for services with that tag and then mark them as used in terms of methods being used in the class, where the locator pulls out a service and calls on it (presumably an interface method).

We often use something like this

#[AutowireLocator('app.tagged.handler', indexAttribute: 'type')] private readonly ServiceLocator $handlersLocator,

so if this would be supported it'd be great.

[janedbal]

Can you show more specific example of method usage that is not seen by DCD?

[pkly]

Currently having issues with something like this

interface FooBarInterface {
    public function work(): void;
}

class Foo {
    /**
      * @param ServiceLocator<FooBarInterface> $locator
      */
    public function __construct(
        #[AutowireLocator('some.tag', indexAttribute: 'something')] private readonly ServiceLocator $locator
    )

    public function something(): void {
        $this->locator->get('whatever')->work();
    }
}

// assume the class is tagged properly for the time being
class Bar implements FooBarInterface {
    public function work(): void {} // marked as dead code
}

Even though the interface is properly tagged, the service locator works fine in regular use and the container xml is configured via the phpstan-symfony plugin config.

[janedbal]

This example works fine in my reproduction. Can you send minimal failing repo?

[pkly]

I'll try to prepare a reproduction for you on monday.

[pkly]

So, I took a bit of time to look into it, tried to simulate the exact scenario we have and came up with this
https://github.com/pkly/dead-code-detect-repro

However, this also does not report that error.
As I reran phpstan earlier on our main repo suddenly 4 more shipmonk.deadMethod calls were removed.

Regardless of that, I still see the dead code marker in our code.
I added a dump to DeadCodeRule:200 (with $knownCollectedUsages) and noticed that the calls for my interface method interfaceDiscover show up only twice

  5 => ShipMonk\PHPStan\DeadCode\Graph\CollectedUsage {#66128
    -usage: ShipMonk\PHPStan\DeadCode\Graph\ClassMethodUsage {#66127
      -origin: ShipMonk\PHPStan\DeadCode\Graph\UsageOrigin {#66131
        -className: "App\Discoverer"
        -memberName: "discover"
        -memberType: ShipMonk\PHPStan\DeadCode\Enum\MemberType {#11785
          +name: "METHOD"
          +value: 1
        }
        -accessType: ShipMonk\PHPStan\DeadCode\Enum\AccessType {#11790
          +name: "READ"
          +value: 1
        }
        -fileName: "/home/ly/Projects/personal/dead-code-detect-repro/src/Discoverer.php"
        -line: 23
        -provider: null
        -note: null
      }
      -callee: ShipMonk\PHPStan\DeadCode\Graph\ClassMethodRef {#66129
        -className: "App\Interface\DiscoverableInterface"
        -memberName: "interfaceDiscover"
        -possibleDescendant: true
      }
    }
    -excludedBy: null
  }
  20 => ShipMonk\PHPStan\DeadCode\Graph\CollectedUsage {#66058
    -usage: ShipMonk\PHPStan\DeadCode\Graph\ClassMethodUsage {#66070
      -origin: ShipMonk\PHPStan\DeadCode\Graph\UsageOrigin {#66071
        -className: "App\Tests\Discoverable\BasicDiscovererTest"
        -memberName: "testDiscover"
        -memberType: ShipMonk\PHPStan\DeadCode\Enum\MemberType {#11785}
        -accessType: ShipMonk\PHPStan\DeadCode\Enum\AccessType {#11790}
        -fileName: "/home/ly/Projects/personal/dead-code-detect-repro/tests/Discoverable/BasicDiscovererTest.php"
        -line: 14
        -provider: null
        -note: null
      }
      -callee: ShipMonk\PHPStan\DeadCode\Graph\ClassMethodRef {#66057
        -className: "App\Discoverable\BasicDiscoverer"
        -memberName: "interfaceDiscover"
        -possibleDescendant: false
      }
    }
    -excludedBy: "tests"
  }

I'm not sure if this is because you mark all classes that have an interface method as used? (I'm guessing).
I refreshed caches and reran phpstan which got rid of a few things, but this is still returning as not used.

I tried to set it up pretty much the same, with this repo I can't really see the service being marked as having been used?
If possible, please let me know where should I dump some data out that might assist with debugging.

[janedbal]

I can't really see the service being marked as having been used

You can use debug.usageOf to see all usages seen by DCD.

[pkly]

Okay, so I finally had some time to sit down and look at it.

The following is the printout from our debug in phpstan.

Usage debugging information:

App\Interface\DiscoveryHandlerInterface::discover calls
|
| No usages found


App\Handler\DiscoveryHandler::discover calls
|
| Dead because:
| all usages are excluded
|
| Found 2 usages:
|  • tests/Unit/Handler/DiscoveryHandlerTest.php:51 - excluded by tests excluder
|  • tests/Unit/Handler/DiscoveryHandlerTest.php:71 - excluded by tests excluder


App\Manager::discover calls
|
| Marked as alive at:
| entry virtual usage from ShipMonk\PHPStan\DeadCode\Provider\SymfonyUsageProvider (Message handler method via #[AsMessageHandler] attribute)
|   calls App\Processor\DiscoverProcessor::process:48
|     calls App\Manager::discover
|
| Found 2 usages:
|  • src/Processor/DiscoverProcessor.php:48
|  • tests/Unit/ManagerTest.php:76 - excluded by tests excluder

Names slightly redacted, but you get the gist.
The general code looks something like this:

Notification -> processor -> callback -> manager -> handler

As you can see, the discover() method is called and seen (inside of a callback), however it doesn't seem to propagate any lower?

The manager (which you can see being called) has a ServiceLocator<DiscoveryHandlerInterface> parameter in the constructor, which later gets called like so

// body of App\Manager::discover()
        if (!$this->discoveryHandlersLocator->has($source->name)) {
            return;
        }

        $this->discoveryHandlersLocator->get($source->name)
            ->discover($em, $product);

As such, it should propagate lower, but it does not.
We're wrapping the message from DiscoverProcessor in a retryable call from our bundle, which essentially is just a callback. And it does get seen, so, I'm not sure exactly what's happening on the way there.

[janedbal]

What does \PHPStan\dumpType($this->discoveryHandlersLocator->get($source->name)); say?

[pkly]

funnily enough, I added the dumps like so:

// dump
if (!...) {
    return;
}

// dump
$manager->get->discover()

and only the first dump ever displays.

Says

Dumped type: App\Interface\DiscoveryHandlerInterface

Also says: "Service "x" is not registered in the container." (symfonyContainer.serviceNotFound), even though it very much is (seems like PHPStan is seeing the invalid service id, as it's searching for the string we use for the locator, which is not a valid id)

[janedbal]

This is a phpstan-symfony interaction, not a DCD bug. DCD is correctly reporting "no usage" because the call happens in code PHPStan considers unreachable.

  public function discover(...): void
  {
      // ✅ dump #1 shows App\Interface\DiscoveryHandlerInterface — reachable, fine
      if (!$this->discoveryHandlersLocator->has($source->name)) {
          return;                       // <-- PHPStan thinks this ALWAYS runs
      }

      // ❌ dump #2 never prints — this whole block is "unreachable"
      $this->discoveryHandlersLocator->get($source->name)
          ->discover($em, $product);    // <-- so DCD never sees this usage => handler looks dead
  }

You can workaround it by configuring phpstan-symfony not to use hassers:

  parameters:
      symfony:
          constantHassers: false   # stop has() from collapsing to a constant bool

[pkly]

Thanks for letting me know, I suspected as much, but doesn't this seem like a bug in the phpstan-symfony service lookup in that case?

[janedbal]

Maybe. The argument against its behaviour is likely this:

The phpstan-symfony applies its global-container resolution to a ServiceLocator. The extension is registered blanket for Psr\Container\ContainerInterface, so it catches an injected tagged ServiceLocator, then looks the key up in the compiled-container ServiceMap (global service ids) where a locator's local index keys never live → confidently returns false and emits serviceNotFound. The extension is asserting knowledge it can't have about a locator's contents.

But the documented readme part may suggest it is intentional.

---

Feel free to report it. I'm closing this issue now.