From fa132614e09204238d9a95cb61cfe3b852877bdc Mon Sep 17 00:00:00 2001 From: Massimiliano Culpo Date: Thu, 17 Feb 2022 08:50:50 +0100 Subject: [PATCH] ASP-based solver: don't sort when defining variant possible values (#29013) fixes #28260 Since we iterate over different variants from many packages, the variant values may have types which are not comparable, which causes errors at runtime. This is not a real issue though, since we don't need the facts to be ordered. Thus, to avoid needless sorting, the sorted function has been removed and a comment has been added to tip any developer that might need to inspect these clauses for debugging to add back sorting on the first two items only. It's kind of difficult to add a test for this, since the error depends on whether Python sorting algorithm ever needs to compare the third value of a tuple being ordered. --- lib/spack/spack/solver/asp.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/spack/spack/solver/asp.py b/lib/spack/spack/solver/asp.py index 0df83191a4..dfd2111453 100644 --- a/lib/spack/spack/solver/asp.py +++ b/lib/spack/spack/solver/asp.py @@ -1617,8 +1617,9 @@ def define_variant_values(self): """ # Tell the concretizer about possible values from specs we saw in - # spec_clauses() - for pkg, variant, value in sorted(self.variant_values_from_specs): + # spec_clauses(). We might want to order these facts by pkg and name + # if we are debugging. + for pkg, variant, value in self.variant_values_from_specs: self.gen.fact(fn.variant_possible_value(pkg, variant, value)) def _facts_from_concrete_spec(self, spec, possible):