Fix cached results surviving a change of --autoload-file#8034
Conversation
A different extra autoload changes what PHPStan can resolve, so cached results must not survive it. Repro: run without -a (helper functions unresolvable, files cached clean), then run with -a — the fresh inference suggestions stay hidden until --clear-cache. The configuration hash already includes the parameter bag, so registering the resolved autoload file path there at boot is enough. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
LGTM 👍 |
| // ArgvInput handles both "--autoload-file path" and "--autoload-file=path" | ||
| $autoloadFileOption = (new ArgvInput())->getParameterOption(['--autoload-file', '-a'], null); | ||
| if (is_string($autoloadFileOption) && $autoloadFileOption !== '') { | ||
| SimpleParameterProvider::setParameter(Option::AUTOLOAD_FILE, realpath($autoloadFileOption) ?: $autoloadFileOption); |
There was a problem hiding this comment.
Just curious, where is this Option::AUTOLOAD_FILE parameter used later?
There was a problem hiding this comment.
Nowhere directly — it only feeds SimpleParameterProvider::hash(), which FileHashComputer folds into the configuration hash. So a different -a changes that hash and the cache clears at boot, same as editing rector.php.
There was a problem hiding this comment.
Got it 👍
Btw, feels like I'm talking to chatbot, it's very hard to process these long responses.
Lots of unnecessary clutter, unrelated methods, links to decipher. Human response would be better :D
There was a problem hiding this comment.
Fair enough, will slow down a bit with the AI replies, although Fable 5 is quite trigger happy with these, more so than previous models, now need to actually instruct it NOT to do it where in the past you have to tell it to do it explicitly
There was a problem hiding this comment.
I know, but we're not :D I don't want to turn this codebase into an AI slop. So far it costs more attention than it brings value.
|
Where is the |
|
@SanderMuller this AI generated PR and description make us harder to verify, as you mentioned something that never exists in rector code base: 
which means that exactly the hallucination. We need contributor that actually understand and can explain the issue cleanly as a human, understand the flow and has effort to fix the notice feedback as a human. That will help us (maintainer) to review. |
|
Sorry, that one is on me. I pushed the class + tests at 09:09, two minutes after the merge, and updated the description without noticing it had already merged. So the class is real, just badly timed — it is in #8035 now. Fair point on the long AI-flavored responses. I will keep PRs and comments shorter. |
…8035) Follow-up to #8034, which merged before its last revision: the parameter registration moves from inline bin code into a unit-testable class. Tests pin that every CLI spelling (--autoload-file path, --autoload-file=path, -a path) resolves to the same real path, that the parameter stays untouched without the flag, and that registering it changes FileHashComputer's configuration hash. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
3 participants
Problem
--autoload-filechanges what PHPStan can resolve, but it lives only in CLI input — unlikewithBootstrapFiles()/withAutoloadPaths()it never reaches the configuration hash. So cached results survive it:rector process --dry-runwithout-aon a project whose helper functions live in an extra autoload → the helpers are unresolvable, files get cached as unchangedrector process --dry-run -a vendor/autoload.php→ PHPStan can now infer through the helpers, a fresh run reports new suggestions — but the warm run reports[OK] Rector is done!until--clear-cacheFix
bin/rector.phpalready reads the option at boot (to load the file early); now it also registers the resolved path as a parameter there, before the configuration hash is computed — andFileHashComputeralready includes the parameter bag in that hash, so a changed-ainvalidates the cache like any config change.ArgvInput::getParameterOption()handles all spellings (--autoload-file path,--autoload-file=path,-a path), andrealpath()normalization keeps the hash identical across them — verified: switching spellings or repeating the flag does not re-invalidate, and parallel workers (which receive the space-separated form) compute the same hash as the main process.The resolution lives in
AutoloadFileParameterResolverso it is unit-testable: every spelling resolves to the same real path, no flag leaves the parameter untouched, and the resolved file changesFileHashComputer's configuration hash.🤖 Generated with Claude Code