April 2016 - ghc-tickets

[GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators
by GHC 16 Dec '16

16 Dec '16

#11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.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: -------------------------------------+------------------------------------- Throughout GHC's source there are related pretty-printing operators with subtly different `infixr/infixl`-declarations. It would be desirable to unify those and possibly use `Semigroup((<>))` instead (where `<>` represents a semigroup/monoid operation anyway) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11243: Use Type Synonyms to Compress Errors
by GHC 16 Dec '16

16 Dec '16

#11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Error messages can be ugly, especially when working with promoted types. I've been dealing with this for a long time with [one library in particular](https://hackage.haskell.org/package/lol). But I just encountered something truly heinous. Due to a minor mistake, GHC spit out 8 errors in total, the shortest of which was 60 lines, and the longest of which was 20,046 lines long. That's no typo: the last error is over 20,000 lines long. Props to GHC for handling such a mess. As the library author, I've learned to look paste these massive errors. But I'm afraid that some user is going to have a heart attack (or worse: give up and go home). You can see in the error message that most of it is recurring blocks of {{{ PrimePower ('PP '(type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type- natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type- natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type- natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0)))))), type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type-natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0)) }}} and {{{ (NextListElt * zq ((':) * (ZqBasic * Types.Q18869761 Types.Z) ((':) * (Types.Zq * Types.Q19393921, ZQ1) ((':) * (Types.Zq * Types.Q19918081, ZQ2) ((':) * (Types.Zq * Types.Q2149056001, ZQ3) ((':) * (Types.Zq * Types.Q3144961, ZQ4) ((':) * (Types.Zq * Types.Q7338241, ZQ5) ('[] *))))))))), }}} I believe that GHC attempts to expand type synonyms as much as possible, which is great in many cases. But for this error, the repetition of fully expanded blocks completely hides the true nature of the error, especially since the user (obviously) makes heavy use of type synonyms anyway. The feature I'm requesting is the ability to somehow reduce the mess in the attached error. Here are a few ideas: 1. A flag to tell GHC to *not* expand type synonyms, i.e. if the user uses `N2` from Data.Type.Natural, GHC should print 'N2' instead of {{{ type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type-natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0) }}} 2. Allow library developers a way to tell the compiler how to print a certain entity, i.e., with a custom name. This is somewhat similar to the Custom Type Errors proposal, but I don't think that proposal includes a way to tell GHC how to print specific types/type synonyms. Has anyone else run into this issue before? Are there any existing solutions or other ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10301: Plugins/dynamic loading subtly broken (it seems)
by GHC 15 Dec '16

15 Dec '16

#10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.8.2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: | crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #8276 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Imported from #8276, which was originally about a Haddock bug (that was different in nature but appeared similarly): > I still experience this panic on GHC 7.8.2 with Windows x86_64: > > {{{ > $ ghci > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > λ> import StaticFlags > λ> import Data.IORef > λ> readIORef v_opt_C_ready > Loading package array-0.5.0.0 ... linking ... done. > Loading package deepseq-1.3.0.2 ... linking ... done. > Loading package bytestring-0.10.4.0 ... linking ... done. > Loading package containers-0.5.5.1 ... linking ... done. > Loading package Win32-2.3.0.2 ... linking ... done. > Loading package filepath-1.3.0.2 ... linking ... done. > Loading package old-locale-1.0.0.6 ... linking ... done. > Loading package time-1.4.2 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package pretty-1.1.1.1 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package Cabal-1.18.1.3 ... linking ... done. > Loading package binary-0.7.1.0 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hoopl-3.10.0.1 ... linking ... done. > Loading package hpc-0.6.0.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package transformers-0.3.0.0 ... linking ... done. > Loading package ghc-7.8.2 ... linking ... done. > False > λ> staticFlags > ghc.exe: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-unknown-mingw32): > Static flags have not been initialised! > Please call GHC.parseStaticFlags early enough. > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > But not with GHC 7.8.2 on Linux x86_64: > > {{{ > $ ghci > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > λ> import StaticFlags > λ> import Data.IORef > λ> readIORef v_opt_C_ready > Loading package array-0.5.0.0 ... linking ... done. > Loading package deepseq-1.3.0.2 ... linking ... done. > Loading package bytestring-0.10.4.0 ... linking ... done. > Loading package containers-0.5.5.1 ... linking ... done. > Loading package filepath-1.3.0.2 ... linking ... done. > Loading package old-locale-1.0.0.6 ... linking ... done. > Loading package time-1.4.2 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package pretty-1.1.1.1 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package Cabal-1.18.1.3 ... linking ... done. > Loading package binary-0.7.1.0 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hoopl-3.10.0.1 ... linking ... done. > Loading package hpc-0.6.0.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package transformers-0.3.0.0 ... linking ... done. > Loading package ghc-7.8.2 ... linking ... done. > True > λ> staticFlags > [] > }}} > > This has caused problems for me when running programs such as [https://github.com/ku-fpg/hermit/ HERMIT] on Windows, since at some point, {{{parseStaticFlagsFull}}} seems to be called during program execution. A workaround is to call {{{initStaticOpts}}} manually somewhere in the program, but I feel like that shouldn't be necessary. The one above was on Windows. Also reported: > Hello, > > A similar panic also happens when running Liquid Haskell [http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/] on a file that uses the Units of Measure plugin [https://github.com/adamgundry/uom- plugin] > > > {{{ > liquid: liquid: panic! (the 'impossible' happened) > (GHC version 7.10.1 for x86_64-unknown-linux): > Static flags have not been initialised! > Please call GHC.parseStaticFlags early enough. > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #10294: Missing instances if compiling with -fplugin
by GHC 15 Dec '16

15 Dec '16

#10294: Missing instances if compiling with -fplugin -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Linux Keywords: | Type of failure: GHC rejects Architecture: x86_64 | valid program (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using the example from "9.3.3.2. Using Annotations" of the GHC user manual does not work correctly with GHC 7.10. The following fails: $ ghc -c Bug1.hs -fplugin=SayAnnNames.Plugin {{{ Bug1.hs:5:1: No instance for (Data SomeAnn) arising from an annotation In the annotation: {-# ANN foo SomeAnn #-} }}} It does not seem to matter why the type class is required: $ ghc -c Bug2.hs -fplugin=SayAnnNames.Plugin {{{ Bug2.hs:10:7: No instance for (Data SomeAnn) arising from a use of ‘bar’ In the expression: bar SomeAnn In an equation for ‘baz’: baz = bar SomeAnn }}} Compiling without -fplugin works fine, though. If SomeAnn is defined in a different module than SayAnnNames.Plugin and reexported from it, the instances are in scope, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10294> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9890: RTS -qa option is helpful but under-documented
by GHC 15 Dec '16

15 Dec '16

#9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The entire documentation for the RTS `-qa` option is Use the OS's affinity facilities to try to pin OS threads to CPU cores. This is an experimental feature, and may or may not be useful. Please let us know whether it helps for you! It does help for us: enabling it on a multithreaded, moderately GC-heavy web server led to a sizeable improvement (~20%) in throughput benchmarks. However, it would be nice if the GHC documentation was a little more descriptive about what exactly this option does and how experimental it is now considered! (Relatedly, perhaps it would be worth adding a single index of RTS options in the user's guide, much like the flag reference for GHC itself.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10614: Show constraints in ``Found hole...''
by GHC 15 Dec '16

15 Dec '16

#10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently it is not clear when types are known equal. Consider writing castWith: {{{#!hs {-# LANGUAGE GADTs , TypeOperators #-} import Data.Type.Equality hiding (castWith) castWith :: a :~: b -> a -> b castWith Refl x = _ }}} which results in {{{ TypeEq.hs:5:19: error: Found hole: _ :: b Where: ‘b’ is a rigid type variable bound by the type signature for: castWith :: a :~: b -> a -> b at TypeEq.hs:4:13 Relevant bindings include x :: a (bound at TypeEq.hs:5:15) castWith :: a :~: b -> a -> b (bound at TypeEq.hs:5:1) In the expression: _ In an equation for ‘castWith’: castWith Refl x = _ }}} Filling the hole with x is correct, but it is not clear from the message that GHC knows this. It would be useful to have a section "Constraints include" e.g. {{{ TypeEq.hs:5:19: error: Found hole: _ :: b Where: ‘b’ is a rigid type variable bound by the type signature for: castWith :: a :~: b -> a -> b at TypeEq.hs:4:13 Relevant bindings include x :: a (bound at TypeEq.hs:5:15) castWith :: a :~: b -> a -> b (bound at TypeEq.hs:5:1) Constraints include <------ NEW LINE a ~ b (from Refl :: a :~: a at TypeEq.hs:5:10) <------ NEW LINE In the expression: _ In an equation for ‘castWith’: castWith Refl x = _ }}} And show class constraints (Show a etc.) similarly -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory
by GHC 13 Dec '16

13 Dec '16

#9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I initially filed this as a [http://stackoverflow.com/questions/26333815 /why-do-hgetbuf-hputbuf-etc-allocate-memory question on StackOverflow], assuming that the behavior I'm seeing was intentional, or that I was misinterpreting the profiler results... but Kazu Yamamoto [https://twitter.com/kazu_yamamoto/status/522583112249663488 suggested] I should file this as an issue here. It's my first GHC ticket, so here goes: {{{#!hs main :: IO () main = do buf <- mallocArray 1 echo buf echo :: Ptr Word8 -> IO () echo buf = forever $ do len <- readRawBufferPtr "read" stdin buf 0 1 writeRawBufferPtr "write" stdout buf 0 (fromIntegral len) }}} I expect the only heap allocation here should be my explicit `mallocArray`, but profiling with `+RTS -P` indicates this isn't the case: both the read and write operations do appear to allocate some short-lived heap objects. In contrast: {{{#!hs echo :: Ptr Word8 -> IO () echo buf = forever $ do threadWaitRead $ Fd 0 len <- c_read 0 buf 1 c_write 1 buf (fromIntegral len) yield }}} does not appear to allocate. I did a bit of digging (copying bits of source code from `base` into my own project, to get cost center annotations) and it seems like the allocation might be happening in `throwErrnoIfRetryMayBlock`. See [https://gist.github.com/anonymous/3ba3cfa118e1d05870d4 this gist] for more detail, including core output from `-ddump-simpl`. In all honesty, I don't know whether this is a bug. I was just surprised by it, when I first encountered it using `hGetBuf` / `hPutBuf`, so I'm trying to understand whether this is expected behavior and why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8248: GHCi should not warn if group writable
by GHC 13 Dec '16

13 Dec '16

#8248: GHCi should not warn if group writable ----------------------------+---------------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Any number of Linux distros support the idea of user groups, whereby when a new user is created there is also simultaneously a group created with the same name; ie, instead of {{{ -rw-r--r--. 1 andrew users 19 Sep 5 08:29 ghci.conf }}} as us old traditionalists would have it, you get {{{ -rw-rw-r--. 1 andrew andrew 19 Sep 5 08:29 ghci.conf }}} because the umask in such cases is 0002 instead of 0022. There is entirely nothing unusual or incorrect about this approach, and it is followed, for example, in the Fedora family of distros. GHC, however, is being a bit silly in emitting the following: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. *** WARNING: /home/andrew/.ghc/ghci.conf is writable by someone else, IGNORING! Prelude> }}} Foremost the fact that the file is group writable is not a problem and the user's choice, //particularly// in this case because it's group writable in the user's group! Regardless of that, GHCi should not be ignoring files with other than 0644 permissions; this isn't `.ssh/`. Can this check and attendant behaviour be removed? AfC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11739: Simplify axioms; should be applied to types
by GHC 12 Dec '16

12 Dec '16

#11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But the example shows that the new expressiveness is not expressive enough! Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F <Int> co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the ax[1] is not necessarily OK. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm
by GHC 10 Dec '16

10 Dec '16

#9308: nofib fannkuch-redux runs perpetually with -fllvm ------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Running the nofib benchmarks with make -k EXTRA_HC_OPTS=-fllvm on a HEAD build of ghc configured with perf-llvm (3.4.2) results in fannkuch-redux running in an infinite loop. The benchmark runs in about 3.5s without the -fllvm {{{ HC = /Users/xx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 RUNTEST_OPTS = -ghc-timing ==nofib== fannkuch-redux: time to compile Main follows... /Users/jrp/Projects/ghc/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 -c Main.hs -o Main.o <<ghc: 358716248 bytes, 313 GCs, 10827462/27497216 avg/max bytes residency (6 samples), 57M in use, 0.00 INIT (0.00 elapsed), 0.20 MUT (0.53 elapsed), 0.21 GC (0.23 elapsed) :ghc>> ==nofib== fannkuch-redux: size of Main.o follows... __TEXT __DATA __OBJC others dec hex 10333 497 0 0 10830 2a4e ==nofib== fannkuch-redux: time to link fannkuch-redux follows... <<ghc: 19914544 bytes, 16 GCs, 1005021/2239600 avg/max bytes residency (3 samples), 25M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.53 elapsed), 0.02 GC (0.02 elapsed) :ghc>> ==nofib== fannkuch-redux: size of fannkuch-redux follows... __TEXT __DATA __OBJC others dec hex 4075520 446464 0 4295945496 4300467480 10053ed18 ==nofib== fannkuch-redux: time to run fannkuch-redux follows... ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9