November 2015 - ghc-tickets

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

14 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 13 Feb '16

13 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 11 Feb '16

11 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] #8136: arr020 test fails randomly with ghci way
by GHC 07 Feb '16

07 Feb '16

#8136: arr020 test fails randomly with ghci way -----------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------- I noticed that when I run arr020 (`make TEST=arr020`) it randomly segfaults when running `ghci` way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8265: getTokenStream fails for source using cpp
by GHC 07 Feb '16

07 Feb '16

#8265: getTokenStream fails for source using cpp -----------------------------------+--------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Calling getTokenStream (or getRichTokenStream) on a module that has CPP directives fails as the lexer is given un-preprocessed source -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10862: No way to exclude current directory from search path
by GHC 07 Feb '16

07 Feb '16

#10862: No way to exclude current directory from search path -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Having Main.hs in the current directory, executing ghc --make Main -i still compiles the module, even though -i should in theory "reset the search path back to nothing". But it seems nothing ~ the default (current dir). I would propose to either change the behavior, or add a new flag, in order to be able to better control the build environment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10898: GHCI crash
by GHC 07 Feb '16

07 Feb '16

#10898: GHCI crash ---------------------------------+------------------------------- Reporter: trebor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------+------------------------------- robert@HeisenbergJr:~$ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-linux): interactiveUI:setBuffering2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3