You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

228 lines
5.9 KiB
PHTML

<?php
/*
* This file is part of Composer.
*
* (c) Nils Adermann <naderman@naderman.de>
* Jordi Boggiano <j.boggiano@seld.be>
*
* For the full copyright and license information, please view the LICENSE
* file that was distributed with this source code.
*/
namespace Composer\DependencyResolver;
/**
* Stores decisions on installing, removing or keeping packages
*
* @author Nils Adermann <naderman@naderman.de>
* @implements \Iterator<array{0: int, 1: mixed}>
*/
class Decisions implements \Iterator, \Countable
{
const DECISION_LITERAL = 0;
const DECISION_REASON = 1;
/** @var Pool */
protected $pool;
/** @var array<int, int> */
protected $decisionMap;
/** @var array<array{0: int, 1: mixed}> */
protected $decisionQueue = array();
public function __construct(Pool $pool)
{
$this->pool = $pool;
$this->decisionMap = array();
}
public function decide($literal, $level, $why)
{
$this->addDecision($literal, $level);
$this->decisionQueue[] = array(
self::DECISION_LITERAL => $literal,
self::DECISION_REASON => $why,
);
}
public function satisfy($literal)
{
$packageId = abs($literal);
return (
$literal > 0 && isset($this->decisionMap[$packageId]) && $this->decisionMap[$packageId] > 0 ||
$literal < 0 && isset($this->decisionMap[$packageId]) && $this->decisionMap[$packageId] < 0
);
}
public function conflict($literal)
{
$packageId = abs($literal);
return (
(isset($this->decisionMap[$packageId]) && $this->decisionMap[$packageId] > 0 && $literal < 0) ||
(isset($this->decisionMap[$packageId]) && $this->decisionMap[$packageId] < 0 && $literal > 0)
);
}
public function decided($literalOrPackageId)
{
return !empty($this->decisionMap[abs($literalOrPackageId)]);
}
public function undecided($literalOrPackageId)
{
return empty($this->decisionMap[abs($literalOrPackageId)]);
}
public function decidedInstall($literalOrPackageId)
{
$packageId = abs($literalOrPackageId);
return isset($this->decisionMap[$packageId]) && $this->decisionMap[$packageId] > 0;
}
public function decisionLevel($literalOrPackageId)
{
$packageId = abs($literalOrPackageId);
if (isset($this->decisionMap[$packageId])) {
return abs($this->decisionMap[$packageId]);
}
return 0;
}
public function decisionRule($literalOrPackageId)
{
$packageId = abs($literalOrPackageId);
foreach ($this->decisionQueue as $i => $decision) {
if ($packageId === abs($decision[self::DECISION_LITERAL])) {
return $decision[self::DECISION_REASON];
}
}
return null;
}
public function atOffset($queueOffset)
{
return $this->decisionQueue[$queueOffset];
}
public function validOffset($queueOffset)
{
return $queueOffset >= 0 && $queueOffset < \count($this->decisionQueue);
}
public function lastReason()
{
return $this->decisionQueue[\count($this->decisionQueue) - 1][self::DECISION_REASON];
}
public function lastLiteral()
{
return $this->decisionQueue[\count($this->decisionQueue) - 1][self::DECISION_LITERAL];
}
public function reset()
{
while ($decision = array_pop($this->decisionQueue)) {
$this->decisionMap[abs($decision[self::DECISION_LITERAL])] = 0;
}
}
public function resetToOffset($offset)
{
while (\count($this->decisionQueue) > $offset + 1) {
$decision = array_pop($this->decisionQueue);
$this->decisionMap[abs($decision[self::DECISION_LITERAL])] = 0;
}
}
public function revertLast()
{
$this->decisionMap[abs($this->lastLiteral())] = 0;
array_pop($this->decisionQueue);
}
#[\ReturnTypeWillChange]
public function count()
{
return \count($this->decisionQueue);
}
#[\ReturnTypeWillChange]
public function rewind()
{
end($this->decisionQueue);
}
#[\ReturnTypeWillChange]
public function current()
{
return current($this->decisionQueue);
}
#[\ReturnTypeWillChange]
public function key()
{
return key($this->decisionQueue);
}
#[\ReturnTypeWillChange]
public function next()
{
prev($this->decisionQueue);
}
#[\ReturnTypeWillChange]
public function valid()
{
return false !== current($this->decisionQueue);
}
public function isEmpty()
{
return \count($this->decisionQueue) === 0;
}
protected function addDecision($literal, $level)
{
$packageId = abs($literal);
$previousDecision = isset($this->decisionMap[$packageId]) ? $this->decisionMap[$packageId] : null;
if ($previousDecision != 0) {
5 years ago
$literalString = $this->pool->literalToPrettyString($literal, array());
$package = $this->pool->literalToPackage($literal);
throw new SolverBugException(
"Trying to decide $literalString on level $level, even though $package was previously decided as ".(int) $previousDecision."."
);
}
if ($literal > 0) {
$this->decisionMap[$packageId] = $level;
} else {
$this->decisionMap[$packageId] = -$level;
}
}
Fix solver problem exceptions with unexpected contradictory "Conclusions" This 5 character fix comes with a solver test as well as a functional installer test essentially verifying the same thing. The solver test is more useful when working on the solver. But the functional test is less likely to be accidentally modified incorrectly during refactoring, as every single package, version and link in the rather complex test scenario is essential, and a modified version of the test may very well still result in a successful installation but no longer verify the bug described below. Background: In commit 451bab1c2cd58e05af6e21639b829408ad023463 from May 19, 2012 I refactored literals from complex objects into pure integers to reduce memory consumption. The absolute value of an integer literal is the id of the package it refers to in the package pool. The sign indicates whether the package should be installed (positive) or removed (negative), So a major part of the refactoring was swapping this call: $literal->getPackageId() For this: abs($literal) Unintentionally in line 554/523 I incorrectly applied this change to the line: $this->literalFromId(-$literal->getPackageId()); It was converted to: -abs($literal); The function literalFromId used to create a new literal object. By using the abs() function this change essentially forces the resulting literal to be negative, while the minus sign previously inverted the literal, so positive into negative and vice versa. This particular line is in a function meant to analyze a conflicting decision during dependency resolution and to draw a conclusion from it, then revert the state of the solver to an earlier position, and attempt to solve the rest of the rules again with this new "learned" conclusion. Because of this bug these conclusions could only ever occur in the negative, e.g. "don't install package X". This is by far the most likely scenario when the solver reaches this particular line, but there are exceptions. If you experienced a solver problem description that contained a statement like "Conclusion: don't install vendor/package 1.2.3" which directly contradicted other statements listed as part of the problem, this could likely have been the cause.
5 years ago
public function toString(Pool $pool = null)
Fix solver problem exceptions with unexpected contradictory "Conclusions" This 5 character fix comes with a solver test as well as a functional installer test essentially verifying the same thing. The solver test is more useful when working on the solver. But the functional test is less likely to be accidentally modified incorrectly during refactoring, as every single package, version and link in the rather complex test scenario is essential, and a modified version of the test may very well still result in a successful installation but no longer verify the bug described below. Background: In commit 451bab1c2cd58e05af6e21639b829408ad023463 from May 19, 2012 I refactored literals from complex objects into pure integers to reduce memory consumption. The absolute value of an integer literal is the id of the package it refers to in the package pool. The sign indicates whether the package should be installed (positive) or removed (negative), So a major part of the refactoring was swapping this call: $literal->getPackageId() For this: abs($literal) Unintentionally in line 554/523 I incorrectly applied this change to the line: $this->literalFromId(-$literal->getPackageId()); It was converted to: -abs($literal); The function literalFromId used to create a new literal object. By using the abs() function this change essentially forces the resulting literal to be negative, while the minus sign previously inverted the literal, so positive into negative and vice versa. This particular line is in a function meant to analyze a conflicting decision during dependency resolution and to draw a conclusion from it, then revert the state of the solver to an earlier position, and attempt to solve the rest of the rules again with this new "learned" conclusion. Because of this bug these conclusions could only ever occur in the negative, e.g. "don't install package X". This is by far the most likely scenario when the solver reaches this particular line, but there are exceptions. If you experienced a solver problem description that contained a statement like "Conclusion: don't install vendor/package 1.2.3" which directly contradicted other statements listed as part of the problem, this could likely have been the cause.
5 years ago
{
$decisionMap = $this->decisionMap;
ksort($decisionMap);
$str = '[';
foreach ($decisionMap as $packageId => $level) {
$str .= (($pool) ? $pool->literalToPackage($packageId) : $packageId).':'.$level.',';
Fix solver problem exceptions with unexpected contradictory "Conclusions" This 5 character fix comes with a solver test as well as a functional installer test essentially verifying the same thing. The solver test is more useful when working on the solver. But the functional test is less likely to be accidentally modified incorrectly during refactoring, as every single package, version and link in the rather complex test scenario is essential, and a modified version of the test may very well still result in a successful installation but no longer verify the bug described below. Background: In commit 451bab1c2cd58e05af6e21639b829408ad023463 from May 19, 2012 I refactored literals from complex objects into pure integers to reduce memory consumption. The absolute value of an integer literal is the id of the package it refers to in the package pool. The sign indicates whether the package should be installed (positive) or removed (negative), So a major part of the refactoring was swapping this call: $literal->getPackageId() For this: abs($literal) Unintentionally in line 554/523 I incorrectly applied this change to the line: $this->literalFromId(-$literal->getPackageId()); It was converted to: -abs($literal); The function literalFromId used to create a new literal object. By using the abs() function this change essentially forces the resulting literal to be negative, while the minus sign previously inverted the literal, so positive into negative and vice versa. This particular line is in a function meant to analyze a conflicting decision during dependency resolution and to draw a conclusion from it, then revert the state of the solver to an earlier position, and attempt to solve the rest of the rules again with this new "learned" conclusion. Because of this bug these conclusions could only ever occur in the negative, e.g. "don't install package X". This is by far the most likely scenario when the solver reaches this particular line, but there are exceptions. If you experienced a solver problem description that contained a statement like "Conclusion: don't install vendor/package 1.2.3" which directly contradicted other statements listed as part of the problem, this could likely have been the cause.
5 years ago
}
$str .= ']';
4 years ago
Fix solver problem exceptions with unexpected contradictory "Conclusions" This 5 character fix comes with a solver test as well as a functional installer test essentially verifying the same thing. The solver test is more useful when working on the solver. But the functional test is less likely to be accidentally modified incorrectly during refactoring, as every single package, version and link in the rather complex test scenario is essential, and a modified version of the test may very well still result in a successful installation but no longer verify the bug described below. Background: In commit 451bab1c2cd58e05af6e21639b829408ad023463 from May 19, 2012 I refactored literals from complex objects into pure integers to reduce memory consumption. The absolute value of an integer literal is the id of the package it refers to in the package pool. The sign indicates whether the package should be installed (positive) or removed (negative), So a major part of the refactoring was swapping this call: $literal->getPackageId() For this: abs($literal) Unintentionally in line 554/523 I incorrectly applied this change to the line: $this->literalFromId(-$literal->getPackageId()); It was converted to: -abs($literal); The function literalFromId used to create a new literal object. By using the abs() function this change essentially forces the resulting literal to be negative, while the minus sign previously inverted the literal, so positive into negative and vice versa. This particular line is in a function meant to analyze a conflicting decision during dependency resolution and to draw a conclusion from it, then revert the state of the solver to an earlier position, and attempt to solve the rest of the rules again with this new "learned" conclusion. Because of this bug these conclusions could only ever occur in the negative, e.g. "don't install package X". This is by far the most likely scenario when the solver reaches this particular line, but there are exceptions. If you experienced a solver problem description that contained a statement like "Conclusion: don't install vendor/package 1.2.3" which directly contradicted other statements listed as part of the problem, this could likely have been the cause.
5 years ago
return $str;
}
public function __toString()
{
return $this->toString();
}
}