November 2016 - ghc-tickets

[GHC] #12686: Attempt to promote a value to a type results in an internal error
by GHC 28 Nov '16

28 Nov '16

#12686: Attempt to promote a value to a type results in an internal error -------------------------------------+------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Trying to compile {{{#!hs {-# LANGUAGE GADTs, DataKinds, KindSignatures #-} data Nat = Zero | Succ Nat data Vec :: * -> Nat -> * where Nil :: Vec a 'Zero Cons :: a -> Vec a n -> Vec a ('Succ n) data Bad = Bad { a :: Nat, b :: Vec Int a} }}} results in `error: Not in scope: type variable ‘a’`. Change the last structure to {{{#!hs data Bad = Bad { a :: Nat, b :: Vec Int 'a} }}} and the result is {{{ • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r15Y :-> ATcTyCon Bad, r17P :-> APromotionErr RecDataConPE] • In the second argument of ‘Vec’, namely ‘a’ In the type ‘Vec Int a’ In the definition of data constructor ‘Bad’ }}} The user is attempting to promote a value to a type, which cannot be done, but the error message should be more informative. Reproduces in 8.0.1 and 8.1.20160916. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #618: Dependency caching in ghc --make
by GHC 28 Nov '16

28 Nov '16

#618: Dependency caching in ghc --make -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): dobenour: SQLite, or really any single file database, could be used, but this would change GHC's compilation model to output some extra files besides the files it normally outputs. I'm a little loathe to do this when we ought to be able to just read out the cached dependencies from the interface files we generate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/618#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5567: LLVM: Improve alias analysis / performance
by GHC 28 Nov '16

28 Nov '16

#5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Have the LLVM devs been asked about this? I think that GHC's use of CPS (and its non-use of the C stack) might be one of the problems. LLVM is designed for C-style code and its optimizations might not fire on the IR that GHC generates. I can think of a solution, but it would involve significant changes, both to the compiler and the RTS. The idea is to do a CPS => SSA transform and then lower to LLVM IR from the SSA form. The Haskell stack would become the C stack, with stack switching handled by the assembler code in `StgRun`. LLVM's GC support would be used to generate stack maps to be read by the RTS for GC purposes. Fortunately, I believe that these tasks are relatively independent. I suspect (from what others have said) that an equivalent of LLVM's `mem2reg` for the STG stack is what is needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5567#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #618: Dependency caching in ghc --make
by GHC 28 Nov '16

28 Nov '16

#618: Dependency caching in ghc --make -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Could SQLite be used as the storage backend for the cache? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/618#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 28 Nov '16

28 Nov '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12884: Parsing of literate files fails because of special character (#)
by GHC 27 Nov '16

27 Nov '16

#12884: Parsing of literate files fails because of special character (#) -------------------------------------+------------------------------------- Reporter: bales | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: literate | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A sharp sign (#) in the documentation part of a literate haskell file causes the parser to fail. As I understand it, any line that doesn't start with a greater-than sign should be ignored. {{{#!hs #+ > module Empty where }}} The previous code leads to the following error: with ghc-7.8.3: Bug.lhs:1:2: lexical error at character '+'[[BR]] with ghc-8.0.1: Bug.lhs:1:1: error: parse error on input ‘#+’ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12884> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12882: Unexpected constraint when using ExistentialQuantification
by GHC 27 Nov '16

27 Nov '16

#12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- Hello! Consider this simple code: {{{ data Elem t = Typeable t => Elem Int tst1 :: forall a. Elem a -> TypeRep tst1 (Elem _) = typeRep (Proxy :: Proxy a) }}} It works and it should work. `Elem` is created only to be sure that if we've got a value of type `Elem t` we don't have to check that `t` is `Typeable`. <offtopic> By the way, exystential newtypes would be so awesome in GHC! </offtopic> And now a strange thing. If we create another function: {{{ tst2 :: forall a. Elem a -> TypeRep tst2 _ = typeRep (Proxy :: Proxy a) }}} GHC throws error that there is no `Typeable a` constraint. The only difference between `tst1` and `tst2` is different pattern binding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12882> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12883: Unexpected constraint when using ExistentialQuantification
by GHC 27 Nov '16

27 Nov '16

#12883: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! Consider this simple code: {{{ data Elem t = Typeable t => Elem Int tst1 :: forall a. Elem a -> TypeRep tst1 (Elem _) = typeRep (Proxy :: Proxy a) }}} It works and it should work. `Elem` is created only to be sure that if we've got a value of type `Elem t` we don't have to check that `t` is `Typeable`. <offtopic> By the way, exystential newtypes would be so awesome in GHC! </offtopic> And now a strange thing. If we create another function: {{{ tst2 :: forall a. Elem a -> TypeRep tst2 _ = typeRep (Proxy :: Proxy a) }}} GHC throws error that there is no `Typeable a` constraint. The only difference between `tst1` and `tst2` is different pattern binding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12753: GHCi/Template Haskell: Don't panic on linker errors.
by GHC 27 Nov '16

27 Nov '16

#12753: GHCi/Template Haskell: Don't panic on linker errors. -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11042 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the link editor is called by `Linker.hs` as part of loading a library and an error occurs GHCi panics. As a consequence users submit bug reports because the panic message tells them do do so. The link editor process can fail because of missing libraries, failure to create a link file, missing linker program, etc., all of which are beyond the control of GHC and should not be considered a bug in GHC. When the link editor fails 1. an error message should be printed and GHC should terminate if the error is fatal. 1. a warning (that could be silenced) should be issued in non-fatal cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial
by GHC 26 Nov '16

26 Nov '16

#11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Look at `CoreUtils.exprIsTrivial` and `CorePrep.cpe_ExprIsTrivial`. They are identical! The latter has a comment saying {{{ cpe_ExprIsTrivial :: CoreExpr -> Bool -- Version that doesn't consider an scc annotation to be trivial. }}} but the code does not treat ticks any differently. So the question is: '''are they supposed to be different'''? And if not, can we just combine them? Peter W, Simon M: this is your territory. I don't understand tick stuff well enough. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38