[Aster89]

I looked up Tasty's documentation and specifically the Dependencies section, which enlightened me about the existence of dependentTestGroup and similar functions.

With this PR I'm using dependentTestGroup to force seriality between two portions of the tests. The choice of not running them all serially is empirical.

I've manually verified that

ionice nice ghcup run --ghc 9.10.3 -- cabal run -w ghc-9.10.3 func-test -- -j32

passes, despite the -j32 flag.

---

Fixes #5149.

---

• I read and followed our AI policy

[fendor]

Very interesting! If it works 🤷 But it does show us where the issue lies, if these groups running in parallel are the reason for the failure.

[Aster89]

The failures are due to

/home/runner/work/haskell-language-server/haskell-language-server/test/functional/Main.hs:12:28: error: [GHC-88464]
    Variable not in scope:
      dependentTestGroup
        :: t0 -> DependencyType -> [TestTree] -> TestTree
   |
12 | main = defaultTestRunner $ dependentTestGroup "haskell-language-server" AllFinish
   |                            ^^^^^^^^^^^^^^^^^^

In the same log, I read that tasty-1.5.3 is being used, and indeed dependentTestGroup was introduced in tasty-1.5.4 to replace sequentialTestGroup.

I suppose the issue is that stackage-lts23 and stackage-lts24 ship with <= tasty-1.5.3, but I'm relying on a >= tasty-1.5.4 functionality.

I wonder what happens if I enforce a lower bound of 1.5.4 for tasty, as there's currently none in haskell-language-server.cabal.

---

Incidentally, why that ugly spacing???

[fendor]

Incidentally, why that ugly spacing???

That's just the default formatting with stylish-haskell, our formatter for HLS. Is this the first time you are working outside the case-split plugin? :D

The purpose is to align it with qualified, e.g.

import qualified Data.List
import           Data.Set

I wonder what happens if I enforce a lower bound of 1.5.4 for tasty, as there's currently none in haskell-language-server.cabal.

Stack would ignore it (or throw the error earlier), you need to add that version as an extra-dep in the stack.yamls.

[Aster89]

Incidentally, why that ugly spacing???

That's just the default formatting with stylish-haskell, our formatter for HLS. Is this the first time you are working outside the case-split plugin? :D

No, probably it's the first time I run stylish-haskell on a file where there's no import qualified.

The purpose is to align it with qualified, e.g.

import qualified Data.List
import           Data.Set

Yeah, I know that, I just don't understand the preemptive spacing in the event that somebody will add/make an import qualified at some point in the future. It looks ugly.

I would say that suffering the diff of spaces in that event at review time is little cost. (That's the only reason I can see for the current behavior.)

[fendor]

It looks ugly.

The point of this is to keep git diffs small. If you reformatted all imports because one import added qualified, then it would be really annoying. Think of your plugin, where you have about 100 imports. Assume none of them used qualified, but then you add a qualified import. You'd have 100 loc for just a single import. Then you realize you don't want to import it qualified, and have another 100 loc changes.

Also, you get used to it. Best not to think about it too much.

[fendor]

LGTM, thanks!