* PHP 8.1/Tests: fix some deprecation warnings
The default value for the `preg_split()` `$limit` parameter is `-1`, not `null`.
Fixes numerous `preg_split(): Passing null to parameter #3 ($limit) of type int is deprecated` notices when running the test suite.
Ref: https://www.php.net/manual/en/function.preg-split.php
* PHP 8.1/NoProxyPattern: fix deprecation warning
The default value for the `preg_split()` `$limit` parameter is `-1`, not `null`.
Fixes some `preg_split(): Passing null to parameter #3 ($limit) of type int is deprecated` notices when running the test suite.
```
Deprecation triggered by Composer\Test\Util\Http\ProxyManagerTest::testGetProxyForRequest:
preg_split(): Passing null to parameter #3 ($limit) of type int is deprecated
Stack trace:
0 [internal function]: Symfony\Bridge\PhpUnit\DeprecationErrorHandler->handleError(8192, '...', '...', 42)
1 src/Composer/Util/NoProxyPattern.php(42): preg_split('...', '...', NULL, 1)
2 src/Composer/Util/Http/ProxyManager.php(148): Composer\Util\NoProxyPattern->__construct('...')
3 src/Composer/Util/Http/ProxyManager.php(50): Composer\Util\Http\ProxyManager->initProxyData()
4 src/Composer/Util/Http/ProxyManager.php(59): Composer\Util\Http\ProxyManager->__construct()
5 tests/Composer/Test/Util/Http/ProxyManagerTest.php(75): Composer\Util\Http\ProxyManager::getInstance()
...
```
Ref: https://www.php.net/manual/en/function.preg-split.php
* PHP 8.1: fix deprecation warnings / http_build_query()
This fixes all relevant calls to the PHP native `http_build_query()` function.
The second parameter of which is the _optional_ `$numeric_prefix` parameter which expects a `string`.
A parameter being optional, however, does not automatically make it nullable.
As of PHP 8.1, passing `null` to a non-nullable PHP native function will generate a deprecation notice.
In this case, these function calls yielded a `http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated` notice.
Changing the `null` to an empty string fixes this without BC-break.
Fixes a few deprecation warnings found when running the tests.
Refs:
* https://www.php.net/manual/en/function.http-build-query.php
* https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
* PHP 8.1: fix deprecation notices / PharData::__construct()
This fixes all relevant calls to the PHP native `PharData::__construct()` method.
The second parameter of this method is the _optional_ `$flags` parameter which expects an `int` of flags to be passed to the `Phar` parent class `RecursiveDirectoryIterator`.
Fixed by passing the default value for the `$flags` parameter as per the `RecursiveDirectoryIterator::__construct()` method.
The third parameter of the method is the _optional_ `$alias` parameter which expects an `string`.
Fixed by passing an empty string.
Fixes various notices along the lines of:
```
Deprecation triggered by Composer\Test\Package\Archiver\ArchiveManagerTest::testArchiveTar:
PharData::__construct(): Passing null to parameter #2 ($flags) of type int is deprecated
Stack trace:
0 [internal function]: Symfony\Bridge\PhpUnit\DeprecationErrorHandler->handleError(8192, '...', '...', 55)
1 src/Composer/Package/Archiver/PharArchiver.php(55): PharData->__construct('...', NULL, NULL, 2)
2 src/Composer/Package/Archiver/ArchiveManager.php(193): Composer\Package\Archiver\PharArchiver->archive('...', '...', '...', Array, false)
3 tests/Composer/Test/Package/Archiver/ArchiveManagerTest.php(65): Composer\Package\Archiver\ArchiveManager->archive(Object(Composer\Package\CompletePackage), '...', '...')
...
```
Refs:
* https://www.php.net/manual/en/phardata.construct.php
* https://www.php.net/manual/en/recursivedirectoryiterator.construct.php
Co-authored-by: jrfnl <jrfnl@users.noreply.github.com>
The only type of request job remaining was "install" which is really a
root requirement. The only other kind of input for the solver is now a
set of fixed packages.
Rules have been updated to account for only two kinds of former job
reason: FIXED or ROOT_REQUIRE. The job property has always been
redundant and has been removed, since reasonData suffices.
Problem reasons are always rules, so the unnecessary wrapping in an
array has been removed.
We now only ever generate a single rule per root require or fixed
package, so there is no need for the solver to special handle disabling
"jobs" anymore, the rule can just be disabled as usual.
For consistency special handling of rules for jobs in problems has been
integrated into the rule class like all other rule reasons. As part of
this change the error message for root requirements has been improved a
bit to make it clearer where the package installation request came from.
The word job has also been removed from operations, which are called
operations, not jobs.
Jordi Boggiano