May 2016 - ghc-tickets

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

15 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 15 Dec '16

15 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] #12042: Infinite loop with type synonyms and hs-boot
by GHC 15 Dec '16

15 Dec '16

#12042: Infinite loop with type synonyms and hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a "known" bug, but the source code comment which mentioned this could happen didn't give a test case so I thought I'd supply one. {{{ -- A.hs-boot module A where data S type R = S -- B.hs module B (module A, module B) where import {-# SOURCE #-} A type U = S -- A.hs module A where import qualified B type S = B.R type R = B.U }}} When I try to build `A.hs` in one-shot I infinite loop: {{{ ezyang@sabre:~$ ghc-8.0 --make A.hs -fforce-recomp [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs-boot:2:1: error: Type constructor ‘S’ has conflicting definitions in the module and its hs-boot file Main module: type S = R Boot file: abstract S ezyang@sabre:~$ ghc-8.0 -c A.hs -fforce-recomp ^C }}} The problem is that `-c` properly knot ties `data S` in the boot file to the local type synonym (`--make` is unaffected due to #12035), and then we have a type synonym loop which GHC doesn't catch early enough. `TcTyDecls.hs` has a nice comment which suggests that this is a known bug: {{{ Checking for class-decl loops is easy, because we don't allow class decls in interface files. We allow type synonyms in hi-boot files, but we *trust* hi-boot files, so we don't check for loops that involve them. So we only look for synonym loops in the module being compiled. We check for type synonym and class cycles on the *source* code. Main reasons: a) Otherwise we'd need a special function to extract type-synonym tycons from a type, whereas we already have the free vars pinned on the decl b) If we checked for type synonym loops after building the TyCon, we can't do a hoistForAllTys on the type synonym rhs, (else we fall into a black hole) which seems unclean. Apart from anything else, it'd mean that a type-synonym rhs could have for-alls to the right of an arrow, which means adding new cases to the validity checker Indeed, in general, checking for cycles beforehand means we need to be less careful about black holes through synonym cycles. The main disadvantage is that a cycle that goes via a type synonym in an .hi-boot file can lead the compiler into a loop, because it assumes that cycles only occur entirely within the source code of the module being compiled. But hi-boot files are trusted anyway, so this isn't much worse than (say) a kind error. }}} although the circumstances in this example are a little different. I take this bug as evidence that we should NOT attempt to knot-tie in this situation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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