[FrameworkBundle] add constraint validators before optimizations

[xabbuh]

Q	A
Branch?	3.4
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#24222
License	MIT
Doc PR

[nicolas-grekas]

I'm not sure, but can that break anything? Like compiler passes that add the tag? Aren't all compiler passes that use hasDefinition "affected" btw - ie decorating their target service breaks them? In which case, shouldn't the solution be inside the pass itself/themselves - eg using has/findDefinition?

Sorry that's a lot of questions, but I'm always suspicious with these kind of changes :)

[xabbuh]

Like compiler passes that add the tag?

That's for sure possible. That would have to be solved by running custom compiler passes with a higher priority. I am afraid there is not much we can do otherwise if we want to solve the linked issue.

Aren't all compiler passes that use hasDefinition "affected" btw - ie decorating their target service breaks them? In which case, shouldn't the solution be inside the pass itself/themselves - eg using has/findDefinition?

That was my initial solution for this (see #24223), but in fact that's not the issue we need to solve here (while I still think we could possibly improve existing compiler passes in such a way).

[nicolas-grekas]

So, this issue can happen with any pass, isn't it?
I'm not sure that potentially breaking fine working apps to support a new use case is legit.
What alternatives do we have? Marking this as unsupported would be fine to me also if there is none.
WDYT?

[xabbuh]

Not really, because all (if I didn't miss any) our other compiler passes dealing with tags are already registered at the before optimization stage so decorating them works just fine.

IMO this is not a new use case. Decorating used to work fine in the past until we accidentally broke that by moving the compiler pass.

[nicolas-grekas]

OK, let's do this, #20116 contains no details anyway...

[fabpot]

Thank you @xabbuh.