Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it correct to assume that if a class is part of the Symfony container, it's not dead? #92

Open
ruudk opened this issue Sep 14, 2024 · 1 comment

Comments

@ruudk
Copy link

ruudk commented Sep 14, 2024

I'm looking at the SymfonyEntrypointProvider and see that it relies on the ServiceMapFactory from phpstan-symfony. This ServiceMapFactory uses the containerXmlPath to function.

In our Symfony project, we have this XML file disabled, because it took 2 seconds to generate.

Our project fully relies on Autowire. So all files in src as scanned, unless they are explicitly marked with the #[Symfony\Component\DependencyInjection\Attribute\Exclude] attribute.

Let's say we would enable the XML file, and configure it as such, I don't think it will answer the question if the class is used or not. Because most of our unused classes, are autowired.

Maybe I'm overlooking something.

@janedbal
Copy link
Member

janedbal commented Sep 14, 2024

I see your point, but first of all, we do not have "unused class analysis" yet. We only have __construct analysis and that one is definitelly called within your framework. The same assumption is done in VendorEntrypointProvider which marks all overridden methods originating in vendor as used - and that does not need to be true either.

I understand that this is not 100% correct aproach, but at least it allows some decent analysis for some symfony projects. You can always disable those default entrypoint providers and implement some logic yourself. Dead-code analysis is just hard when frameworks come into play :)

If just __construct analysis is not working for you well, you can easily ignore all those errors with single PHPStan ignore regex.

Anyway, thanks for questioning the approach used, we will consider what can be done in future to provide even more precise analysis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants