Hey!

Thanks for your PR. You are targeting branch "7.2" but it seems your PR description refers to branch "6.4, 7.2".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

I've additionally fixed PHP 8.1 compatibility (readonly on fixture class level, I have this as a default in IDE and just today saw the red underline in files 😉). What's interesting is whyprevious CI run did not run tests on PHP 8.1, andlatest one did 😅.

I feel like the solution that's proposed at the moment is way to much. What if the error is a parse error or anything else that'd better be caught at linting time?

@nicolas-grekas I've been thinking about your question last 2 days and my initial opinion did not change -lint:container is IMHOnot a place for spotting syntax errors. These should be caught in a separate job (php -l or parallel lint), the last moment for it could becache:clear. I thinklint:container should focus only on DI definition and skip all the errors related to initialising services. Ideally it shouldn't initialise them in the first place, but I get that in order to match signature's expected type with other service's type or expression' return type it has to be done. Anyway, I think my fix is valid, as it aligns with the comment that is right there:

If a service from the expression cannot be fetched from the container, we skip the validation.

In our case it's runtime issue, but for other scenarios it can be actually language-level issue - none of them should break the DI linting (maybe flag for this would be a good idea, so you could runlint:container --stop-on-error or something like that).

What about checking the error message and ignoring only the ones we know we want to ignore?
I don't agree with you about linting not being the place to spot parse errors: any opportunity to spot mistakes as early as possible is a win. False-positives are what is bad, and I would care about them one by one.

Up to follow my last suggestion@Wirone?