What about instead of removing the type support adding support for adding a priority within a type? In my opinion, being able to choose the compiler pass type makes it much easier to determine when a compiler pass will be executed than it would be when there were only priorities (and some things even could not fully be accomplished when using only priorities).

Well that's still possible@xabbuh but only through the class constants.

But technically I would now only be able to add 100 compiler passes per type (after that priorities cannot be distinguished).

Well, this PR does not bring a solution... it just basically rename the key. As@xabbuh has proposed, I think it would be better to have a notion a priority inside each types, which would be sorted out before the big merge.

Well you could add more than 100 passes per type (a type corresponds to a priority which is not incremented) the only restriction is that you have only 99 differents priorities available between each type for doing whatever you want but that's the same thing for event listeners.
And your solution@Taluu won't respect bc.

I think this idea has been proposed in the past and rejected. Basically, I don't like to give too much flexibility here. People should not rely on precise ordering within one pass. Adding new passes where it makes sense seems better and could be considered if we have enough real-world use cases.

@fabpot I've searched PRs solving the same issue but I only found#10778 which propose a different approach which doesn't solve all issues.
A typical use case is when a bundle uses a compiler pass to change the attributes of a definition. If another bundle needs to access this definition attributes before the container optimization, it isn't able to be sure which version of the definition it has.

Even the core depends on the compiler passes ordering : would symfony still work if we shuffledthis array ?

I also dig into this issue in#13609 for the exact same use case @Ener-Getick describes.

Did you take a decision about this ?

BTW the build fail is unrelated.

I've been thinking how to improve this PR and I finally agree with@xabbuh and@Taluu that this could be confusing to replace the types by a priority system.
So instead I added a new$priority attribute which is completely BC as they proposed.

@fabpot are you still against this change?
As an example, I often see this kind of code:

publicfunctionbuild(ContainerBuilder$container) {$passConfig =$container->getCompilerPassConfig();$passes =$passConfig->getBeforeOptimizationPasses();// This allows to be certain that your pass will be executed before a pass// located in a third party bundlearray_unshift($passes,newMyPass());$passConfig->setBeforeOptimizationPasses($passes);}

This could be simplified with this PR to:

publicfunctionbuild(ContainerBuilder$container) {$container->addCompilerPass(newMyPass(), PassConfig::TYPE_BEFORE_OPTIMIZATION,50);}

I'd love to see this merged.
Is the repository still in a feature freeze ? or is it possible to decide whether or not to merge this ?

Adding a priority like done here looks good to me.

@fabpot I'll add some tests then :)

BTW maybe we will have to deprecate theset* functions now ?
They were useful to put a pass before the built-in ones but now I don't know if we should keep them. If we keep them, we should then decide if it should be possible to define priorities or if the passes should always be added with a priority of 0 as done for now.

I would indeed deprecate the set* methods.

@fabpot it looks like these methods are often used in tests to remove the default passes and have a non altered/fast container.

What do you think about moving them to another class such as theCompiler or theContainerBuilder ?

I think if we really want to deprecate theset* methods we should probably do that later in another PR as we need to find a cleaner substitute which is out of the scope of this PR

Thank you @Ener-Getick.

Great feature. Just needed it :) Thank you@GuilhemN