- ghc-tickets - Haskell.org

Re: [GHC] #8025: -fno-code and Template Haskell are incompatible
by GHC 24 Aug '17

24 Aug '17

#8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3441 Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I agree that having the ability to override the current behaviour would be useful, but I don't think that overloading -fobject-code to do it is right. I would suggest that we need an "-fno-code-auto" flag. Currently, when we are deciding which modules to codegen in GhcMake.enableCodegenForTH, we take all transitive dependencies of modules that use -XTemplateHaskell. We could instead take all transitive dependencies (where those dependencies don't disable -fno-code-auto) of modules that use -XTemplateHaskell. I think it would make sense to disable -fno-code-auto by default if we improved the error message to suggest it be enabled. One could just add {-# OPTIONS_GHC -fno-code-auto #-} to the modules that need to be codegenned. Separately, a flag -fno-code-target={default,interpreted,asm(?),llvm(?)} should perhaps be added to determine the method of codegen. This would enable us to use interpreted by default, again provided that errors from, for example, unboxed tuples, suggested the user change it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 23 Aug '17

23 Aug '17

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by enolan): * cc: enolan (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14147: Confusing error messages with PolyKinds and superclasses
by GHC 23 Aug '17

23 Aug '17

#14147: Confusing error messages with PolyKinds and superclasses -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This program compiles fine: {{{#!hs {-# LANGUAGE FlexibleInstances #-} import Data.Typeable newtype Tagged t v = Tagged v deriving Typeable class (Typeable t) => MyClass t where classF :: t -> Int instance Typeable t => MyClass (Tagged t Int) where classF (Tagged n) = n }}} But if I add `PolyKinds` to the `LANGUAGE` pragma I get: {{{ code/junk/typeable-problems.hs:17:10: error: • Could not deduce (Typeable k) arising from the superclasses of an instance declaration from the context: Typeable t bound by the instance declaration at code/junk/typeable-problems.hs:17:10-45 • In the instance declaration for ‘MyClass (Tagged t Int)’ | 17 | instance Typeable t => MyClass (Tagged t Int) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Which is very confusing since I don't have a `k` variable anywhere. Adding `-fprint-explicit-kinds` is somewhat better: {{{ code/junk/typeable-problems.hs:17:10: error: • Could not deduce (Typeable * k) arising from the superclasses of an instance declaration from the context: Typeable k t bound by the instance declaration at code/junk/typeable-problems.hs:17:10-45 • In the instance declaration for ‘MyClass (Tagged k t Int)’ | 17 | instance Typeable t => MyClass (Tagged t Int) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But still confusing. It doesn't really point me towards the solution - specifying that the kind of t is `*` explicitly - if I don't already know how the extension works. It's also annoying that turning on an extension causes a type error, but I don't know if that's fixable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Aug '17

23 Aug '17

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion 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 pggiarrusso): If anybody is unaware and interested: the latest work on the topic is "Stream Fusion, to Completeness" (https://strymonas.github.io/) and in Sec. 8 it seems to claim advantages relative to the HERMIT work (though I've only skimmed this), so that might be relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13702: GHC can't produce position independent executables
by GHC 23 Aug '17

23 Aug '17

#13702: GHC can't produce position independent executables -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Due to #12759 we unconditionally pass `-no-pie` to GCC. However, there are legitimate reasons to want a PIE. We should have a `-fPIE` flag to match `-fPIC`, requesting that the compiler produce a position-independent executable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14148: initTc: unsolved constraints
by GHC 23 Aug '17

23 Aug '17

#14148: initTc: unsolved constraints --------------------------------------+---------------------------------- Reporter: robertpergl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- || ghc: panic! (the 'impossible' happened) || (GHC version 8.0.2 for x86_64-unknown-linux): || initTc: unsolved constraints || WC {wc_insol = || [W] ltail_ae2e :: t_ae2d[tau:1] (CHoleCan: ltail) || [W] lhead_ae2h :: t_ae2g[tau:1] (CHoleCan: lhead)} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #8025: -fno-code and Template Haskell are incompatible
by GHC 23 Aug '17

23 Aug '17

#8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3441 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Saizan): This is great, but in some cases generating code for all the imported modules is too much. Would it make sense to have {-# OPTIONS_GHC -fobject-code #-} change the HscTarget for the module, so that authors can fine-tune for which modules code needs to be generated? (together the old behavior of -fno-code, I mean) Currently having that pragma seems to have no effect. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14142: Can't invert -dno-debug-output
by GHC 23 Aug '17

23 Aug '17

#14142: Can't invert -dno-debug-output -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- `mk/flavours/validate.mk` sets {{{ GhcStage2HcOpts = -dno-debug-output }}} and there is no way to undo it. E.g. you can't add {{{ GhcStage2HcOpts += -ddebug-output }}} to your `mk/validate.mk` does not work. We should add `-ddebug-output` to invert it. Easy task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14142> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Aug '17

23 Aug '17

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion 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 sgraf): Replying to [comment:50 simonpj]: > > if we would employ some other mechanism than rewrite rules to specialise call sites > > I don't know what you have in mind here. Would you care to elaborate? Right, that's quite a bummer. I'll probably have to develop a deeper understanding of how `SpecConstr` and the rewrite rule mechanism works before I can answer this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Aug '17

23 Aug '17

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion 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 simonpj): > if we would employ some other mechanism than rewrite rules to specialise call sites I don't know what you have in mind here. Would you care to elaborate? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0