September 2016 - ghc-tickets

[GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent)
by GHC 29 Sep '18

29 Sep '18

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: Architecture: Unknown/Multiple | Operating System: Difficulty: Project (more than a week) | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: 635, 7353 | None/Unknown | Test Case: | Blocking: ----------------------------------------------+---------------------------- This is mainly a reference discussion ticket. libuv (https://github.com/joyent/libuv) is a lightweight library which allows asynchronous IO across OpenBSD, Linux, Darwin, Windows etc by utilizing the fastest implementation on each system (epoll, kqueue, IOCP, event ports). These specialized IO polling methods are '''much''' faster on their respective platforms than just using select() like the RTS currently does. Additionally, it also provides cross platform threads, mutex, condition vars, terminal input/output and term settings w/ cross platform ANSI escape code handling, thread pools, cross platform HRC's etc. It's currently significantly faster than libevent and slightly faster than libev (and no doubt faster than rolling our own stuff). Because it's maintained and utilized heavily by Node.js it's in extremely active and maintained development. Rewriting a portion of the RTS to utilize libuv would have the following benefits; * We could ditch basically all of our platform specific code. Everything under rts/win32 and rts/posix, except the SEH stuff, could be deleted. * libuv is tuned for speed on each platform. This would be an optimization to all our async IO stuff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #12178: Allow inline pragmas on pattern synonyms
by GHC 28 Sep '18

28 Sep '18

#12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Richard observes that it might be useful to allow inline pragmas to refer to pattern synonyms to ensure that the matcher is inlined. The main question to resolve is whether `{-# INLINE P #-}` means to inline just the matcher, just the builder or both. It seems that without more fine grained control then the pragma should cause both the matcher and builder to be inline but I am not certain about this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8809: Prettier error messages?
by GHC 27 Sep '18

27 Sep '18

#8809: Prettier error messages? ------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `clang` has very nice-looking error messages. {{{ #!html <pre>pretty.c:6:7: warning: incompatible pointer to integer conversion passing 'char [14]' to parameter of type 'int' [-Wint-conversion] foo("Hello, world!"); ^~~~~~~~~~~~~~~ pretty.c:1:14: note: passing argument to parameter 'i' here void foo(int i) { ^ 1 warning generated.</pre> }}} `ghc`'s error messages are not so good. {{{ #!html <pre>ugly.hs:7:18: Couldn't match expected type ‘()’ with actual type ‘[Char]’ In the first argument of ‘f’, namely ‘"Hello, world!"’ In the second argument of ‘($)’, namely ‘f "Hello, world!"’ In the expression: print $ f "Hello, world!"</pre> }}} In my opinion, there are three independent improvements that could be made to GHC error messages and warnings: color, context and whitespace. Currently they're blobs of text. Consider all three applied to error messages: {{{ #!html <pre>ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int' main = print $ f "Hello, world!" ^~~~~~~~~~~~~~~ ugly.hs:3:1: note: type of 'f' is given here: f :: () -> IO () ^~</pre> }}} or {{{ #!html <pre>ugly.hs: note: type of 'f' is inferred: f :: forall m. Monad m => () -> m () ^~</pre> }}} In my opinion, context and whitespace are more important that color. Even without color, compare this error message to the one shown above: {{{ ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int' main = print $ f "Hello, world!" ^~~~~~~~~~~~~~~ ugly.hs:3:1: note: type of 'f' is given here: f :: () -> IO () ^~ }}} In my opinion this is much easier to visually process than GHC's current messages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8809> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 79

[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] #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] #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

[GHC] #11295: Figure out what LLVM passes are fruitful
by GHC 19 Sep '18

19 Sep '18

#11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (LLVM) | 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: -------------------------------------+------------------------------------- Builds using GHC's LLVM backend are currently substantially slower than GHC's own native code generator. There are a few possible reasons for this, 1. the cost of forking processes and serializing/parsing LLVM's intermediate representation 2. the cost of the more powerful optimizations responsible for LLVM's (hopefully) better code generation 3. the cost of redundant optimizations overlapping effort already expended by GHC Given that some architecture (e.g. ARM) are only supported by LLVM and therefore suffer considerably at the hand of our slow builds, we should try to reduce # -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20