Date native functions and methods by the versioned callmaps

[danog]

Stacked on #12010 (version guards); the first commit is #12010. Builds on #12006 (merged).

With #12010, guarded uses are not reported, e.g. PHP_VERSION_ID >= 80000 ? fdiv(...) : ..., if (PHP_VERSION_ID < 80300) { return new ReflectionMethod($m); } return ReflectionMethod::createFromMethodName($m);, function_exists()/method_exists().

Summary

The callmaps are versioned (dictionaries/CallMap_70.php … CallMap_85.php). A native function or method without a stub @since is now dated by the first callmap it appears in, and reported when used below that version. On 6.x these are silently accepted at phpVersion="7.4", because Psalm resolves them through the reflection of the PHP it runs on:

Symbol	Introduced in
str_contains(), fdiv()	8.0
array_is_list()	8.1
array_find()	8.4
array_first()	8.5
ReflectionClass::isEnum()	8.1

Filtering extension noise

The callmaps are generated with PECL extensions installed, and those extensions' versions are unrelated to the PHP version. For example, hundreds of Swoole, Redis, MongoDB, uv, ds and ssh2 keys "first appear" at arbitrary PHP versions. So only extensions bundled with PHP are dated, and a bundled extension reports PHP_VERSION as its own version. These symbols are reachable only through the runtime's reflection anyway, so the runtime answers that question.

The version is the first appearance across all callmaps, not the next one after the analysed version. That way the few keys with gaps in the generated maps don't produce false positives.

Cost

A first-appearance index (about 25k keys) is built once, lazily. That only happens the first time a native symbol from a bundled extension is missing from the analysed version's callmap. Each callmap takes about 14 ms to load.

Polyfills

• function_exists('x') in a conditional now evaluates against the analysed version when x is dated by the callmaps. Before, a runtime-native function made Psalm skip the body of if (!function_exists('str_contains')) { function str_contains(…) }, so symfony/polyfill and project polyfills were never scanned.
• A project polyfill of such a function is no longer a DuplicateFunction ("already defined as a core function").
• A function declared in any scanned PHP file (project or autoloaded, not a stub) counts as available. The native stub or reflection storage takes precedence over that declaration, so the scanned files are asked directly, and only on the report path.

Checked on scratch projects at 7.4:

• with symfony/polyfill-php80: nothing is reported for str_contains/str_starts_with, while array_is_list (8.1) is
• a project fdiv polyfill in one file, used from others: no reports, with 1 or 4 threads

Known gaps

• Classes are not dated this way. The callmaps list methods, not classes; new classes are covered by the @since stubs in Load genuinely-new native classes on every PHP version, tagged with @since #12008.
• Psalm also registers the autoload files of its own dependencies, so anything they polyfill counts as available, e.g. array_find via symfony/polyfill-php84. This errs towards not reporting.

🤖 Generated with Claude Code

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit fcb47be. Configure here.}

[cursor]

Polyfill merge ignores analysis version

Medium Severity

In ClassLikeStorageProvider::addMore, $is_polyfill treats any user-defined class as replacing a versioned native stub whenever the stub has since_php_version_id, without comparing analysis_php_version_id to that version. The inline scanner only allows that replacement below the introduced version, so parallel scan merges can overwrite the native stub at the analysed version or newer and skip DuplicateClass.

 

^{Reviewed by Cursor Bugbot for commit fcb47be. Configure here.}