GitLab

Sorry for chiming in so late, I didn't notice #12807 (closed) and I didn't build GHC HEAD for several days, otherwise I would have cried out loud sooner.

I'm deliberately declaring this a regression since I consider this a bad default. And not for the mere fact that change is bad ;-)

Don't get me wrong, I can see usefulness in the -fno-show-source-paths feature (although I consider it inconsistent, see below), but it's a bad default because in my workflows I rely on seeing the source-path by default, and I see no way to restore this as the default behaviour of GHC short of patching GHC.

 [1 of 1] Compiling Control.Concurrent.STMSupply (.hs -> .o)

First of all, if we drop filepaths, then please drop them completely, either I need more information about which .hs file was used as source, or I don't need it at all, so this (.hs -> .o) suffix is just noise to me; not the least because the -> .o part carries almost no information for me. If the premise of -fno-show-source-paths is that we know how we called GHC and thereby know what is being compiled, showing (.hs -> .o) is pointless.

Morever, -f(no-)show-source-paths is a lie/misnomer, as it doesn't only control the *source* path display, but *also* the *output* path display!

Also, when invoking GHC, and pass it multiple include folders, sometimes GHC picks up the wrong module (or rather one I didn't intend), having it print the source file path by default has been a big timesaver to me, detecting when I was barking up the wrong source-file while figuring out why stuff didn't work.

Finally, this also breaks my shell-based workflow because I'm used to copy'n'paste filepaths from GHC's output, especially for longer source-paths where tab-completing my way to the source path is too tedious.

This is just the first impression I got while being exposed to this UI change today, there may be other regressions I'd notice when having to use this for longer.

So, in summary I propose to

• Make -fshow-source-paths the default again

• drop the (.hs->.o) suffix in -fno-show-show-source-paths

• consider a better name; actually, I can see cases where you want to omit only the output-path display (since it's imho often less interesting to know the output files names; even though sometimes you may want to know it since it can be affected in a non-obvious way by output-dir flags), e.g. maybe

• Have -f(no-)show-source-paths control the source-path display

• Have -f(no-)show-output-paths control the output-path display

• As a compromise, consider -fshow-source-paths -fno-show-output-paths becoming the new default.

Trac metadata

Trac field	Value
Version	8.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	low
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture