testsuite combines HOST with TARGET for 'req_smp' flag

This issue is only to log the problem before I issue a patch based on this wip branch.

While working on !9552 I was trying to fix 6 unexpected passes on tests:

Unexpected passes:
   /builds/ghc/ghc/tmp/ghctest-kd7w1_5t/test   spaces/testsuite/tests/codeGen/should_run/T10414.run          T10414 [unexpected] (threaded2)
   /builds/ghc/ghc/tmp/ghctest-kd7w1_5t/test   spaces/libraries/base/tests/T11760.run                        T11760 [unexpected] (normal)
   /builds/ghc/ghc/tmp/ghctest-kd7w1_5t/test   spaces/testsuite/tests/typecheck/should_fail/T12035j.run      T12035j [unexpected] (normal)
   /builds/ghc/ghc/tmp/ghctest-kd7w1_5t/test   spaces/testsuite/tests/driver/T14075/T14075.run               T14075 [unexpected] (normal)
   /builds/ghc/ghc/tmp/ghctest-kd7w1_5t/test   spaces/testsuite/tests/driver/T20030/test1/T20030_test1j.run  T20030_test1j [unexpected] (normal)
   /builds/ghc/ghc/tmp/ghctest-kd7w1_5t/test   spaces/testsuite/tests/driver/t22391/t22391j.run              t22391j [unexpected] (normal)

what was peculiar about these tests is that each of them pass req_smp to the testsuite driver. But the JS backend doesn't support smp so why are they unexpectedly passing and why are they even being run, especially when the config for the JS backend explicitly says "hey I don't support smp".

Why they are being run

We do pass ghc_with_smp=False to the testsuite:

/nix/store/sz0j8k8ljh7y8qgyfxgqb3ws11bcy4gs-python3-3.10.6/bin/python testsuite/driver/runtests.py --rootdir=testsuite/tests --
... ghc_with_smp=False ... -e config.in_tree_compiler=True 

Then, in the testsuite config we have:

if ghc_with_threaded_rts:
    config.run_ways.append('threaded1')
    if ghc_with_smp:
        config.have_smp = True
        config.run_ways.append('threaded2')
        if config.speed == 0:
            config.run_ways.append('nonmoving_thr')
            config.run_ways.append('nonmoving_thr_sanity')

which sets config.have_smp because of these setting in hadrian:

-- | Does the target support threaded RTS?
targetSupportsThreadedRts :: Action Bool
targetSupportsThreadedRts = do
    bad_arch <- anyTargetArch [ "wasm32", "js" ]
    return $ not bad_arch

-- | Does the target support the -N RTS flag?
targetSupportsSMP :: Action Bool
targetSupportsSMP = do
  unreg <- flag GhcUnregisterised
  armVer <- targetArmVersion
  goodArch <- anyTargetArch ["i386"
                            , "x86_64"
                            , "powerpc"
                            , "powerpc64"
                            , "powerpc64le"
                            , "arm"
                            , "aarch64"
                            , "s390x"
                            , "riscv64"
                            , "loongarch64"]
  if   -- The THREADED_RTS requires `BaseReg` to be in a register and the
       -- Unregisterised mode doesn't allow that.
     | unreg                -> return False
       -- We don't support load/store barriers pre-ARMv7. See #10433.
     | Just ver <- armVer
     , ver < ARMv7          -> return False
     | goodArch             -> return True
     | otherwise            -> return False

Notice that the wasm and JS backend support threaded but not smp. So config.have_smp will be False, which means that req_smp will expect a failure:

def req_smp( name, opts ):
    if not config.have_smp:
        opts.expect = 'fail'

But! Will still run the test.

So Why are they passing

But what doesn't make sense is that these tests are passing, so how are they possibly passing? They are passing because the JS stage1 compiler is linked with the stage0 rts, it is a haskell program after all. So req_smp has to differentiate between when the HOST supports smp (which the HOST does for the JS backend) and when the TARGET supports smp (which the TARGET doesn't) to avoid running the test at all.

The fix is to patch req_smp and the requisite parts of hadrian.