Index framework global helpers loaded outside Composer autoload

[dereuromark]

Problem

Global functions defined in vendor/ are reported as unknown_function when their definition file is loaded by the framework's own bootstrap rather than Composer's files autoload.

CakePHP is the canonical case. Its global aliases (__, h, env, pr, debug, collection, ...) live in vendor/cakephp/cakephp/src/*/functions_global.php. Those files are not listed in autoload_files.php. They are pulled in by the app bootstrap:

// config/bootstrap.php
require CAKE . 'functions.php';   // -> src/functions.php, which require's each */functions_global.php

scan_autoload_files only seeds from autoload_files.php (and follows require_once chains out of those), so the *_global.php siblings are never reached. Every __() call - the single most common helper in a Cake template/controller - resolves to "unknown function".

Measured impact

analyze on a real CakePHP 5 application:

	total findings	unknown_function
before	1332	1002 (968 of them __)
after	346	15

A 74% drop in total findings; the remaining 15 unknown_function are unrelated parse edge cases, not globals.

Fix

For each file already listed in autoload_files.php, also seed any sibling in the same directory whose name ends in _global.php. The existing pipeline then handles the rest: the eager full-parse in preload_autoload_files picks up the function_exists-guarded definitions (depth > 0) that the byte scan skips.

The lookup is anchored to existing autoload entries - one read_dir per unique directory - rather than a blind walk of the vendor tree, so the cost is bounded and proportional to the autoload-files set. Indexing extra global-function files is purely additive (more resolvable symbols), so there is no risk of changing existing resolution.

This is framework-agnostic: any package that ships a <name>_global.php beside an autoloaded helper benefits. CakePHP is just the most prominent example.