August 2017 - ghc-tickets

[GHC] #14165: Investigate regressions from simplifier refactor
by GHC 28 Aug '17

28 Aug '17

#14165: Investigate regressions from simplifier refactor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 33452dfc6cf891b59d63fa9fe138b18cbce4df81 (Refactor the Mighty Simplifier) caused test suite regressions under 64-bit Linux and OSX (but not 32-bit Linux or Windows). See the [https://phabricator.haskell.org/B17259 build results]. Under 64-bit Linux: {{{ max_bytes_used value is too high: Expected T1969(normal) max_bytes_used: 16679176 +/-15% Lower bound T1969(normal) max_bytes_used: 14177299 Upper bound T1969(normal) max_bytes_used: 19181053 Actual T1969(normal) max_bytes_used: 19199872 Deviation T1969(normal) max_bytes_used: 15.1 % *** unexpected stat test failure for T1969(normal) bytes allocated value is too high: Expected T12150(optasm) bytes allocated: 70773000 +/-5% Lower bound T12150(optasm) bytes allocated: 67234350 Upper bound T12150(optasm) bytes allocated: 74311650 Actual T12150(optasm) bytes allocated: 74358208 Deviation T12150(optasm) bytes allocated: 5.1 % }}} Under 64-bit OSX: {{{ bytes allocated value is too high: Expected T12150(optasm) bytes allocated: 70773000 +/-5% Lower bound T12150(optasm) bytes allocated: 67234350 Upper bound T12150(optasm) bytes allocated: 74311650 Actual T12150(optasm) bytes allocated: 74503808 Deviation T12150(optasm) bytes allocated: 5.3 % *** unexpected stat test failure for T12150(optasm) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r)
by GHC 28 Aug '17

28 Aug '17

#14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- [https://hackage.haskell.org/package/reflection-2.1.2/docs/Data- Reflection.html#v:give give] from the ''reflection'' library has the following type {{{#!hs give :: forall a r. a -> (Given a => r) -> r }}} but `flip give :: r -> a -> r`! This works with our own `Given`, `give` {{{ $ ghci -ignore-dot-ghci -XRankNTypes GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help Prelude> class Given a Prelude> give :: a -> (Given a => r) -> r; give = undefined Prelude> :t flip give flip give :: c -> a -> c Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14160: Type inference breaking change in GHC 8.0.2
by GHC 28 Aug '17

28 Aug '17

#14160: Type inference breaking change in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- A regression reported by [https://www.reddit.com/r/haskell/comments/6w7grz/type_inference_breaking_ch… Milewski], {{{#!hs {-# LANGUAGE RankNTypes #-} module Test where import Data.Profunctor proj :: Profunctor p => forall c. (forall a. p a a) -> p c c proj e = e f1 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f1 f e = dimap f id (proj e) }}} The regression is that these used to work, but do not currently {{{#!hs -- • Couldn't match type ‘p c0 c0’ with ‘forall a1. p a1 a1’ -- Expected type: p c0 c0 -> p a a -- Actual type: (forall a1. p a1 a1) -> p a a -- • In the second argument of ‘(.)’, namely ‘proj’ -- In the expression: dimap id f . proj -- In an equation for ‘f2’: f2 f = dimap id f . proj -- • Relevant bindings include -- f2 :: (a -> b) -> (forall c. p c c) -> p a b -- (bound at 24:1) f2 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f2 f = dimap id f . proj -- • Cannot instantiate unification variable ‘a0’ -- with a type involving foralls: (forall c. p c c) -> p a b -- GHC doesn't yet support impredicative polymorphism -- • In the expression: undefined -- In an equation for ‘f3’: f3 f = undefined -- • Relevant bindings include -- f :: a -> b -- (bound at 39:4) -- f3 :: (a -> b) -> (forall c. p c c) -> p a b -- (bound at 39:1) f3 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f3 f = undefined -- dimap id f . proj }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14092: hs-boot unfolding visibility not consistent between --make and -c
by GHC 28 Aug '17

28 Aug '17

#14092: hs-boot unfolding visibility not consistent between --make and -c -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: hs-boot. | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- duog's comment in https://phabricator.haskell.org/D3815#107812 pointed out an inconsistency between hs-boot handling in --make and -c that I have been dimly aware of for some time now. Here is how to trigger the situation: {{{ -- A.hs-boot module A where f :: Int -> Int -- B.hs module B where import {-# SOURCE #-} A -- A.hs module A where import B f :: Int -> Int f x = x + 1 -- C.hs module C where import {-# SOURCE #-} A g = f 2 }}} When we run `ghc-head C.hs --make -O -ddump-simpl -fforce-recomp`, we see that f has been successfully inlined: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} g :: Int [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] g = GHC.Types.I# 3# }}} However, if we then one-shot compile C.hs, as in `ghc-head -c C.hs -O -ddump-simpl -fforce-recomp`, the unfolding is not seen: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} C.g1 :: Int [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] C.g1 = GHC.Types.I# 2# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} g :: Int [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] g = f C.g1 }}} The crux of the matter is that `--make` and `-c` have different rules about when to make use of the unfolded definition. The `--make` rule is: compile the modules in some topological order. Any module that comes after `A.hs` sees the improved unfoldings. And as it turns out, the current topological order GHC picks is this: {{{ [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling A ( A.hs, A.o ) [4 of 4] Compiling C ( C.hs, C.o ) }}} The `-c` rule is more complicated. Every module records a list of transitive module dependencies, and whether or not a boot or non-boot was used. We load an hi-boot file if NONE of the modules we imported "saw" the full hi module, AND we only did direct SOURCE imports. If anyone has transitively imported A.hs, we load the hi file. In the example above, C.hs ONLY imports A.hs-boot, so hs-boot is obliged to load A.hi-boot, and thus it does not see the unfolding. The `-c` behavior is the correct behavior, because with the `--make` behavior it is easy to get into a situation where the build is dependent on the topological order chosen. Consider: * `A.hs-boot` * `B.hs-boot` * `A.hs` imports `A.hs-boot`, `B.hs-boot` * `B.hs` imports `A.hs-boot`, `B.hs-boot` (Ignore the fact that in GHC today you can't actually directly import your hs-boot file; you can fix this by importing dummy modules.) Now you can see that depending on the order you compile, e.g., A.hs-boot, B.hs-boot, A.hs, B.hs versus B.hs, A.hs, either A.hs or B.hs will be compiled with the unfoldings for its partner, but not vice versa. This doesn't sound good! Unfortunately, fixing things properly in `--make` mode is quite troublesome. To understand why, we have to first remind ourself about loop retypechecking in make mode. Remember that GHC knot-ties all of the typechecker data structures together (https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TyingTheKnot) This means that at the point we typecheck an hs-boot file, we are building an (immutable) graph on top of the impoverished, type signature only declarations from the hs-boot file. When we finish typechecking the loop closer, the only way to "update" all of the old references to the hs-boot file is to throw out the entire graph and rebuild it from scratch (the loop retypecheck!) So let's think about the A.hs-boot B.hs A.hs C.hs case. At the point we're typechecking A.hs, we throw out the graph referencing A.hs-boot and rebuild it referencing A.hs so that everything gets knot-tied to A.hs. But THEN, C.hs comes around, and it's like, "Oy, I don't want the A.hs version of the graph, I want the A.hs-boot version of the graph." In `-c` mode, this is not a problem, since we have to rebuild the graph from scratch anyway, but in `--make` this is a big deal, since we have to throw everything out and rebuild it AGAIN. One implementation strategy that doesn't involve mucking about with HPT retypechecking is to somehow make the typechecker aware of what unfoldings it should "see" and which it should not. The idea is that if it can ignore unfoldings that it doesn't have legitimate access to, that should be "just as good" as having typechecked against the hs-boot graph itself. But this sounds very tricky and difficult to get right... so here we are. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 25 Aug '17

25 Aug '17

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I can reproduce this on Debian 8 using the i386 GHC 8.2.1 bindist and test program from comment:17. However, I can't reproduce this on x86-64, which should serve as a nice hint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14156: Document the thread wakeup/scheduling/fairness semantics for the STM primitives
by GHC 25 Aug '17

25 Aug '17

#14156: Document the thread wakeup/scheduling/fairness semantics for the STM primitives -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Keywords: stm | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the TSem documentation I saw this: Note that TSem has no concept of fairness, and there is no guarantee that threads blocked in waitTSem will be unblocked in the same order; in fact they will all be unblocked at the same time and will fight over the TSem. Hence TSem is not suitable if you expect there to be a high number of threads contending for the resource. Is this true for all the STM primitives? If so can this be clarified in the documentation for each primitive? Or in the main STM module page and each primitive referring to it. This is an important aspect of the behavior which I believe can sometimes be very important for the user of the library. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14156> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3474: Add a strict variant of iterate to Data.List
by GHC 25 Aug '17

25 Aug '17

#3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 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:D3870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3474#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3474: Add a strict variant of iterate to Data.List
by GHC 25 Aug '17

25 Aug '17

#3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 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:D3870 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"a67b66e663d159c219750a5044ccf553c4b21bdb/ghc" a67b66e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a67b66e663d159c219750a5044ccf553c4b21bdb" Add strict variant of iterate Summary: This closes the nearly-eight-year-old #3474. Test Plan: Validate Reviewers: RyanGlScott, austin, hvr Subscribers: rwbarton, thomie GHC Trac Issues: #3474 Differential Revision: https://phabricator.haskell.org/D3870 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3474#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14000: Out of scope errors with type families do not mention scope
by GHC 25 Aug '17

25 Aug '17

#14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TypeFamilies #-} class C a where type T a c :: a -> T a main = c noSuchThing }}} yields: {{{ test_bad_error.hs:6:1: error: • Couldn't match expected type ‘T a’ with actual type ‘T a0’ NB: ‘T’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for the inferred type for ‘main’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type main :: forall a. T a }}} This makes simple out-of-scope error seem very perplexing and is a huge regression in error quality. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14075: GHC panic with parallel make
by GHC 25 Aug '17

25 Aug '17

#14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13803, #13981 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following modules: {{{#!hs -- F.hs module F () where }}} {{{#!hs -- F.hs-boot module F where import O (O) newtype F = F () instance O F where }}} {{{#!hs -- O.hs module O (O) where class O a where }}} {{{#!hs -- V.hs module V () where import {-# SOURCE #-} F () }}} {{{#!hs -- V.hs-boot module V where }}} If I try to compile this with {{{ ghc -j2 F O V }}} I get {{{ [1 of 4] Compiling O ( O.hs, O.o ) [2 of 4] Compiling F[boot] ( F.hs-boot, F.o-boot ) [3 of 4] Compiling F ( F.hs, F.o ) <no location info>: error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170720 for x86_64-unknown-linux): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing F which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find F in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [r1hL :-> Identifier ‘$trModule’] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} On the other hand {{{ ghc -j1 F O V }}} works just fine, and gives the expected {{{ [2 of 5] Compiling O ( O.hs, O.o ) [3 of 5] Compiling F[boot] ( F.hs-boot, F.o-boot ) [4 of 5] Compiling F ( F.hs, F.o ) F.hs-boot:7:1: error: ‘F.F’ is exported by the hs-boot file, but not exported by the module | 7 | newtype F = F () | ^^^^^^^^^^^^^^^^ F.hs:1:1: error: instance O.O F.F -- Defined at F.hs-boot:8:10 is defined in the hs-boot file, but not in the module itself | 1 | -- F.hs | ^ }}} The example is a little bit sick, in that the original code is not expected to compile. I run into this by accident when trying to construct a minimal example of the issue reported in #13803 (note that that bug is marked as closed, but the original issue reported there remains unfixed, I am trying to construct a minimal testcase for the original issue there). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9