#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: regression | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry for chiming in so late, I didn't notice #12807 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler