Repository navigation
Conversation
Co-Authored-By: Claude
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When pint runs with
--parallel, the workers are started asphp <pint> worker --port ...and none of the parent's ini settings are passed along. Sophp -d memory_limit=1G vendor/bin/pint --parallelonly raises the limit for the parent, and every worker still runs at the default (128M on the official PHP images).That would mostly be a performance problem, except a worker that runs out of memory dies with a fatal on stderr and the parent drops that worker's whole chunk without treating it as an error. The run exits 0 and reports nothing, so
--testpasses in CI with violations in the tree. We ran into this on a project with a 3.3MB data migration, and the pint job had been passing with style violations for a while before anyone noticed. The silent exit 0 is already open upstream as PHP-CS-Fixer/PHP-CS-Fixer#9854. This PR only covers the memory limit not reaching the workers, since that part lives in Pint's own override ofProcessFactory.The fix has
getCommandArgs()inoverrides/Runner/Parallel/ProcessFactory.phpadd-d memory_limit=with the parent'sini_get('memory_limit')value right after the PHP binary. Workers now run with whatever limit the parent was started with. If nobody set one, the workers get the same default they would have had anyway.tests/Unit/Overrides/ProcessFactoryTest.phpsets the limit to 1536M and checks that the worker args come out as-d memory_limit=1536Mright after the binary. Nothing else about how workers are started changes. If no limit was set, or it's-1, the worker just gets the same value it would have picked up from php.ini anyway, so I don't think anything existing would behave differently.The workaround until now has been putting
memory_limit=1024Min an ini file and settingPHP_INI_SCAN_DIR=:<that dir>, since the workers do inherit the environment. That works, but I don't think anyone would expect to need it when they're already passing-d memory_limit.Reproducing
composer.json:generate.php:Before this change it exits 0 and reports nothing. With it, it exits 1 and reports
src/small_with_violation.phpandsrc/large_with_violation.php, which matches the sequential run.