September 2015 - ghc-tickets

[GHC] #9017: Confusing error message with PolyKinds
by GHC 12 Dec '15

12 Dec '15

#9017: Confusing error message with PolyKinds ------------------------------------+------------------------------------- Reporter: edsko | 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: | ------------------------------------+------------------------------------- Consider the following example code: {{{ import Control.Arrow foo :: a b (m b) foo = arr return }}} if we typecheck this we rightly get two errors about missing instances (Arrow a, Monad m). However, if we enable `PolyKinds` we get the following error message: {{{ T.hs:4:7: Kind incompatibility when matching types: a0 :: * -> * -> * a :: k1 -> k -> * Expected type: a b (m b) Actual type: a0 b0 (m0 b0) Relevant bindings include foo :: a b (m b) (bound at T.hs:4:1) In the expression: arr return In an equation for ‘foo’: foo = arr return }}} I can ''sort of'' see where this is coming from if I think really hard :), so perhaps it's not a bug per se, but it's definitely confusing; and it's a pity that a type error (forgotten type qualifier) is reported as a kind error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9017> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9389: Full Test Suite Failures
by GHC 11 Dec '15

11 Dec '15

#9389: Full Test Suite Failures ------------------------------------+---------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+---------------------------------- This is just to record progress on running the full test suite on OS X for the current HEAD using a BuildFlavour = perf build. I'll check through these (some of which are configuration issues because of the non-standard build or some required libraries are not being pulled in). {{{ OVERALL SUMMARY for test run started at Thu Jul 31 23:03:39 2014 BST 0:32:31 spent to go through 4036 total tests, which gave rise to 19262 test cases, of which 4218 were skipped 358 had missing libraries 14485 expected passes 135 expected failures 0 caused framework failures 0 unexpected passes 66 unexpected failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals004 [bad exit code] (threaded2) concurrent/should_run T367_letnoescape [bad exit code] (optllvm) concurrent/should_run conc012 [bad exit code] (ghci) driver/objc objc-hi [bad profile] (profthreaded) driver/objc objc-hi [bad heap profile] (profasm) driver/objc objcpp-hi [bad profile] (profthreaded) driver/objc objcpp-hi [bad heap profile] (profasm) ffi/should_run ffi002 [bad exit code] (threaded2) indexed-types/should_compile T7837 [stderr mismatch] (profasm) perf/compiler T4801 [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/should_run T9203 [stat too good] (normal) profiling/should_run callstack001 [bad stdout] (prof) quasiquotation/qq007 qq007 [exit code non-0] (profasm) quasiquotation/qq008 qq008 [exit code non-0] (profasm) rts T5435_dyn_asm [bad stdout] (normal) rts T7919 [exit code non-0] (profasm,profthreaded) rts T9078 [exit code non-0] (profasm) rts derefnull [bad profile] (profasm,profthreaded) rts divbyzero [bad profile] (profasm,profthreaded) rts overflow1 [bad exit code] (hpc,optasm,profasm,threaded2,dyn,profthreaded,optllvm) rts overflow2 [bad profile] (profasm,profthreaded) rts overflow3 [bad profile] (profasm,profthreaded) simplCore/should_compile T5550 [exit code non-0] (profasm) simplCore/should_compile T7702 [exit code non-0] (profasm) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #10527: Panic Simplifier ticks exhausted with type families
by GHC 08 Dec '15

08 Dec '15

#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've tried to compile my vinyl-like records with 7.10.2-rc1 and got: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op rreplace To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 225484 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attached self contained test compiles with 7.10.1, but fails with 7.10.2-rc1 when compiled with optimizations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation
by GHC 08 Dec '15

08 Dec '15

#10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: pattern | Type of failure: None/Unknown synonyms | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Suppose I have the following two modules. {{{#!hs {-# LANGUAGE PatternSynonyms #-} module A where data A = A2 Int Int pattern A1 a <- A2 a _ where A1 a = A2 a 0 }}} {{{#!hs module B where import A ( A(..) ) a = A1 0 }}} When I try to compile `B.hs` I get an error because `A1` is unbound in module `B`. {{{ $ ghc --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) B.hs:5:5: Not in scope: data constructor ‘A1’ Perhaps you meant ‘A2’ (imported from A) }}} The issue is that the import `A(..)` brings all of `A`s data constructors and accessors into scope, but not any associated pattern synonyms. Instead I have to enable `PatternSynonyms` in module `B` (or just import everything from `A`). {{{#!hs {-# LANGUAGE PatternSynonyms #-} module B where import A ( A(..), pattern A1 ) a = A1 0 }}} I'd like to propose that we extend the semantics of the `A(..)` import/export notation to include any associated pattern synonyms. I think this is in line with the spirit of `PatternSynonyms`, that the extension should allow internal refactoring without causing API breakage, and that the extension should only need to be enabled to *define* pattern synonyms. FYI, this issue does appear in the wild, I ran into it while working on https://phabricator.haskell.org/D861 and had to modify two import lists in Cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10653> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #10444: Tex.Read.Lex.lex broken
by GHC 07 Dec '15

07 Dec '15

#10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ Prelude> lex "&) = mempty" [("&",") = mempty")] Prelude> lex "∘) = mempty" [] }}} I traced this problem to Text.Read.Lex.lex -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8245: ghc-pkg list prints packages in non-alphabetical order
by GHC 07 Dec '15

07 Dec '15

#8245: ghc-pkg list prints packages in non-alphabetical order ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Instead, it prints the ones with the smallest version first. That does not make much sense. I will attach a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names
by GHC 07 Dec '15

07 Dec '15

#10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Trying to help @mpickering with Phab:D1258, I looked at the code in `tcRnSrcDecls` and was surprised to see that exports are renamed after this function is complete. This didn't make any sense to me. And, indeed, it's wrong, witness by this example: {{{ {-# OPTIONS_GHC -fwarn-missing-exported-sigs #-} module Bug (Data.List.intercalate, x) where import qualified Data.List intercalate = True x :: Bool x = intercalate }}} This produces {{{ Bug.hs:7:1: Warning: Top-level binding with no type signature: intercalate :: Bool }}} This warning should not be emitted. I'm not all that concerned about this scenario biting in the wild, but it suggests that refactoring this code is a good thing, and not something Phab:D1258 should take pains to avoid. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10908> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc.
by GHC 07 Dec '15

07 Dec '15

#9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Moderate (less | bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I'm working on a little REPL and the GHC API seems to supply two functions for evaluating one line, without compiling and evaluating into an `HValue`, which doesn't seem to have an `Outputable` instace: `runStmt` and `runDecls`. As it turns out, I need slightly different code to run on declarations verses statements, so this makes sense, but given a random string from the user, how can I tell the difference? I don't see anything in the documentation about this. I took a look at ghci's source (https://github.com/ghc/ghc/blob/a6f2c852d49313fa8acea2deb3741ab86c6ef995/gh…] and it looks like they just peek at the first word of the input, and that may be correct and sufficient, but impossible to verify without looking at Haskell's grammar. But even if I did verify it, that doesn't make explicit the difference between what `runDecls` and `runStmt` will accept. For a contrived example, consider if GHC implemented a feature that allowed for a new type of decl. It might be enabled by a language extension which means that testing whether a string is a statement or declaration cannot be done purely as we have to check the dynflags. Furthermore, the client may not be aware of the extension and thus send the input to `runStmt` instead. It would seem to me that requiring the user to manually parse the input violates separation of concerns since truly GHC knows best what source GHC will accept. The user should not have to examine the input except for if they need to modify or interpret it as something other than Haskell source code. The GHC API should either document an example function for differentiating declarations from statements (and even import statements), supply one itself, or supply several along the lines of `isDecl, isStmt, isImport :: String -> Bool`. This would improve ease-of-use by making client code more obvious and correct. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9706: New block-structured heap organization for 64-bit
by GHC 05 Dec '15

05 Dec '15

#9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar 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: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was having some discussion about GHC's block structured heap with Sergio Benitez and Adam Belay, and during the discussion it was suggested that the way GHC manages the block structured heap is suboptimal when we're on 64-bit architectures. At the moment, we allocate memory from the operating system per-megablock, storing metadata in the very first megablock. We have to do this because, on 32-bit, we can't generally be too picky about what address our memory ends up living. On 64-bits, we have a lot more flexibility. Here is the proposal: 1. Statically decide on a maximum heap size in a power of two. 2. Next, probe for some appropriately aligned chunk of available virtual address space for this. On POSIX, we can mmap /dev/null using PROT_NONE and MAP_NORESERVE. On Windows, we can use VirtualAlloc with MEM_RESERVE. (There are few other runtimes which do this trick, including GCC Go.) 3. Divide this region into blocks as before. The maximum heap size is now the megablock size, and the block size is still the same as before. Masking to find the block descriptor works as before. 4. To allocate, we keep track of the high-watermark, and mmap in 1MB pages as they are requested. We also keep track of how much metadata we need, and mmap extra pages to store metadata as necessary. We still want to request memory from the operating system in conveniently sized chunks, but we can now abolish the notion of a megablock and the megablock allocator, and work purely with block coalescing. Additionally, the recorded heap location means that we can check if a pointer is HEAP_ALLOCED using a mask and equality check, solving #8199. What do people think? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8582: Record syntax for pattern synonyms
by GHC 04 Dec '15

04 Dec '15

#8582: Record syntax for pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Implement syntax for {{{ pattern Cons{car, cdr} = (car, cdr) }}} which can then be used just like a regular record constructor, so the following are all valid patterns: {{{ Cons (Just x) [] Cons{car = Just x} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16