Move from `msys2-20221216` to `msys2-20230526` adversely affects some tests

[mpilgrem]

First identified in #6161 (comment), but the move from GHC 9.2.7 to GHC 9.4.5 was not the cause. It was the bump to msys2-20230526 (#6153).

With msys2-20221216, integration tests 3926-ghci-with-sublibraries, 4270-files-order, module-added-multiple-times behave as expected. With msys2-20230526 (or an upgrade of MSYS2), they fail. For example:

Running: D:\a\stack\stack\_release\bin\stack-2.12.0-windows-x86_64\stack.exe repl
Main.hs: Main module didn't load correctly.
Expected: Hello World!
Actual  : Leaving GHCi.

CallStack (from HasCallStack):
  error, called at D:\\\\a\stack\stack\test\integration\tests\module-added-multiple-times\Main.hs:11:7 in main:Main

In summary, test/integration/lib/StackTest.hs depends on process-1.6.16.0. Function replCommand :: String -> ReaderT ReplConnection IO () feeds commands to GHCi down an input pipe and function replGetLine :: ReaderT ReplConnection IO String captures GHCi’s output from a standard output pipe. What seems to now be happening is that GHCi is behaving as if it has received EOF before receiving any commands and quitting, gracefully, with its usual Leaving GHCi. (Running stack repl locally with the test files suggests that nothing untoward is happening with the actual tests.) That is, it is like GHCi on Windows used to wait for command input in these tests, and now it quits before the input turns up.

[mpilgrem]

It seems to be the core system upgrade that triggers the change in behaviour:

mintty-1~3.6.4-1-x86_64         Terminal emulator with native Windows look and feel (from 1~3.6.2-1)
filesystem-2023.02.07-1-x86_64  Base filesystem (from 2022.01-7)
bash-5.2.015-1-x86_64           The GNU Bourne Again shell (from 5.2.009-1)
pacman-6.0.2-6-x86_64           A library-based package manager with dependency support (MSYS2 port) (from 6.0.1-25)
msys2-runtime-3.4.7-1-x86_64    Posix emulation engine for Windows (from 3.3.6-6)

[ulidtko]

Hi @mpilgrem, I've been looking at this, and got some ideas.

In more holistic context, I keep a few improvements to stack repl in mind — and starting from a cleanup of repl tests, that gets them in order & trivially extendable, seems like a good first step.

Does that sound okay? I just want to declare the intent, and make sure there're no conflicting plans, nor parallel work that I'll interfere with (specifically on repl tests). There isn't that much code about it in stack really, but I'm thinking that whole area could use an overhaul. It might likely end up being somewhat disruptive in terms of git conflicts.

I checked the CI briefly, because I don't have ready access to a well-maintained windows build-server; and IMO the windows jobs running the tests, should suffice for me to make progress here.

[mpilgrem]

@ulidtko, thanks for being interested in the code base. I think there is no major conflict in your plans and anything else going on.

(I do have some current plans to refactor part of Stack.Ghci: (a) to follow the pattern elsewhere that puts the command line options type into its own module and (b) to move the functionality that yields the options that Stack passes to GHC into its own module (as that may end up being common to something to improve HLS support for Stack). However, that is all relatively straightforward and discrete.

EDIT: Item (a) and some other improvements now are in the master branch:

• 93f258e
• 22c5c66

Item (b) can be followed at this pull request:

• Re #6154 Add Stack's ide ghc-options command #6735
  )