February 2018 - ghc-tickets

[GHC] #14823: Test profiling/should_run/scc001 fails on Circle CI
by GHC 21 Apr '18

21 Apr '18

#14823: Test profiling/should_run/scc001 fails on Circle CI -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The test profiling/should_run/scc001 fails on CI: {{{#!hs module Main (main) where main :: IO () main = do print $ f True print $ g 3 print $ h 'a' f :: a -> a f x = x g :: Int -> Int g x = x h :: Char -> Char Just h = Just id }}} And it outputs: {{{ True 3 ghc-stage2: ghc-iserv terminated (-11) }}} instead of {{{ True 3 'a' }}} I guess I'll mark it as an expected failure for now in my PR. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14823> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14698: Cut STM release
by GHC 21 Apr '18

21 Apr '18

#14698: Cut STM release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14706: T11489 fails if run as root
by GHC 21 Apr '18

21 Apr '18

#14706: T11489 fails if run as root -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.5 Integration | 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 testcase `T11489` tests for #11489 by creating a `.prof` file, removing its write bit, and trying to run a program with profiling enabled. Usually the program would fail with an error message as the RTS can't open the `.prof` file for writing. However, when run as `root` the test succeeds. "What madman would compile GHC as `root`?" you ask? Well, CircleCI runs builds as `root` by default. It seems like running builds under Docker is one way around this, although this seems like a pretty large hammer just to eliminate a single test failure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14704: Spurious cost-centre test failures
by GHC 21 Apr '18

21 Apr '18

#14704: Spurious cost-centre test failures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.2.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: -------------------------------------+------------------------------------- CircleCI seems to routinely turn up spurious differences in cost-center profiler tests, {{{patch --- ./profiling/should_run/scc003.run/scc003.prof.sample.normalised 2018-01-22 18:57:35.961616901 +0000 +++ ./profiling/should_run/scc003.run/scc003.prof.normalised 2018-01-22 18:57:35.961616901 +0000 @@ -1,6 +1,6 @@ MAIN MAIN <built-in> 0 f Main scc003.hs:5:1-41 1 -f.(...) Main scc003.hs:5:11-21 1 -fib Main scc003.hs:8:1-50 21891 f.\ Main scc003.hs:5:32-41 1 fib Main scc003.hs:8:1-50 2692537 +f.x' Main scc003.hs:5:11-21 1 +fib Main scc003.hs:8:1-50 21891 --- ./profiling/should_run/scc003.run/scc003.prof.sample.normalised 2018-01-22 18:57:37.321632723 +0000 +++ ./profiling/should_run/scc003.run/scc003.prof.normalised 2018-01-22 18:57:37.321632723 +0000 @@ -1,6 +1,6 @@ MAIN MAIN <built-in> 0 f Main scc003.hs:5:1-41 1 -f.(...) Main scc003.hs:5:11-21 1 -fib Main scc003.hs:8:1-50 21891 f.\ Main scc003.hs:5:32-41 1 fib Main scc003.hs:8:1-50 2692537 +f.x' Main scc003.hs:5:11-21 1 +fib Main scc003.hs:8:1-50 21891 --- ./profiling/should_run/T12962.run/T12962.prof.sample.normalised 2018-01-22 18:57:46.241736499 +0000 +++ ./profiling/should_run/T12962.run/T12962.prof.normalised 2018-01-22 18:57:46.241736499 +0000 @@ -1,4 +1,4 @@ MAIN MAIN <built-in> 0 -blah Main T12962.hs:15:1-22 1 -niz3 Main T12962.hs:12:1-27 1 -foo Main T12962.hs:8:1-21 100 +blah Main T12962.hs:19:1-22 1 +niz3 Main T12962.hs:16:1-27 1 +foo Main T12962.hs:12:1-21 100 --- ./profiling/should_run/T12962.run/T12962.prof.sample.normalised 2018-01-22 18:57:47.209747760 +0000 +++ ./profiling/should_run/T12962.run/T12962.prof.normalised 2018-01-22 18:57:47.209747760 +0000 @@ -1,4 +1,4 @@ MAIN MAIN <built-in> 0 -blah Main T12962.hs:15:1-22 1 -niz3 Main T12962.hs:12:1-27 1 -foo Main T12962.hs:8:1-21 100 +blah Main T12962.hs:19:1-22 1 +niz3 Main T12962.hs:16:1-27 1 +foo Main T12962.hs:12:1-21 100 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11735: Optimize coercionKind
by GHC 20 Apr '18

20 Apr '18

#11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Currently, the `ForAllCo` case of `coercionKind` does an inefficient one- variable substitution. This could be improved by looking for nested `ForAllCo`s. Furthermore, perhaps we don't need an in-scope set and the full substitution machinery here. The subst is simply propagating the update of a tyvar's kind. No structural changes at all. No need for smart coercion constructors or other processing. So if we're going to optimize this, it might be worth making a specialized version of `subst_ty` and `subst_co` that operate over a `VarEnv Var` instead of a full substitution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 87

[GHC] #13380: raiseIO# result looks wrong
by GHC 20 Apr '18

20 Apr '18

#13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `primops.txt.pp` includes the following note: > `raiseIO#` needs to be a primop, because exceptions in the `IO` monad must be ''precise'' - we don't want the strictness analyser turning one kind of bottom into another, as it is allowed to do in pure code. > > But we ''do'' want to know that it returns bottom after being applied to two arguments, so that this function is strict in `y` > {{{#!hs > f x y | x>0 = raiseIO blah > | y>0 = return 1 > | otherwise = return 2 > }}} I believe the "But we do" portion is, unfortunately, entirely wrong. From a user perspective, it is extremely strange to replace a precise exception with an imprecise one. That is, I strongly believe the above code should be considered ''lazy'' in `y`. The function `f` calculates an `IO` action; the value of `y` is only necessary to calculate that action if `x` is non- positive. We can, conservatively, say for certain that the second component of the result of `raiseIO#` (i.e., the "return value") is bottom. We can also say, given {{{#!hs case raiseIO# e s of (# s', r #) -> q }}} that `q` is dead (we could replace it by `(# s', undefined #)`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13276: Unboxed sums are not Typeable
by GHC 20 Apr '18

20 Apr '18

#13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: Ben Gamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While the Typeable machinery introduce in the type-indexed Typeable rework (#11011) is fully capable of representing unboxed sums, we currently don't allow this since it would require that we generate an enormous number of bindings in `GHC.Types`. This is because we need to generate both `TyCon` and `KindRep` bindings for each type constructor and its promoted data constructors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13261: Consider moving Typeable evidence generation wholly back to solver
by GHC 20 Apr '18

20 Apr '18

#13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new 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: -------------------------------------+------------------------------------- Since 91c6b1f54aea658b0056caec45655475897f1972 we have generated a set of bindings with each datatype definition which the compiler will refer to when constructing `Typeable` evidence. As described in the commit message, this came with a rather significant performance penalty, especially given that it is paid regardless of whether the code being compiled uses `Typeable`. The type-indexed Typeable implementation (#11011) augments these bindings with additional information allowing the kind of a type of be reconstructing at runtime (#10343). Unfortunately, this further blows up the cost of associated with Typeable binding generation. Some of the testsuite regressions are hard to swallow to say the least. While I'm still working out what can be done to reduce this cost, I do wonder whether the generating these bindings at the time of type definition is so wise. Relatively few users make use of Typeable and the cost is not negligible. Moreover, generating bindings for families of tycons (e.g. unboxed sums, which have thousands of type constructors and promoted data constructors) all at once produces a truly massive amount of code (albeit it only has to be done once). On the other hand, I suppose if Richard's dependent types story comes to fruition then perhaps the weight imposed by generating Typeable bindings at type-definition time might pull its weight. Anyways, just idle reflections. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13450: Better parse error for empy character literal
by GHC 20 Apr '18

20 Apr '18

#13450: Better parse error for empy character literal -------------------------------------+------------------------------------- Reporter: parsonsmatt | 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: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Empty character literals give an obscure error message. As an example, this code: {{{#!hs example = foo : bar where foo = '' bar = "asdf" }}} gives the following error when loaded in GHCi: {{{ err.hs:4:6: parse error (possibly incorrect indentation or mismatched brackets) }}} This has affected me once, as a beginner. I've seen it affect a few other beginners, and the error message isn't very helpful to figuring out what's wrong. It would be nice if a better error message could be reported. If there's a parse error on `''`, then GHC could report something like: {{{ err.hs:3:11: parse error on `''`. Note: Character literals may not be empty. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10037: Several profiling tests give different results optimised vs. unoptimised
by GHC 20 Apr '18

20 Apr '18

#10037: Several profiling tests give different results optimised vs. unoptimised -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Profiling | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Most of the differences are relatively harmless (mostly CAF attribution), but it would be nice to get this right. In the meantime I'll mark them expect_broken and point to this ticket. The following tests in `tests/profiling/should_run` are affected: {{{ scc001 T2552 ioprof callstack001 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5