In complex scenarios reasons for learned rules can themselves be learned
rules caused by other learned rules which had the some of the same
reasons. In this situation iterating over all problem rules requires
keeping track of which rules have previously been analyzed to avoid and
endless loop.
Side effect is that the sorting of problems including learned rules
changes slightly.
Locked packages are basically like removable fixed packages, so we still
only load one version, but we do not require their installation unless
something the user needs requires their use. So they automatically get
removed if they are no longer needed on any update.
Instead of marking locked packages as fixed, we change the pool builder
to load only the locked version and treat it like a fixed package, but
removing the actual request fix, makes the solver treat it as a regular
optional dependency. As a consequence locked packages may be removed on
a partial update of another package, but they cannot be updated.
So far the ordering of alias packages with the same name was undefined
so the actual order was determined by implementation of the sorting
algorithm in PHP. As of PHP8 sort is stable by default which changes the
outcome in some of our test cases.
With the fully defined total order the order can longer change depending
on sorting algorithm used and remains the same across PHP versions.
See https://wiki.php.net/rfc/named_params#internal_functions
(implemented but not yet merged)
An ArgumentCountError will be thrown when passing variadic arguments to
a function with call_user_func_array() if extra unknown named arguments
are encountered.
Fatal error: Uncaught ArgumentCountError: array_merge() does not accept unknown named parameters in phar:///path/to/composer.phar/src/Composer/DependencyResolver/DefaultPolicy.php:84
(e.g. for `['phpunit/phpunit' => [72]]`)
Andrés De la Cruz
Nils Adermann
Jordi Boggiano
Bezpiatov
Simon Berger
Markus Staab
Yanick Witschi
Oleg Andreyev
Tyson Andre