Repository navigation
Conversation
|
You've opened the pull request against the latest branch 2.2.x. PHPStan 2.2 is not going to be released for months. If your code is relevant on 2.1.x and you want it to be released sooner, please rebase your pull request and change its target to 2.1.x. |
|
If you want to have a non-default error formatter and you don't want to execute PHPStan each time with the CLI option, you can use the configuration parameter. The configuration parameter was never meant to be used to query the current error formatter. What is your usecase, why are you interested in it? |
I want to be able to detect used formatter from within DCD. I need to enable some memory-intensive tracking for autoremoval of dead code - and that does not make sense to do for regular executions. Thus, my idea was to check if errorFormat matches ours and we can perform some extra work. |
|
I'm skeptical about this. For one, So it's not really okay to inject it into rules and collectors because the result cache might become stale (except for CollectedDataNode rule but it's brittle and hard to control). Could you instead do the expensive work inside the special "fixing" error formatter altogether? Maybe somehow mark the output of rules and collectors with "hey, this needs some extra work" which could the error formatter pick up and finish before removing dead code? |
Not really or very hardly. The concrete usecase is full removal neverRead property - not just definition, but all remaining writes to be deleted. So during main DCD analysis, I need to collect those and send them thru error.metadata to the formatter. |
The same issue is already there for all parameters not invalidating result cache. The only problem with this one is that it may not hold actual value so it is unreliable. |
bbf6649 to
97ff54e
Compare
The errorFormat DIC parameter was not updated when the --error-format CLI option was used - it always held the config file value (default null). This meant reading the parameter from the container would not reflect the actually-used value. Thread the CLI error format through CommandHelper::begin() and ContainerFactory::create() as a dynamic parameter, so it properly overrides the config file value. Simplify the resolution in AnalyseCommand to just read from the container.
97ff54e to
edf4e22
Compare
|
I feel like we should find another solution for this problem. |
The errorFormat DIC parameter was not updated when the
--error-formatCLI option was used - it always held the config file value (default null). This meant reading the parameter from the container would not reflect the actually-used value.