Re: GHC (API?) question: GHC Core for Base libraries

[Shao, Cheng]

Indeed, the boot.sh script is likely what you are looking for. To
compile `base` and retrieve Core for it, you just need to set up an
empty package database, use the Setup.hs script in base to compile it,
and load your plugin via "--ghc-option=.." provided to `Setup
configure`.
On Wed, Dec 5, 2018 at 2:37 AM Bill Hallahan  wrote:
>
> Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is a 
> good example of using a vanilla ghc installation to compile standard 
> libraries like base.
>
> Thanks Cheng, this looks interesting and helpful!  I'm still trying to 
> understand it fully, but it seems like the important pieces for building base 
> are in the boot and Setup scripts?
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks 
> support for the bytecode backend used by TH, plugins, ghci, etc. A base build 
> with a stage 2 compiler should work.
>
> Thanks Brandon.  Is there a recommended/documented way to build base with a 
> stage 2 compiler?  I haven't been able to find anything about this on the 
> wiki.
>
> On Dec 3, 2018, at 11:10 PM, Brandon Allbery  wrote:
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks 
> support for the bytecode backend used by TH, plugins, ghci, etc. A base build 
> with a stage 2 compiler should work.
>
> On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan  
> wrote:
>>
>> Hi,
>>
>> I'm writing a program analyzer that operates on GHC Core.  Currently, I'm 
>> using the GHC API to get Core from .hs files.  I'd like to be able to run 
>> this analysis on the standard libraries that come with GHC, which requires 
>> getting those as Core.
>>
>> Unfortunately, the build process for these libraries is not entirely 
>> straightforward, and relies on a make script.  I eventually came up with the 
>> plan of writing a GHC plugin, which, rather than performing any 
>> optimizations, would simply run the analysis, and then print the results out 
>> to a file.  I was able to write the plugin successfully, and test it on 
>> several files that were not from the base library.
>>
>> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the 
>> make script would call the plugin.  I ended up with the following:
>>
>> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d 
>> -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d 
>> -package hplugin -fplugin HPlugin.Plugin -v
>>
>> The two package databases are to get to (1) the GHC API and (2) the plugin 
>> ("hplugin") itself.  With this I get an error message, which I have not been 
>> able to find a way to resolve:
>>
>> "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O 
>> -Wall  -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i 
>> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build 
>> -ilibraries/ghc-prim/dist-install/build/autogen 
>> -Ilibraries/ghc-prim/dist-install/build 
>> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
>> -optP-include 
>> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h 
>> -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db 
>> /usr/local/lib/ghc-8.0.2/package.conf.d -package-db 
>> /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin 
>> -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts -Wno-trustworthy-safe 
>> -Wno-deprecated-flags -Wnoncanonical-monad-instances  -odir 
>> libraries/ghc-prim/dist-install/build -hidir 
>> libraries/ghc-prim/dist-install/build -stubdir 
>> libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c 
>> libraries/ghc-prim/./GHC/Types.hs -o 
>> libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno 
>> libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
>> : not built for interactive use - can't load plugins 
>> (HPlugin.Plugin)
>> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
>> make: *** [all] Error 2
>>
>> So I'm now wondering (an answer to either of these two questions would be 
>> helpful):
>> (1) Is this a viable path?  That is, is it possible to use a plugin when 
>> building Base?  If so, does anyone know what I might be doing wrong/what 
>> could be causing this error message?
>> (2) Is there some other better/easier way I could get Core representations 
>> of the standard libraries?  I guess, in theory, it must be possible to 
>> compile the standard libraries with the GHC API, but I have no idea 
>> how/where to look to figure out how?
>>
>> Thanks,
>> Bill
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing 

Re: GHC (API?) question: GHC Core for Base libraries

[Brandon Allbery]

It's more complicated than that, because unless your'e just doing some
transient experimentation this will bite you over and over. What you'll
want to do is check the stage during compilation (it should be available as
macros via the CPP extension) and disable the plugin for stage 1. Then (I
think; it's even worse if not...) use the base built during stage 2.

The comlication there being that it may use the stage 1 compiler to build
the stage 2 base. In this case, you probably can't e.g. get this integrated
into ghc, because it has to be possible to get it in stage 1 and ideally
stage 2 (some platforms can't do stage 2 builds yet; ARM at least used to
be in this category, hence e.g. no ghci or TH). Which places limits on what
features can be used in the base package.

On Tue, Dec 4, 2018 at 1:37 PM Bill Hallahan 
wrote:

> Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is
> a good example of using a vanilla ghc installation to compile standard
> libraries like base.
>
> Thanks Cheng, this looks interesting and helpful!  I'm still trying to
> understand it fully, but it seems like the important pieces for building
> base are in the boot and Setup scripts?
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks
> support for the bytecode backend used by TH, plugins, ghci, etc. A base
> build with a stage 2 compiler should work.
>
> Thanks Brandon.  Is there a recommended/documented way to build base with
> a stage 2 compiler?  I haven't been able to find anything about this on the
> wiki.
>
> On Dec 3, 2018, at 11:10 PM, Brandon Allbery  wrote:
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks
> support for the bytecode backend used by TH, plugins, ghci, etc. A base
> build with a stage 2 compiler should work.
>
> On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan 
> wrote:
>
>> Hi,
>>
>> I'm writing a program analyzer that operates on GHC Core.  Currently, I'm
>> using the GHC API to get Core from .hs files.  I'd like to be able to run
>> this analysis on the standard libraries that come with GHC, which requires
>> getting those as Core.
>>
>> Unfortunately, the build process for these libraries is not entirely
>> straightforward, and relies on a make script.  I eventually came up with
>> the plan of writing a GHC plugin, which, rather than performing any
>> optimizations, would simply run the analysis, and then print the results
>> out to a file.  I was able to write the plugin successfully, and test it on
>> several files that were *not* from the base library.
>>
>> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that
>> the make script would call the plugin.  I ended up with the following:
>>
>> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d
>> -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d
>> -package hplugin -fplugin HPlugin.Plugin -v
>>
>> The two package databases are to get to (1) the GHC API and (2) the
>> plugin ("hplugin") itself.  With this I get an error message, which I have
>> not been able to find a way to resolve:
>>
>> "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O
>> -Wall  -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i
>> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build
>> -ilibraries/ghc-prim/dist-install/build/autogen
>> -Ilibraries/ghc-prim/dist-install/build
>> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
>> -optP-include
>> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h
>> -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db
>> /usr/local/lib/ghc-8.0.2/package.conf.d -package-db
>> /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package
>> hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts
>> -Wno-trustworthy-safe -Wno-deprecated-flags
>> -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build
>> -hidir libraries/ghc-prim/dist-install/build -stubdir
>> libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c
>> libraries/ghc-prim/./GHC/Types.hs -o
>> libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno
>> libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
>> : not built for interactive use - can't load plugins
>> (HPlugin.Plugin)
>> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
>> make: *** [all] Error 2
>>
>> So I'm now wondering (an answer to either of these two questions would be
>> helpful):
>> (1) Is this a viable path?  That is, is it possible to use a plugin when
>> building Base?  If so, does anyone know what I might be doing wrong/what
>> could be causing this error message?
>> (2) Is there some other better/easier way I could get Core
>> representations of the standard libraries?  I guess, in theory, it must be
>> possible to compile the standard libraries with the GHC API, but I have no
>> idea how/where to look to figure out how?
>>
>> Thanks,
>> Bill
>> 

Re: GHC (API?) question: GHC Core for Base libraries

[Bill Hallahan]

> Joachim Breitner's veggies(https://github.com/nomeata/veggies 
> ) project is a good example of using a 
> vanilla ghc installation to compile standard libraries like base.
Thanks Cheng, this looks interesting and helpful!  I'm still trying to 
understand it fully, but it seems like the important pieces for building base 
are in the boot and Setup scripts?

> The problem here is that you're using a stage 1 build, and stage 1 lacks 
> support for the bytecode backend used by TH, plugins, ghci, etc. A base build 
> with a stage 2 compiler should work.
Thanks Brandon.  Is there a recommended/documented way to build base with a 
stage 2 compiler?  I haven't been able to find anything about this on the wiki.

> On Dec 3, 2018, at 11:10 PM, Brandon Allbery  wrote:
> 
> The problem here is that you're using a stage 1 build, and stage 1 lacks 
> support for the bytecode backend used by TH, plugins, ghci, etc. A base build 
> with a stage 2 compiler should work.
> 
> On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan  > wrote:
> Hi,
> 
> I'm writing a program analyzer that operates on GHC Core.  Currently, I'm 
> using the GHC API to get Core from .hs files.  I'd like to be able to run 
> this analysis on the standard libraries that come with GHC, which requires 
> getting those as Core.
> 
> Unfortunately, the build process for these libraries is not entirely 
> straightforward, and relies on a make script.  I eventually came up with the 
> plan of writing a GHC plugin, which, rather than performing any 
> optimizations, would simply run the analysis, and then print the results out 
> to a file.  I was able to write the plugin successfully, and test it on 
> several files that were not from the base library.
> 
> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk 
> , so that the make script would call the plugin.  I ended 
> up with the following:
> 
> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d 
> -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d 
> -package hplugin -fplugin HPlugin.Plugin -v
> 
> The two package databases are to get to (1) the GHC API and (2) the plugin 
> ("hplugin") itself.  With this I get an error message, which I have not been 
> able to find a way to resolve:
> 
> "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Wall 
>  -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i 
> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build 
> -ilibraries/ghc-prim/dist-install/build/autogen 
> -Ilibraries/ghc-prim/dist-install/build 
> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
> -optP-include 
> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id 
> rts -this-unit-id ghc-prim -XHaskell2010 -package-db 
> /usr/local/lib/ghc-8.0.2/package.conf.d -package-db 
> /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin 
> -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts -Wno-trustworthy-safe 
> -Wno-deprecated-flags -Wnoncanonical-monad-instances  -odir 
> libraries/ghc-prim/dist-install/build -hidir 
> libraries/ghc-prim/dist-install/build -stubdir 
> libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c 
> libraries/ghc-prim/./GHC/Types.hs -o 
> libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno 
> libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
> : not built for interactive use - can't load plugins 
> (HPlugin.Plugin)
> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
> make: *** [all] Error 2
> 
> So I'm now wondering (an answer to either of these two questions would be 
> helpful):
> (1) Is this a viable path?  That is, is it possible to use a plugin when 
> building Base?  If so, does anyone know what I might be doing wrong/what 
> could be causing this error message?
> (2) Is there some other better/easier way I could get Core representations of 
> the standard libraries?  I guess, in theory, it must be possible to compile 
> the standard libraries with the GHC API, but I have no idea how/where to look 
> to figure out how?
> 
> Thanks,
> Bill
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> 
> 
> 
> --
> brandon s allbery kf8nh
> allber...@gmail.com 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal not updated after rebase?

[My Nguyen]

Thank you so much Richard - it worked! And you are right, I had a `git add -u` 
at some point. This is what happens when I don’t review my changes closely! I 
had no idea I made changes to libraries/Cabal and such.

Anyways, the diff is on Phab again, D5229. Hope to see feedback :)

My


From: Richard Eisenberg 
Sent: Monday, December 3, 2018 9:35 PM
To: My Nguyen
Cc: Krzysztof Gogolewski; ghc-devs@haskell.org
Subject: Re: Cabal not updated after rebase?

Detached HEADs are normal with submodules. (I suppose sentences like that would 
have gotten me executed several centuries ago...)

When I look at 
https://github.com/mynguyenbmc/ghc/compare/93a3f9070d5d69ad6a28fe94d20c54609698...wip/kind-app,
 which is, I believe, the difference between GHC HEAD and your branch, I see 
that the Cabal submodule has changed. I imagine you didn't mean to do this. 
(This has happened to me with an ill-timed `git add -u` while rebasing. Perhaps 
that's what caused the trouble for you, too.)

To fix, you can manually `git checkout abcdefabcdef` each erroneously changed 
submodule to point to the right commit from HEAD. Then, `git add` each 
submodule in the ghc repo (i.e. not inside any submodule) and try again.

I hope this helps!
Richard

On Dec 3, 2018, at 6:27 PM, My Nguyen 
mailto:mnguy...@brynmawr.edu>> wrote:

I did not touch Cabal at all, but somehow `git status` in libraries/Cabal is 
telling me there’s a detached HEAD?

I built GHC with a fresh checkout from github, and it worked. But after 
applying my patch, it doesn’t work anymore.

From: Richard Eisenberg mailto:r...@cs.brynmawr.edu>>
Sent: Monday, December 3, 2018 8:26 PM
To: My Nguyen
Cc: Krzysztof Gogolewski; ghc-devs@haskell.org
Subject: Re: Cabal not updated after rebase?

Did you change the Cabal submodule at all in your work? Maybe it's out of sync 
somehow...

What happens if you build GHC without including your changes? Does it work?

On Dec 3, 2018, at 12:13 PM, My Nguyen 
mailto:mnguy...@brynmawr.edu>> wrote:

Hello,

Thanks for the suggestion. Unfortunately, the problem persists :(!

My


From: Krzysztof Gogolewski 
mailto:krz.gogolew...@gmail.com>>
Sent: Monday, December 3, 2018 2:46 PM
To: My Nguyen
Cc: ghc-devs@haskell.org
Subject: Re: Cabal not updated after rebase?

Hi,

Does `git clean -fdx .` in libraries/Cabal help? git clean doesn't go into 
submodules.

-Krzysztof

On Mon, Dec 3, 2018 at 6:09 PM My Nguyen 
mailto:mnguy...@brynmawr.edu>> wrote:
Hi all,

I've finished quite a big rebase and was trying to rebuild, but it failed with:

ghc-cabal: Encountered missing dependencies:
Cabal ==2.5.*
I then tried applying my patch on a fresh checkout of GHC and found the reason:



libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:error:
   Bad interface file: 
libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Binary.hi
   Something is amiss; requested module  
Cabal-2.4.0.1:Distribution.Compat.Binary differs from name found in the 
interface file Cabal-2.5.0.0:Distribution.Compat.Binary (if these names look 
the same, try again with -dppr-debug)
   |
119 |import Distribution.Compat.Binary   (Binary (..))
   | ^^

libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:120:1:error:
   Bad interface file: 
libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Semigroup.hi
   Something is amiss; requested module  
Cabal-2.4.0.1:Distribution.Compat.Semigroup differs from name found in the 
interface file Cabal-2.5.0.0:Distribution.Compat.Semigroup (if these names look 
the same, try again with -dppr-debug)
   |
120 |import Distribution.Compat.Semigroup (Semigroup (..), gmappend, gmempty)
   | 

libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:141:1:error:
   Bad interface file: 
libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Stack.hi
   Something is amiss; requested module  
Cabal-2.4.0.1:Distribution.Compat.Stack differs from name found in the 
interface file Cabal-2.5.0.0:Distribution.Compat.Stack (if these names look the 
same, try again with -dppr-debug)
   |
141 |import Distribution.Compat.Stack
   | 


I'm sure I did `git module update`; I even `git clean` everything and  `make` 
from fresh but somehow the cabal still isn't updated. Can anyone help me on why 
this is happening and how to fix it?

Thanks so much,
My

Re: Windows test failures

[Roland Senn]

Hi Tamar,
WINDOWS===On Windows I did the following changes before running the
'plugin09' test: 1.) In the compiler (HscMain.hs), just before calling
the plugin function 'parsedPlugin', I set BufferMode of the file stdout
to LineBuffering. 2.) At the same place, I write a message to stdout
with the text "COMPILER About to call plugin parse" and the result of
the buffer-mode query. 3.) In the plugin, in the function parsedPlugin,
I query and print (to stdout) the buffer mode. 4.) I added the heading
PLUGIN to the normal parse message issued by the parsedPlugin function
5.) In the compiler (HscMain.hs) just after returning from the plugin,
I print the line "COMPILER Returning from plugin parse" to stdout. 6.)
In the  plugin function interfaceLoadPlugin' that is called much later,
I flush stdout, and add the heading "PLUGIN".
This gives the following interesting result:
 COMPILER About to call plugin parse: LineBuffering COMPILER Returning
from plugin parse PLUGIN Buffermode: BlockBuffering Nothing PLUGIN
parsePlugin(a,b) PLUGIN interfacePlugin: Prelude ...
The output lines do not appear in the sequence they were produced!!The
plugin doesn't see/inherit the BlockBuffer mode (LineBuffering) set by
the compiler!!
This is a strong indication, that there are two different buffers for
stdout. One in the compiler and another one in the plugin.At the end of
the processing, the buffer in the compiler is automatically flushed,
however the buffer in the plugin never gets flushed!
LINUX=I did a similar test in Linux, however, here I set the buffer
mode to 'Blockmode Nothing' and I didn't do a manual flush in the
plugin. I got the following result:
 COMPILER About to call plugin parse: Buffering mode: BlockBuffering
Nothing PLUGIN Buffering: BlockBuffering Nothing PLUGIN
parsePlugin(a,b) COMPILER Returning from plugin parse PLUGIN
interfacePlugin: Prelude ...
Here the lines are in the same order as they were produced.The setting
of the Buffering mode is inherited by the plugin.
I think, on Linux the compiler and the plugin share the same buffer.
To fix the issue on Windows, the compiler and the plugin should use the
same buffer for stdout.However I don't know whether this is possible /
difficult / easy?What's your opinion?
Many thanks and kind regards   Roland
Here are my changes for Windows in code:
Change in HscMain the line "import System.IO (fixIO)" to "import
System.IO"
Last lines of function HscMain.hs:hscParse'
-- apply parse transformation of pluginslet
applyPluginAction p opts  = parsedResultAction p opts
mod_summaryliftIO $ hSetBuffering stdout
LineBufferingmode <- liftIO $ hGetBuffering
stdoutliftIO $ putStrLn ("COMPILER About to call plugin
parse: " ++ show mode)rsxresult <- withPlugins dflags
applyPluginAction resliftIO $ putStrLn "COMPILER Returning
from plugin parse"return rsxresult
New code for function SourcePlugin.hs:parsedPlugin
parsedPlugin opts _ pm  = do   mode <- liftIO $ hGetBuffering
stdout   liftIO $ putStrLn $ "PLUGIN Buffermode: " ++ show
mode   liftIO $ putStrLn $ "PLUGIN parsePlugin(" ++ intercalate ","
opts ++ ")"   return pm
New code for function SourcePlugin.hs:interfaceLoadPlugin'
interfaceLoadPlugin' :: [CommandLineOption] -> ModIface -> IfM lcl
ModIfaceinterfaceLoadPlugin' _ iface  = do liftIO $ putStrLn $ "PLUGIN
interfacePlugin: "  ++ (showSDocUnsafe $
ppr $ mi_module iface)   liftIO $ hFlush stdout   return iface


Am Dienstag, den 04.12.2018, 00:02 + schrieb Phyx:
> Hi Roland,
> 
> Thanks for looking into these.
> 
> > 
> I looked into the testcases 'plugins09', 'plugins10' and 'plugins11'
> and
>  found the following: GHC-Windows uses BufferMode 'BlockBuffering 
> Nothing', however, GHC-Linux uses 'LineBuffering'. 
> 
> Ah, yes, this isn't technically a Linux vs Windows thing, GHC will
> always default to LineBuffering for terminals and BlockBuffering for
> anything else. The issue is that msys2 terminals have std handles
> that are backed by files instead of pipes. This is an artifact of how
> they try to emulate posix shells, See https://github.com/msys2/msys2/
> wiki/Porting#standard-streams-in-mintty.  
> This means that when GHC runs inside an msys2 program such as bash
> it'll always default to BlockBuffering.
> 
> 
> 
> > 
> I don't know anything about the "Why" and "Where" in the GHC IO
> module on Windows, so I'm unable to come up with a patch. 
> 
> The above said the handles should be getting flushed when the
> finalizers are run, but these aren't 100% guaranteed so if the tests
> rely on this then your solution (to force buffer mode to
> LineBuffering) sounds like perfectly adequate.  Could you put a patch
> up with that?
> 
> My new I/O manager takes a different approach to determine the buffer
> mode, but I still have some kinks to work out before posting it.
> 
> > 
> PS: I can't say anything