November 2016 - ghc-tickets

[GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults
by GHC 30 Nov '16

30 Nov '16

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+---------------------------------- {{{ -- test.hs import System.Mem (performMajorGC) main = performMajorGC >> putStrLn "Done" }}} built with `ghc -pgmlo opt -pgmlc llc -fllvm --make test.hs` segfaults both for LLVM 3.4 and 3.5svn (taken from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64) 32-bit ghc-7.9.20140404+llvm produces good executable. Adding `ArchX86_64` `OSMinGW32` case to `moduleLayout` in `compiler/llvmGen/LlvmCodeGen/Ppr.hs` improves things slightly (some code segfaulting without it starts to work) but still does not cure the code above. Also I've found the Cmm produced for LLVM CG differs from that produced for NCG. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #12725: T7037 is broken on Windows
by GHC 30 Nov '16

30 Nov '16

#12725: T7037 is broken on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- `T7037` appears to fail on Windows. Namely, `stdout` appears to be empty, whereas the expected output is `"ok"`. I had suspected that the issue was the `execv` call failing but this doesn't seem to be thew case; no code after `execv` is executed. A problem for another day... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12554: Testsuite exibits large amount of framework failures
by GHC 30 Nov '16

30 Nov '16

#12554: Testsuite exibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've tried this on multiple computers and they all have the same issue. I get around 400 testsuite failures with the error: {{{ r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run T11797 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run T10734 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run T11345 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run T10820 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run T11484 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run T9022 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run T12130 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run T8761 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run T12407 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run T11463 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run T12478_4 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run T12478_3 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run T12513 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run T12530 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run') }}} What they all have in common is that they are all using the latest MSYS2 and tools: {{{ Tamar@Squid MINGW64 ~/ghc $ python3 --version Python 3.5.2 Tamar@Squid MINGW64 ~/ghc $ uname -a MINGW64_NT-10.0 Kino 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 30 Nov '16

30 Nov '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Is there anything left before we can do this? If not I will go ahead and put a patch up on Phabricator that makes `-split-objs` a deprecated synonym for `-split-sections`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2168: ghci should show haddock comments for identifier
by GHC 30 Nov '16

30 Nov '16

#2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): Doing some more investigations it might make more sense to add the docs to `HscTypes.ModIface` in a fashion similar to how Haddock does in its `Interface` type. This would also add the possibility of docs for unexported entities as Haddock currently supports. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2168#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11219: Implement fine-grained `-Werror=...` facility
by GHC 29 Nov '16

29 Nov '16

#11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: Design/Warnings -------------------------------------+------------------------------------- ...copied from Design/Warnings: Introduce variant of `-Werror` (c.f. GCC's `-Werror=*`) which allows to specify the individual warnings to be promoted to errors, e.g. - `-Wall -Werror=orphans` would only promote `-Worphans` warnings into errors - `-Wall -Werror -Wno-error=missing-methods` would promote all warnings //except// `-Wmissing-methods` into errors TODO: specify semantics a bit more exactly (the basic idea is to follow gcc/clang as much as sensible, and only deviate where it's necessary) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754
by GHC 29 Nov '16

29 Nov '16

#12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Where building ieee754 succeeded with GHC 7.10, it fails with 8.0 on platforms without registerised builds, for example arm64: {{{ [1 of 2] Compiling Numeric.IEEE ( Numeric/IEEE.hs, dist- ghc/build/Numeric/IEEE.o ) In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2448:6: error: error: conflicting types for 'nextup' EFF_(nextup); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextup' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2501:6: error: error: conflicting types for 'nextup' EFF_(nextup); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextup' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2554:6: error: error: conflicting types for 'nextupf' EFF_(nextupf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextupf' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2607:6: error: error: conflicting types for 'nextupf' EFF_(nextupf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextupf' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2660:6: error: error: conflicting types for 'nextdown' EFF_(nextdown); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdown' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2713:6: error: error: conflicting types for 'nextdown' EFF_(nextdown); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdown' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2766:6: error: error: conflicting types for 'nextdownf' EFF_(nextdownf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdownf' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2819:6: error: error: conflicting types for 'nextdownf' EFF_(nextdownf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdownf' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold -Wl,-z,noexecstack") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld.gold") ,("ld flags"," -z noexecstack") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchARM64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","YES") ,("LLVM llc command","llc-3.7") ,("LLVM opt command","opt-3.7") ,("Project version","8.0.1") ,("Project Git commit id","4986837f8168cacf95c24fecc84d7b36c47f3c11") ,("Booter version","7.10.3") ,("Stage","2") ,("Build platform","aarch64-unknown-linux") ,("Host platform","aarch64-unknown-linux") ,("Target platform","aarch64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib/ghc") ,("Global Package DB","/usr/lib/ghc/package.conf.d") ] }}} The same is true for mips64el, s390x, alpha, hppa, m68k, sh4, sparc64, and I imagine mips and mipsel as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12802> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #2168: ghci should show haddock comments for identifier
by GHC 29 Nov '16

29 Nov '16

#2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): Adamse: I think this would be great for haddock too, and am excited someone wants to proceed! I know that a number of people have an interest in this, and am trying to get some further eyes on the proposal to confirm it makes sense, but on first glance it looks like a reasonable approach. Even step 1 on its own would be great, as an opportunity for lots of tooling (ghci included) to start making use of the data. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2168#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12799: Itimer.c doesn't compile on iOS non-threaded RTS
by GHC 29 Nov '16

29 Nov '16

#12799: Itimer.c doesn't compile on iOS non-threaded RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS uses the pthread-based `Itimer` implementation due to the bizarrely crippled timer mechanisms provided imposed by that platform. This broke in 999c464da36e925bd4ffea34c94d3a7b3ab0135c which fixed the pthreads implementation to correctly pause when unneeded. In doing this, however, it introduced a dependency on the RTS's synchronization primitives provided by `OSThreads.c` (e.g. `Condition`, `Mutex`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12851: Regression: GHC doesn't show filepaths by default anymore
by GHC 29 Nov '16

29 Nov '16

#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

1 13