concretizer: spec_clauses() shouldn't emit node_compiler_hard for rule bodies.

`node_compiler_hard()` means that something explicitly asked for a node's
compiler to be set -- i.e., it's not inherited, it's required. We're
generating this in spec_clauses even for specs in rule bodies, which
results in conditions like this for optional dependencies:

In py-torch/package.py:

    depends_on('llvm-openmp', when='%apple-clang +openmp')

In the generated ASP:

    declared_dependency("py-torch","llvm-openmp","build")
      :- node("py-torch"),
         variant_value("py-torch","openmp","True"),
         node_compiler("py-torch","apple-clang"),
         node_compiler_hard("py-torch","apple-clang"),
         node_compiler_version_satisfies("py-torch","apple-clang",":").

The `node_compiler_hard` there means we would have to *explicitly* set
py-torch's compiler to trigger the llvm-openmp dependency, rather than
just letting it be set by preferences. This is wrong; the dependency
should be there regardless of how the compiler was set.

- [x] remove fn.node_compiler_hard() call from spec_clauses when
      generating rule body clauses.

1 files changed, 0 insertions, 2 deletions

diff --git a/lib/spack/spack/solver/asp.py b/lib/spack/spack/solver/asp.py
index 105d39049e..1f314b8f52 100644
--- a/lib/spack/spack/solver/asp.py
+++ b/lib/spack/spack/solver/asp.py
@@ -1178,8 +1178,6 @@ class SpackSolverSetup(object):
         # compiler and compiler version
         if spec.compiler:
             clauses.append(f.node_compiler(spec.name, spec.compiler.name))
-            clauses.append(
-                fn.node_compiler_hard(spec.name, spec.compiler.name))
 
             if spec.compiler.concrete:
                 clauses.append(f.node_compiler_version(