Open mpilgrem opened 1 year ago
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)
First identified in https://github.com/commercialhaskell/stack/pull/6161#issuecomment-1596300005, but the move from GHC 9.2.7 to GHC 9.4.5 was not the cause. It was the bump to
msys2-20230526
(https://github.com/commercialhaskell/stack/issues/6153).With
msys2-20221216
, integration tests3926-ghci-with-sublibraries
,4270-files-order
,module-added-multiple-times
behave as expected. Withmsys2-20230526
(or an upgrade of MSYS2), they fail. For example:In summary,
test/integration/lib/StackTest.hs
depends onprocess-1.6.16.0
. FunctionreplCommand :: String -> ReaderT ReplConnection IO ()
feeds commands to GHCi down an input pipe and functionreplGetLine :: 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. (Runningstack 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.