September 2017 - ghc-tickets

[GHC] #13147: Formatting is broken in Exceptions section of GHC.Prim haddock
by GHC 26 Sep '18

26 Sep '18

#13147: Formatting is broken in Exceptions section of GHC.Prim haddock -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something seems to have gone wrong with how this documentation is rendered to HTML. https://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#g:14 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken
by GHC 26 Sep '18

26 Sep '18

#10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- In TcDefaults.hs, `tcDefaults` is supposed to check whether the supplied default type is an instance o `Num` or `IsString` (note the lack of extended defaults here, so this has been broken for quite some time). Following the code we can see that `simplifyDefault` in TcSimplify.hs calls `reportAllUnsolved` and it does report the error -- with typechecker tracing on we see {{{ Adding error: <interactive>:19:1: error: No instance for (Num []) arising from a 'default' declaration When checking the types in a default declaration }}} But typechecking never actually fails, so it returns `Just ()` regardless and the error gets swallowed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12848: Reduce long-term memory usage of GHCi
by GHC 25 Sep '18

25 Sep '18

#12848: Reduce long-term memory usage of GHCi ---------------------------------------+-------------------------- Reporter: arybczak | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+-------------------------- If you take moderately sized Haskell project (let's use lens as an example) and decide to work with it using `cabal repl`, memory usage of GHCi becomes a bit problematic after a few code reloads. I compared 7.10.3 and 8.0.1 using the following steps: 1. Start GHCi with `cabal repl`. 2. Wait for all modules to load, check memory usage with `htop`. 3. Issue `find . -name '*.hs' -exec touch {} +` in src directory. 4. Issue `:r` in GHCi so it reloads all modules. 5. Repeat (3) and (4) four more times. Results: '''GHC 7.10.3''' * After `cabal repl`: 874MB * After reloading all modules (1st): 1304MB * After reloading all modules (2nd): 1763MB * After reloading all modules (3rd): 2216MB * After reloading all modules (4th): 2672MB * After reloading all modules (5th): 3121MB Basically, every time modules are reloaded memory usage increases by ~450MB, which is definitely not fun. '''GHC 8.0.1''' * After `cabal repl`: 1322MB * After reloading all modules (1st): 2144MB * After reloading all modules (2nd): 2201MB * After reloading all modules (3rd): 2208MB * After reloading all modules (4th): 2212MB * After reloading all modules (5th): 2213MB Here the initial memory usage is much higher as with 7.10.3 and there is a sharp increase after first full reload, but then it more or less plateaus. I presume this change is the result of 6ae616f5be1db6da8bc0c5e36736a76cfea46844 - upfront memory usage is probably higher due to more things being forced (and the fact that memory usage doesn't increase indefinitely is great). However, I'm still concerned about the spike after the first reload - would it be possible to get rid of (or at least decrease) it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees"
by GHC 25 Sep '18

25 Sep '18

#14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- = The basic Ideas Currently GHC uses Augustssons algorithm for pattern matching which was published in 85 which works fine for many cases. However there has been research on how to do better than that for a while now. Most notably by Maranget in "Compiling Pattern Matching to Good Decision Trees". I plan to look into applying his ideas to GHC for my undergraduate thesis. Thanks to imprecise exceptions we should be able to reorder argument evaluation as long as this doesn't make our programs more strict. Proofing that is high on my bucket list but hasn't been done yet. = Pros and Cons **Advantages** would be: * It should lead to equal or better code for the vast majority of patterns. * It might reduce compile times for cases were we can desugar directly to good code. **Disadvantages**: * Desugaring gets more complex. It' obvious that since the underlying algorithm is more complex the desugarer would also grow in complexity in accordance. It is hard to say in advance how much of a difference it will make but I hope it won't be too bad. Depending on the runtime of the new algorithm compared to the old one this might also speed up compilation for cases where the old algorithm generated code that had to be heavily optimized by the simplifier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8578: Improvements to SpinLock implementation
by GHC 25 Sep '18

25 Sep '18

#8578: Improvements to SpinLock implementation ------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The SpinLock implementation has a number of deficiencies. Here is a pair of patches that improves its implementation. Let me know what you think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10193: TypeRep Show instance doesn't add parens around type operators
by GHC 24 Sep '18

24 Sep '18

#10193: TypeRep Show instance doesn't add parens around type operators -------------------------------------+------------------------------------- Reporter: | Owner: pawel.nowak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc3 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Incorrect result Keywords: | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code {{{#!hs {-# LANGUAGE AutoDeriveTypeable #-} {-# LANGUAGE TypeOperators #-} import Data.Typeable data a :*: b = Pair a b main = print (typeOf (Pair 'a' 'b')) }}} prints {{{#!hs :*: Char Char }}} which is not valid Haskell. I belive it should print {{{#!hs (:*:) Char Char }}} In my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation: {{{#!hs let type_str = show $ Data.Typeable.typeOf wit ... let expr_typesig = concat [parens e, " :: ", type_str] }}} What results in a parse error. I can write a patch if someone confirms that's the desired behavior and doesn't break anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11155: Trivial error thunk gives "undefined reference to stg_ap_0_upd_info"
by GHC 23 Sep '18

23 Sep '18

#11155: Trivial error thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- This error popped up when Alan was coding the solution for #11028. The error is utterly unrelated to what Alan was working on. Here's a reproducer {{{ {-# OPTIONS_GHC -O -fno-full-laziness #-} module Main where foo :: Bool {-# NOINLINE foo #-} foo = error "rk" bar x = let t :: Char t = case foo of { True -> 'v'; False -> 'y' } in [t] main = print (bar ()) }}} Just compile that and you get {{{ Foo.o: In function `c1Sm_info': (.text+0x29a): undefined reference to `stg_ap_0_upd_info' }}} Why do we get that unresolved symbol? The STG code for `bar` looks like {{{ Main.bar :: forall t_aup. t_aup -> [GHC.Types.Char] [GblId, Arity=1, Str=DmdType <L,A>m2, Unf=OtherCon []] = \r srt:SRT:[rf :-> Main.foo] [x_s1RR] let { sat_s1RT [Occ=Once] :: GHC.Types.Char [LclId, Str=DmdType] = \u srt:SRT:[rf :-> Main.foo] [] Main.foo; } in : [sat_s1RT GHC.Types.[]]; }}} Look at that: an updatable thunk saying `sat_s1RT = Main.foo`! The error message is terrible, but the problem is a thunk whose only payload is a single variable. Why does that happen? The Core is {{{ bar = \ (@ t_aup) _ -> let t::Char = case foo of wild_00 { } in : @ Char t ([] @ Char) }}} The `case` is needed to change `foo`'s type from `Bool` to `Char`. The Core-to-STG pass drops the empty case alternatives as useless (rightly), but leaves a bare variable as the RHS, which confuses the code generator. We should clearly substitute `Main.foo` for `t`, either in Core-to-STG, or during code generation. Why hasn't this happened before now? It is quite hard to provoke, because floating the thunk for `t` to top level stops it happening. So it only happens if you switch off full laziness (as my test case here does), or if some very delicate inlining happens after the last float-out. The latter is very rare, but it's what happened to Alan. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8281: The impossible happened: primRepToFFIType
by GHC 21 Sep '18

21 Sep '18

#8281: The impossible happened: primRepToFFIType -----------------------------------+--------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I ran into this error while trying to use GHCi on the hashable package: {{{ $ cabal repl Preprocessing library hashable-1.2.0.10... GHCi, version 7.6.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 package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading object (static) dist/build/cbits/fnv.o ... done Loading object (static) dist/build/cbits/getRandomBytes.o ... done final link ... done [1 of 4] Compiling Data.Hashable.RandomSource ( Data/Hashable/RandomSource.hs, interpreted ) [flags changed] [2 of 4] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, interpreted ) [flags changed] ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-apple-darwin): primRepToFFIType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #13700: GHCi command listing possible type class instances
by GHC 21 Sep '18

21 Sep '18

#13700: GHCi command listing possible type class instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- This is a reminder ticket, I want to be able to list possible instances, {{{ >>> :insts Product (Functor f, Functor g) => Functor (Product f g) (Applicative f, Applicative g) => Applicative (Product f g) ... >>> :insts Product Identity Functor g => Functor (Product Identity g) Applicative g => Applicative (Product Identity g) Monad g => Monad (Product Identity g) MonadFix g => MonadFix (Product Identity g) MonadZip g => MonadZip (Product Identity g) ... >>> :insts Product Identity Identity Functor (Product Identity Identity) Applicative (Product Identity Identity) Monad (Product Identity Identity) MonadFix (Product Identity Identity) MonadZip (Product Identity Identity) }}} Would be so useful for `GeneralizedNewtypeDeriving` {{{#!hs newtype Pair a = P (Product Identity Identity a) deriving (Functor, Applicative, Monad, MonadFix, MonadZip, ...) -- pattern (:#) :: a -> a -> Pair a -- pattern a1 :# a2 = P (Identity a1 `Pair` Identity a2) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11671: Allow labels starting with uppercase with OverloadedLabels
by GHC 21 Sep '18

21 Sep '18

#11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- The following program {{{#!hs {-# LANGUAGE OverloadedLabels, DataKinds, FlexibleInstances, MultiParamTypeClasses #-} import GHC.OverloadedLabels instance IsLabel "Three" Int where fromLabel _ = 3 test :: Int test = #Three main :: IO () main = print test }}} fails to compile in ghc 8.0 with a parse error (while it works as expected if we replace "Three" -> "three"). This may be a conscious design decision, but if not I figured I would ask if it would be possible to allow such labels starting with uppercase letters. I run into this when working on adding support for OverloadedLabels to the gobject-introspection bindings (autogenerated bindings for gtk, etc.), where it would be natural in a few places to write overloaded labels starting with a capital letter. Not hugely important, but sometimes aesthetically more pleasing (imho), and I am not aware of a good reason to forbid them. Perhaps there is one? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18