February 2017 - ghc-tickets

[GHC] #10823: Expose keepAlive to Template Haskell
by GHC 03 Feb '17

03 Feb '17

#10823: Expose keepAlive to Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | 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 Revisions: | -------------------------------------+------------------------------------- {{{keepAlive}}} is a [https://github.com/ghc/ghc/blob/efa7b3a474bc373201ab145c129262a73c86f959/co… function in TcRnMonad] that adds a {{{Name}}} to the set of {{{Name}}}s to keep when pruning out dead code. A concrete use case for exposing this to Template Haskell is in LiquidHaskell, which will soon function as a Core plugin. In LiquidHaskell, a subset of Haskell functions can be "lifted" to the logic level and used in types. For example: {{{ module Test (ok) where [lq| inline gt |] gt x y = x > y [lq| ok :: x:Int -> { v:Int | gt x v } |] ok x = x + 1 }}} LiquidHaskell runs a transformation from the {{{CoreBind}}} for {{{gt}}} to its internal representation of decidable logic. Since Core plugins are run after "dead" code is removed at the end of desugaring, and since {{{gt}}} is not exported, the {{{CoreBind}}} for {{{gt}}} would not reach the {{{CoreBinds}}} LH receives as a Core plugin. The solution for this is to be able to mark names with {{{keepAlive}}} from Template Haskell. Proposed specification: {{{ keepAlive :: Name -> Q () }}} where {{{Name}}} is a Template Haskell {{{Name}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10823> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13229: Add -ddump-inlinings-reasoning
by GHC 03 Feb '17

03 Feb '17

#13229: Add -ddump-inlinings-reasoning -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- It always takes me a while (usually by reading the source code) that `-ddump-inlinings` is not as useful as I want it to be without `-dverbose- core2core`. This just happened to me yesterday. But the latter is very verbose! In changeset:6128b2ffbe36ed2779583e05ee9d817eaafc1c9c Ben documented this behaviour (thanks!) but it is still annoying. Can we not have a flag `-ddump-inlinings-reasoning` that enables the more verbose variant of `-ddump-inlinings` independent of `-dverbose- core2core`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13181: Introduce GHC.TypeNats module with natVal
by GHC 03 Feb '17

03 Feb '17

#13181: Introduce GHC.TypeNats module with natVal -------------------------------------+------------------------------------- Reporter: phadej | Owner: phadej Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- See [https://mail.haskell.org/pipermail/libraries/2017-January/027615.html libraries thread] Currently we have in the GHC.TypeLits module {{{ natVal :: forall n proxy. KnowNat n => proxy n -> Integer }}} However, the result integer is never negative. Numeric.Natural module is in base since base-4.8.0.0. --- I propose that we introduce new module GHC.TypeNats with natVal and natVal' {{{ natVal :: forall n proxy. KnownNat n => proxy n -> Natural }}} and {{{ natVal' :: forall n. KnownNat n => Proxy# n -> Natural }}} and other KnownNat related terms and type families. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13186: Change EvNum to EvNum :: Natural -> EvLit
by GHC 03 Feb '17

03 Feb '17

#13186: Change EvNum to EvNum :: Natural -> EvLit -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature | Status: new request | 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: #8306 #8412 | #13181 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we carry `Nat` kind as an Integer internally. Just changing the type of EvNum (and related isomorphic types like `HsTyLit` etc) does pretty far. The core problem is that we should be able to output Natural literals into Core. Also this would need change to parser, to accept only Naturals in types. Currently negative literals are caught in the renamer (due the fact that template-haskell might inject negative integers as well). This will propagate to template-haskell, changing TyLit there as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 02 Feb '17

02 Feb '17

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.2.1 Comment: It's finally done! Thanks hsyl20! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 02 Feb '17

02 Feb '17

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | 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:D2839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"bbd3c399939311ec3e308721ab87ca6b9443f358/ghc" bbd3c39/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bbd3c399939311ec3e308721ab87ca6b9443f358" Ditch static flags This patch converts the 4 lasting static flags (read from the command line and unsafely stored in immutable global variables) into dynamic flags. Most use cases have been converted into reading them from a DynFlags. In cases for which we don't have easy access to a DynFlags, we read from 'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'. It's not perfect (not thread-safe) but it is still better as we can set/unset these 4 flags before each run when using GHC API. Updates haddock submodule. Rebased and finished by: bgamari Test Plan: validate Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2839 GHC Trac Issues: #8440 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13228: Surprising inlining failure
by GHC 02 Feb '17

02 Feb '17

#13228: Surprising inlining failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- When I fail to mark something seemingly unrelated `INLINE`, something else doesn't inline. In the below (cut down dramatically from my recent lazy ST work), if I don't mark `>>` inline in the `Monad` instance, then `*>` never inlines, and none of the rules fire when compiling `foom` and `basic`. If `>>` is marked inline, then everything works as expected. {{{#!hs module RulesLazy (ST, strictToLazyST, lazyToStrictST) where import qualified Control.Monad.ST as ST -- No, this is not really lazy ST newtype ST s a = ST (s -> (a, s)) instance Functor (ST s) where fmap _ _ = undefined instance Applicative (ST s) where pure _ = undefined _ <*> _ = undefined m *> n = m `thenST` n {-# NOINLINE [1] thenST #-} thenST :: ST s a -> ST s b -> ST s b _ `thenST` _ = ST $ \_ -> undefined instance Monad (ST s) where {-# INLINE (>>) #-} -- CRITICAL LINE m >> n = m `thenST` n _ >>= _ = undefined {-# NOINLINE [1] strictToLazyST #-} strictToLazyST :: ST.ST s a -> ST s a strictToLazyST _ = ST $ \_ -> undefined {-# NOINLINE [1] lazyToStrictST #-} lazyToStrictST :: ST s a -> ST.ST s a lazyToStrictST _ = undefined {-# RULES "then/S2L" forall m n . m `thenST` strictToLazyST n = strictToLazyST (lazyToStrictST m *> n) "L2S/S2L" forall m . lazyToStrictST (strictToLazyST m) = m #-} module RulesBurn where import RulesLazy import qualified Control.Monad.ST as SST {-# NOINLINE foom #-} foom :: SST.ST s a -> SST.ST s b -> SST.ST s c -> ST s c foom m n o = (strictToLazyST m *> strictToLazyST n) *> strictToLazyST o {-# NOINLINE basic #-} basic :: ST s a -> SST.ST s b -> ST s b basic m n = m *> strictToLazyST n }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched
by GHC 02 Feb '17

02 Feb '17

#5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this is out of scope of the pattern match checker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5728#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13098: Template Haskell support for Pattern Synonym's Complete Pragma
by GHC 02 Feb '17

02 Feb '17

#13098: Template Haskell support for Pattern Synonym's Complete Pragma -------------------------------------+------------------------------------- Reporter: magesh.b | Owner: mpickering Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- #8779 provides exhaustive checking support for Pattern Synonym via Complete pragma. https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs It would be nice, if we are able to generate those pragma via TH. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis
by GHC 02 Feb '17

02 Feb '17

#10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | 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: | -------------------------------------+------------------------------------- I would expect GHC to warn of a non-exhaustive pattern match at compile- time when faced with this, {{{#!hs {-# LANGUAGE EmptyCase #-} module Test where test :: Bool -> Int test a = case a of }}} Yet it happily accepts this without complaint. If one attempts to evaluate, e.g., `test True` the expected "Non-exhaustive patterns in case" error is thrown at runtime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29