December 2015 - ghc-tickets

[GHC] #8278: Improve error message when the same type is imported from two different library versions
by GHC 15 Feb '16

15 Feb '16

#8278: Improve error message when the same type is imported from two different library versions ------------------------------------+------------------------------------- Reporter: Yuras | 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: | ------------------------------------+------------------------------------- When a package indirectly depends on different versions of the same library, ghc reports cryptic error: {{{ Couldn't match expected type `ByteString' with actual type `bytestring-0.9.2.1:Data.ByteString.Internal.ByteString' }}} Error contains fully qualified type with package name and version only when the type is imported from different versions on the library, so looks like ghc knows what is wrong. Is it possible to add something like the next: {{{ Note: ByteString is imported from different package versions: bytestring-0.9.2.1 and bytestring-0.10.0.1 }}} It is inspired by a number of StackOverflow questions (e.g. http://stackoverflow.com/questions/12576817/couldnt-match-expected-type- with-actual-type-error-when-using-codec-bmp/12577025#12577025, http://stackoverflow.com/questions/18767086/bytestring-to-lazy-text-and- vice-versa/18769431?noredirect=1#comment27676563_18769431) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10576: REPL returns list of all imported names when operator completion requested
by GHC 15 Feb '16

15 Feb '16

#10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple completions complete command | Type of failure: Incorrect result operator | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When querying completions for operators GHCi returns a list containing all imported names rather than suitable completions. For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base and Prelude. Then if you import something else, for example `:m +Data.Text`, the result of query will contain names from Data.Text also. In case of projects (`cabal repl`) things are worst, because returned list contains all names imported project-wise and it could be really huge. GHCi behaves similarly with following queries: :complete repl "(>>" :complete repl "Prelude.>>" :complete repl "Prelude.(>>" I only tested this on OS X 10.9, GHC 7.8.4 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9920: Segfault in arm binary
by GHC 14 Feb '16

14 Feb '16

#9920: Segfault in arm binary ----------------------------+------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+------------------------------------------- Using ghc HEAD (6713f0d9a) I compile a very simple program which segfaults immediately. Stepping through it using GDB I find its crashing on the instruction {{{ 0x3f5a98 <stg_init_finish$def+12> ldr r5, [r5] }}} and that just before this instruction the value of `r5` is zero. That means its trying to load into `r5` the value at the address in `r5`. Obviously that's going to segfault. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch
by GHC 12 Feb '16

12 Feb '16

#9022: TH pretty printer and GHC parser semicolon placement mismatch ----------------------------+---------------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- In GHC 7.8 TemplateHaskell pretty printer started inserting explicit braces and semicolons. It puts semicolons at the end of the line as opposed to the beginning of the next line. This causes GHC to fail parsing if we try to compile the pretty printed code. {{{ $ cat Foo.hs module Main where import Language.Haskell.TH main = putStrLn $ pprint foo foo :: Dec foo = barD where barD = FunD ( mkName "bar" ) [ Clause manyArgs (NormalB barBody) [] ] barBody = DoE [letxStmt, retxStmt] letxStmt = LetS [ ValD (VarP xName) (NormalB $ LitE $ IntegerL 5) [] ] retxStmt = NoBindS $ AppE returnVarE xVarE xName = mkName "x" returnVarE = VarE $ mkName "return" xVarE = VarE xName manyArgs = map argP [0..9] argP n = VarP $ mkName $ "arg" ++ show n $ ghc-7.8.2 Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo ... $ ./Foo | tee Bar.hs bar arg0 arg1 arg2 arg3 arg4 arg5 arg6 arg7 arg8 arg9 = do {let x = 5; return x} $ ghc Bar.hs [1 of 1] Compiling Main ( Bar.hs, Bar.o ) Bar.hs:2:61: parse error on input `return' }}} I don't know if this is a problem with TH pretty printer or if GHC is supposed to parse semicolons wherever they are.. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9386: GHCi cannot load .so in same ./
by GHC 12 Feb '16

12 Feb '16

#9386: GHCi cannot load .so in same ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In my directory ./ I have an empty file Foo.hs and a shared object file mylib.so. From that directory in the shell, $ ghci Foo *.so 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. Loading object (dynamic) mylib.so ... failed. <command line>: user specified .o/.so/.DLL could not be loaded (mylib.so: cannot open shared object file: No such file or directory) Whilst trying to load: (dynamic) mylib.so Additional directories searched: (none) It's interesting that GHCi searches ./ and identifies the correct object file, but then fails to load it. I have also tried the path ./*.so for the GHCi option. However, if I move mylib.so to a directory ./Temp, $ ghci Foo Temp/*.so loads without issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10734: pprint of ‘let’ inside ‘do’ prints invalid Haskell
by GHC 10 Feb '16

10 Feb '16

#10734: pprint of ‘let’ inside ‘do’ prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On GHC 7.10.1 {{{#!hs Prelude Language.Haskell.TH Language.Haskell.TH.Ppr> pprint <$> runQ [| do { let { x = 5 }; return x; } |] "do {let x_0 = 5; GHC.Base.return x_0}" }}} The let binding inside the resulting {{{do}}} should be inside curly braces too -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10022: Clean up GHC.RTS.Flags
by GHC 09 Feb '16

09 Feb '16

#10022: Clean up GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: normal | Version: 7.10.1-rc1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: #9970 Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There's some cleanup to do for `GHC.RTS.Flags`, based on the comments in https://ghc.haskell.org/trac/ghc/ticket/5364#comment:11 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11163: New exhaustiveness checker breaks T5642
by GHC 09 Feb '16

09 Feb '16

#11163: New exhaustiveness checker breaks T5642 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new exhaustiveness checker drastically increases compile time of the `T5642` testcase. From the profile it appears that a great deal of time is being spent evaluating `Check.mkPmId.occname`, {{{ COST CENTRE MODULE %time %alloc mkPmId.occname Check 73.7 16.9 mkOneConFull Check 3.4 10.2 deSugar HscMain 2.8 14.8 mkOneConFull.arguments Check 2.5 5.5 pmTraverse Check 1.6 0.8 mkOneConFull.subst1 Check 1.5 5.9 wrapK.go Check 1.5 5.9 cMatcher Check 1.2 2.7 canEvVar TcCanonical 1.0 3.4 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11161: New exhaustiveness checker breaks concurrent/prog001
by GHC 09 Feb '16

09 Feb '16

#11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: concurrent/prog001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new exhaustiveness checker appears to allocate until the machine runs out of memory while compiling the `concurrent/prog001` testcase. In particular it stalls while desugaring the `Thread` module. The fact that this module contains non-trivial pattern matching, coupled with the compiler gets stuck in `Desugar`, and the fact that I've noted other performance issues with the new exhaustiveness checker (see #10711) leads me to believe that this patch is to blame. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11160: New exhaustiveness checker breaks ghcirun004
by GHC 09 Feb '16

09 Feb '16

#11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new exhaustiveness checker has broken `tests/ghci/should_run/ghcirun004`, which now hangs in desugaring. If one removes all but a few hundred of `foo`'s equations in the test things return to sanity. It appears that the compile time is scaling non-linearly with the number of equations, ||= no. equations =||= compile wall time =|| || 150 || 0.4 s || || 250 || 0.89 s || || 300 || 1.22 s || || 350 || 1.85 s || || 400 || 2.65 s || || 500 || 4.86 s || || 550 || 6.60 s || || 600 || 8.65 s || || 650 || 10.27 s || || 700 || 12.84 s || || 1000 || 38.51 s || -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12