Remove indentation for error output

[wraithm]

Closes #5430

Indenting the error output of builds makes it so that emacs and vim cannot detect and track errors in the output.

I tested this by running this version of stack inside of my emacs and building a project that produces errors. I confirmed that compilation-mode works with --no-interleaved-output turned on.

[chrisdone]

Makes sense to me.

[wraithm]

@snoyberg What do you think?

[snoyberg]

Do you have a comparison of how this affects output in the interleaved output case?

[wraithm]

@snoyberg I created this repo to demonstrate the effects of this PR: https://github.com/wraithm/5523-stack-test

The big difference is that emacs/vim can capture the results of the second output and track the errors, but not the first.

Two packages, one with an error in it. The new version doesn't prepend whitespace to the error output. Here are the results with the two different versions of stack:

Old version of stack

$ stack --version
Version 2.5.1, Git revision d6ab861544918185236cf826cb2028abb266d6d5 x86_64 hpack-0.33.0
$ stack build --no-interleaved-output
Building all executables for `bad' once. After a successful build of all of them, only specified executables will be rebuilt.
bad> configure (exe)
bad> build (exe)
Log files have been written to: /path/to/5523-stack-test/.stack-work/logs/

--  While building package bad-0.1.0 (scroll up to its section to see the error) using:
      /home/user/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.4 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0 build exe:bad --ghc-options ""
    Process exited with code: ExitFailure 1
    Logs have been written to: /path/to/5523-stack-test/.stack-work/logs/bad-0.1.0.log

    Configuring bad-0.1.0...
    Preprocessing executable 'bad' for bad-0.1.0..
    Building executable 'bad' for bad-0.1.0..
    [1 of 2] Compiling Main

    /path/to/5523-stack-test/bad/Main.hs:4:47: error:
        lexical error in string/character literal at character '\n'
      |
    4 | main = putStrLn "This is a blatant parse error
      |                                               ^

New version of stack

$ ../stack/stack --version
Version 2.6.0, Git revision 21223c306df528f75e769d1eef5ed4bf8d916129 (8305 commits) PRE-RELEASE x86_64 hpack-0.33.0
$ ../stack/stack build --no-interleaved-output
Building all executables for `bad' once. After a successful build of all of them, only specified executables will be rebuilt.
bad> configure (exe)
bad> build (exe)
Log files have been written to: /path/to/5523-stack-test/.stack-work/logs/

--  While building package bad-0.1.0 (scroll up to its section to see the error) using:
      /home/user/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.4 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0 build exe:bad --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: /path/to/5523-stack-test/.stack-work/logs/bad-0.1.0.log

Configuring bad-0.1.0...
Preprocessing executable 'bad' for bad-0.1.0..
Building executable 'bad' for bad-0.1.0..
[1 of 2] Compiling Main

/path/to/5523-stack-test/bad/Main.hs:4:47: error:
    lexical error in string/character literal at character '\n'
  |
4 | main = putStrLn "This is a blatant parse error
  |                                               ^

[snoyberg]

That all makes sense, but how does it affect things when there is interleaved output?

[wraithm]

When they're interleaved, the output is identical in both cases. Everything has the package name prepended, so errors definitely can't be parsed by emacs/vim there. Honestly, that's a little annoying too, imho, error locations should be on their own line. But the newest version of stack can't produce an output that allows for tracking of errors at all. I don't mind adding --no-interleaved-output.

Here's an example:

$ stack build # old version
Building all executables for `bad' once. After a successful build of all of them, only specified executables will be rebuilt.
bad> configure (exe)
bad> Configuring bad-0.1.0...
bad> build (exe)
bad> Preprocessing executable 'bad' for bad-0.1.0..
bad> Building executable 'bad' for bad-0.1.0..
bad> [1 of 2] Compiling Main
bad> 
bad> /path/to/5523-stack-test/bad/Main.hs:4:47: error:
bad>     lexical error in string/character literal at character '\n'
bad>   |
bad> 4 | main = putStrLn "This is a blatant parse error
bad>   |                                               ^
bad> 

--  While building package bad-0.1.0 (scroll up to its section to see the error) using:
      /home/user/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.4 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0 build exe:bad --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1

$ ../stack/stack build # new version
Building all executables for `bad' once. After a successful build of all of them, only specified executables will be rebuilt.
bad> configure (exe)
bad> Configuring bad-0.1.0...
bad> build (exe)
bad> Preprocessing executable 'bad' for bad-0.1.0..
bad> Building executable 'bad' for bad-0.1.0..
bad> [1 of 2] Compiling Main
bad> 
bad> /path/to/5523-stack-test/bad/Main.hs:4:47: error:
bad>     lexical error in string/character literal at character '\n'
bad>   |
bad> 4 | main = putStrLn "This is a blatant parse error
bad>   |                                               ^
bad> 

--  While building package bad-0.1.0 (scroll up to its section to see the error) using:
      /home/user/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.4 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0 build exe:bad --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1

[snoyberg]

If it's just changing the non-interleaved case, I don't see an issue. Can you add a changelog entry explaining the change? Then I'll be happy to merge. Thanks!

[wraithm]

Will do.

[wraithm]

@snoyberg Is this a behavior change, other enhancement, or a bug fix?

[wraithm]

I added it as an other enhancement! 👍🏻

[snoyberg]

Enhancement sounds good, thanks!

[snoyberg]

Thank you!

[wraithm]

Thank you! 👍🏻