If you're going to optimize this, please switch it to a prepopulated hash table.

A nice solution might be to include this information as a flag in zend_func_info, which is generated from stubs.

bin2hex hex2bin strlen mb_strlen would be good here as well, maybe also preg_match preg_replace

bin2hex/hex2bin are done, strlen is already optimized to an opcode rather than a function call, and mb_strlen can't be done because it depends on ini settings that can change at runtime

The encoding parameter is the character encoding. If it is omitted or null, the internal character encoding value will be used.

preg_replace - I've avoided that because of https://www.regular-expressions.info/catastrophic.html potentially taking exponential time in the worst case, and bugs that have been seen in the past with PCRE's jit on different platforms, though maybe that isn't a problem in practice for compiling source code

preg_match - same, also has a reference parameter

A nice solution might be to include this information as a flag in zend_func_info, which is generated from stubs.

I'd considered doing that but didn't know if there were reasons that this wasn't already done - though, until the recent refactoring by @nikic it wouldn't even have been possible to catch notices/exceptions during compilation

This would enable PECLs to start using this, which would be convenient if done properly.

I also had a question on when it's safe to do this for floating-point math. Do we assume that rounding modes don't change (or does that not apply for pow)? I see "pow" is already added, but would "log", "exp", "pi", etc. be reasonable to add (not really common to need, but now it has no cost to add)

• More functions should be added in subsequent PRs instead to be easier to finish reviewing this

A nice solution might be to include this information as a flag in zend_func_info, which is generated from stubs.

Done, the build is passing except for a spurious travis failure. This is ready for review.

I also had a question on when it's safe to do this for floating-point math. Do we assume that rounding modes don't change (or does that not apply for pow)?

Never mind, I see Zend/zend_float.c has ensured that for a really long time, in zend_init_fpu - as of https://wiki.php.net/rfc/rounding

I was thinking of float-to-string conversion historically not being done in opcache until php 8.0, for https://wiki.php.net/rfc/locale_independent_float_to_string

will this change have an relevant impact on how long files need to compile?
in the CLI where we don't use opcache in the regular case, might this be an issue?

will this change have an relevant impact on how long files need to compile?

It should be a tiny bit faster, I'd expect, with no longer having a long chain of string comparisons when compiling functions that have constant operands.

PHP is already evaluating the most commonly used functions at compile-time. Apart from the new case-insensitive string functions (strtolower, strtoupper, strcasecmp, etc) any new functions added here are less commonly used.

This also only affects compilation of calls that have constant operands - if the operands are not inferrable as constants at compile time then this code path doesn't get called.

opcache.file_cache is an option if CLI compilation time is a concern.

in the CLI where we don't use opcache in the regular case, might this be an issue?

If opcache.enable_cli isn't enabled or opcache isn't loaded, this has no impact, it isn't called.

Also, in the interactive CLI (php -a) the optimizer isn't used, same as eval, though the required files would have opcache get used

@kocsismate fyi

Thanks for the ping (I already had a quick look at the PR before), and I liked it very much :)

A question has just came to my mind though: wouldn't it make more sense to use a more general name for the annotation, like @pure, just like what static analysis tools use? As far as I can understand, pure functions can be evaluated at compile time (- slow ones according to your definition in the comments). However, I'm fine with @compile-time-eval as well :)

UPDATE: I've just realized that @pure is probably not a good idea, since you cannot evaluate every pure function at compile time.

A question has just came to my mind though: wouldn't it make more sense to use a more general name for the annotation, like @pure, just like what static analysis tools use? As far as I can understand, pure functions can be evaluated at compile time (- slow ones according to your definition in the comments). However, I'm fine with @compile-time-eval as well :)

UPDATE: I've just realized that @pure is probably not a good idea, since you cannot evaluate every pure function at compile time.

I agree, I'd avoided that name for that reason (functions may be too slow, use up too much memory, infinitely loop, etc).

That name would also make the use of @pure in stubs differ from userland phpdoc (e.g. for stubs for IDEs/analyzers), if phpdoc were to ever add @pure as a standard annotation and make it more likely PECL developers would use it in a place where it would be unsafe.

src/Psalm/DocComment.php
34:        'generator-return', 'ignore-falsable-return', 'variadic', 'pure',