Should this really be done as a bug fix? Can't we consider it's a limitation for sure, but that's how it works for now? If you agree, then the cache warmup should be added in the PR on master.

We can also consider it as a undocumented limitation and I can add it as a feature to master. I just find the current behavior kind of weird to be honest. But I don't really mind 😊

Should we usecache.system then for the expression language cache?

Should we use cache.system then for the expression language cache?

a dedicated pool instead, so userland items cannot collide with internals - see egcache.validator

An option for 2.7 could be to keep trying to parse in the extension at compile time, but fallback to runtime parsing (using Expression instead of SerializedParsedExpression) in case of an invalid function being used (as this is the only kind of parse error which can change once registering custom functions). This way, only projects using a custom function in theirallow_if expression would be affected by the slower code path.

An option for 2.7 could be to keep trying to parse in the extension at compile time, but fallback to runtime parsing (using Expression instead of SerializedParsedExpression) in case of an invalid function being used (as this is the only kind of parse error which can change once registering custom functions). This way, only projects using a custom function in their allow_if expression would be affected by the slower code path.

@stof yes I was also thinking about that.

We could catchSyntaxError but this can also mean the expression simply has a wrong syntax 🙈So as a side effect instead of at compile time the error would show up on run-time. But I guess thats not a big problem? => actually that's the case already with my current fix here 😊

@stof@nicolas-grekas I updated it so we keep trying to parse the expression on compile time and we simply fallback to using a raw expression if it fails.

Let me know what you think 😉

I could create a separate PR for master to use a new cache pool + deprecateExpressionVoter::addExpressionLanguageProvider.

Hmm not sure its a big problem. I mean when using the FrameworkExtraBundle@Security annotation with an expression it also appears on run-time for example?

What do you think@stof ?

@nicolas-grekas@stof should I continue to work on this? Or should we close the issue as "won't fix"?

@dmaicher move as new feature on master?

@nicolas-grekas ok 😉 Will prepare a new PR soon for master that

• does not pre-parse expressions anymore at compile-time
• deprecatesExpressionVoter::addExpressionLanguageProvider
• adds a cache pool for the security expression language