- ghc-tickets - Haskell.org

[GHC] #15684: Add tests for SIMD loads and stores
by GHC 28 Sep '18

28 Sep '18

#15684: Add tests for SIMD loads and stores -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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 NCG SIMD patch tests most of the arithmetic operations but not loads and stores. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15418: Performance drop 60 times on non-profiling binary
by GHC 27 Sep '18

27 Sep '18

#15418: Performance drop 60 times on non-profiling binary ----------------------------------------+--------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I have a rather large application that I have spent quite some time on tuning it as performance is just too bad. I have come to a point where the profiler reports about 14 seconds on a particular example, which is about 5x slower than I would like to see. However, building the same binary without profiling ability results in that the example takes 14 _minutes_. If I just touch a file and build with profiling information, but not giving it any profiling related RTS options, it takes about 30 seconds (not 14 seconds, but that is probably due to profiling overhead being there). How can performance drop 60x when I basically just relink it? From what I can see using "top" and memory profiling, memory consumption is quite stable over time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[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] #15664: Core Lint error
by GHC 26 Sep '18

26 Sep '18

#15664: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From [https://github.com/VictorCMiraldo/victorcmiraldo.github.io/blob/845e74b59ae… Generic Programming of All Kinds], {{{#!hs {-# Language RankNTypes, TypeOperators, DataKinds, PolyKinds, GADTs, TypeInType, TypeFamilies #-} {-# Options_GHC -dcore-lint #-} -- https://github.com/VictorCMiraldo/victorcmiraldo.github.io/blob/845e74b59ae… import Data.Kind import GHC.Exts import Data.Function data Ctx :: Type -> Type where E :: Ctx(Type) (:&:) :: a -> Ctx(as) -> Ctx(a -> as) type family Apply(kind) (f :: kind) (ctx :: Ctx kind) :: Type where Apply(Type) a E = a Apply(k -> ks) f (a:&:as) = Apply(ks) (f a) as data ApplyT kind :: kind -> Ctx(kind) -> Type where A0 :: a -> ApplyT(Type) a E AS :: ApplyT(ks) (f a) as -> ApplyT(k -> ks) f (a:&:as) type f ~> g = (forall xx. f xx -> g xx) unravel :: ApplyT(k) f ~> Apply(k) f unravel (A0 a) = a unravel (AS fa) = unravel fa }}} gives a core lint error {{{ $ ghci -ignore-dot-ghci hs/443.hs > /tmp/bug.log }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15665: Break up the stable pointer table
by GHC 26 Sep '18

26 Sep '18

#15665: Break up the stable pointer table -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- I see no obvious reason for the stable pointer table to be a single array. Indeed, that leads to all sorts of complications. It smells to me like the simplest thing would be to make it a chain of blocks, and make a `StablePtr#` a real pointer to the relevant entry. No relocation ever! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15679: Use String rather than [Char] where possible
by GHC 26 Sep '18

26 Sep '18

#15679: Use String rather than [Char] where possible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Try this in GHCi {{{ Prelude> :t "foo" "foo" :: [Char] }}} It would be better to say {{{ "foo" :: String }}} Why don't we? Because of this in `TysWiredIn` {{{ stringTy :: Type stringTy = mkListTy charTy -- convenience only }}} That is, where GHC needs `String` is uses `stringTy` which is just `[Char]`. How to fix? Two ways: 1. Make `String` into a "wired-in type". That's not hard, but it increases the number of wired-in types, which is generally undesirable. 2. Make `String` into a "knonw-key name", and look it up in the type environment on the (few) occasions where we need `stringTy`. That's a little harder -- notably `hsLitType` would become monadic -- but not difficult. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15679> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15678: Provide the provenance of unification variables in error messages when possible
by GHC 26 Sep '18

26 Sep '18

#15678: Provide the provenance of unification variables in error messages when possible -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: TypeErrors | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs module Foo where x :: Int x = const 42 _ }}} When compiles, this gives the following suggestion: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Foo ( Bug.hs, Bug.o ) Bug.hs:4:14: error: • Found hole: _ :: b0 Where: ‘b0’ is an ambiguous type variable • In the second argument of ‘const’, namely ‘_’ In the expression: const 42 _ In an equation for ‘x’: x = const 42 _ • Relevant bindings include x :: Int (bound at Bug.hs:4:1) Valid hole fits include x :: Int (bound at Bug.hs:4:1) otherwise :: Bool (imported from ‘Prelude’ at Bug.hs:1:8-10 (and originally defined in ‘GHC.Base’)) False :: Bool (imported from ‘Prelude’ at Bug.hs:1:8-10 (and originally defined in ‘GHC.Types’)) True :: Bool (imported from ‘Prelude’ at Bug.hs:1:8-10 (and originally defined in ‘GHC.Types’)) lines :: String -> [String] (imported from ‘Prelude’ at Bug.hs:1:8-10 (and originally defined in ‘base-4.12.0.0:Data.OldList’)) unlines :: [String] -> String (imported from ‘Prelude’ at Bug.hs:1:8-10 (and originally defined in ‘base-4.12.0.0:Data.OldList’)) (Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno- max-valid-hole-fits) | 4 | x = const 42 _ | ^ }}} One thing that's rather ugly about this is the use of the type `b0`. What exactly //is// `b0` anyway? The only hint that the error message gives is that it's an ambiguous type variable. But that's not terribly helpful to figure out where `b0` arises from. Ambiguous type variables like this one arise quite frequently when writing Haskell code, and it can often take some sleuthing to figure out why they pop up. simonpj had one suggestion for making ambiguous type variables less confusing: report their provenance whenever possible. There is one notable example of a situation where it's simple to explain from where exactly in the source code a unification variable originates: function applications. In particular, the program above applies the function `const 42` to `_`, which means that the type of `const 42` is instantiated to be `b0 -> Int`. Let's report this! Something like: {{{ • Found hole: _ :: b0 Where: ‘b0’ is an ambiguous type variable Arising from an application of (const 42 :: b0 -> Int) In the expression: const 42 _ }}} This would go a long way to clearing up what GHC is thinking when it reports these ambiguous type variable errors. While we can't easily report the provenance of //every// ambiguous type variables, those arising from function applications are quite doable. We might be able to reuse the `CtOrigin` machinery (or take heavy inspiration from it) to accomplish this feat. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15676: Users guide: broken external links
by GHC 26 Sep '18

26 Sep '18

#15676: Users guide: broken external links -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.6.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: -------------------------------------+------------------------------------- Section 10.9 'Type Families' intro has external links to three papers, labelled [AssocDataTypes2005] [AssocTypeSyn2005] [TypeFamilies2008] The links point to http://www.cse.unsw.edu.au/~chak/papers/....html. I get Access Forbidden Error 403. Instead they could point to the microsoft research publications versions(?) (Each is co-authored by Chak and SPJ and others.) But beware some of those are draft versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15676> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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