Bug report
On the current 2.2.x tip, a Laravel project using larastan dies before analysis starts:
In LarastanStubFilesExtension.php line 25:
Undefined constant "Larastan\Larastan\LARAVEL_VERSION"
larastan defines that constant from its bootstrapFiles entry (vendor/larastan/larastan/bootstrap.php, which boots the application), and its stub files extension reads it. On the tip the project stub files are collected before the bootstrap files have run, so the constant does not exist yet.
Trace (phar built from 2.2.x-dev@9680cc4):
at vendor/larastan/larastan/src/LarastanStubFilesExtension.php:25
Larastan\Larastan\LarastanStubFilesExtension::{closure:getFiles():25}() at vendor/symfony/finder/Iterator/CustomFilterIterator.php:54
...
iterator_to_array() at vendor/larastan/larastan/src/LarastanStubFilesExtension.php:30
Larastan\Larastan\LarastanStubFilesExtension->getFiles() at src/PhpDoc/DefaultStubFilesProvider.php:66
PHPStan\PhpDoc\DefaultStubFilesProvider->getStubFiles() at src/PhpDoc/DefaultStubFilesProvider.php:78
PHPStan\PhpDoc\DefaultStubFilesProvider->getProjectStubFiles() at src/Command/CommandHelper.php:485
PHPStan\Command\CommandHelper::{closure:begin():477}() at src/Command/InceptionResult.php:58
PHPStan\Command\InceptionResult->getFiles() at src/Command/AnalyseCommand.php:209
Red/green
| build |
result |
| 2.2.8 release phar |
analysis runs |
| 2.2.9 release phar |
analysis runs |
2.2.x-dev@9680cc4 |
crash above |
Same project, same config, same larastan 3.x, same command in all three; each run with its own empty tmpDir.
It also crashes with --debug, so it is not limited to the forking path.
Candidate commit (a pointer, not a finding)
55d9d9bcc "Run bootstrapFiles per forked worker instead of inheriting the parent's" is the only change to when bootstrap files run in 2.2.9..9680cc4 — it adds BootstrapFilesRunner and rewrites CommandHelper::begin() (+21/-20). I did not bisect phars, so please treat the attribution as a lead rather than a diagnosis.
Reproduction
Any Laravel application with larastan/larastan ^3.0 and a phpstan.neon that includes vendor/larastan/larastan/extension.neon, analysed with a phar built from the tip. No project code is needed — the crash happens while collecting stub files, before any file is analysed.
I cannot reduce this to a phpstan.dev snippet: it needs a bootstrapFiles entry that defines a constant and a StubFilesExtension that reads it, which is a project-configuration shape rather than an analysed-code shape. If a minimal standalone project (a bootstrap file defining a constant + a tiny extension reading it in getFiles()) would be useful, I am happy to put one together.
Environment
PHP 8.4, Laravel 13.26.1, larastan 3.x, macOS, PHPStan level 5.
Why it seems worth catching now
This is unreleased, so it is catchable before 2.2.10. As it stands, every larastan user would be unable to run PHPStan at all — not a false positive, but a hard stop before analysis.
Found while re-checking whether phpstan/phpstan-src#6265 closes the Laravel half of #15102 for us; that half is a separate report which I am posting on the PR.
Bug report
On the current
2.2.xtip, a Laravel project using larastan dies before analysis starts:larastan defines that constant from its
bootstrapFilesentry (vendor/larastan/larastan/bootstrap.php, which boots the application), and its stub files extension reads it. On the tip the project stub files are collected before the bootstrap files have run, so the constant does not exist yet.Trace (phar built from
2.2.x-dev@9680cc4):Red/green
2.2.x-dev@9680cc4Same project, same config, same larastan 3.x, same command in all three; each run with its own empty
tmpDir.It also crashes with
--debug, so it is not limited to the forking path.Candidate commit (a pointer, not a finding)
55d9d9bcc"Run bootstrapFiles per forked worker instead of inheriting the parent's" is the only change to when bootstrap files run in2.2.9..9680cc4— it addsBootstrapFilesRunnerand rewritesCommandHelper::begin()(+21/-20). I did not bisect phars, so please treat the attribution as a lead rather than a diagnosis.Reproduction
Any Laravel application with
larastan/larastan^3.0 and aphpstan.neonthat includesvendor/larastan/larastan/extension.neon, analysed with a phar built from the tip. No project code is needed — the crash happens while collecting stub files, before any file is analysed.I cannot reduce this to a phpstan.dev snippet: it needs a
bootstrapFilesentry that defines a constant and aStubFilesExtensionthat reads it, which is a project-configuration shape rather than an analysed-code shape. If a minimal standalone project (a bootstrap file defining a constant + a tiny extension reading it ingetFiles()) would be useful, I am happy to put one together.Environment
PHP 8.4, Laravel 13.26.1, larastan 3.x, macOS, PHPStan level 5.
Why it seems worth catching now
This is unreleased, so it is catchable before 2.2.10. As it stands, every larastan user would be unable to run PHPStan at all — not a false positive, but a hard stop before analysis.
Found while re-checking whether phpstan/phpstan-src#6265 closes the Laravel half of #15102 for us; that half is a separate report which I am posting on the PR.