January 2018 - ghc-tickets

Re: [GHC] #7398: RULES don't apply to a newtype constructor
by GHC 29 Jan '18

29 Jan '18

#7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418, | Differential Rev(s): #13290 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7398: RULES don't apply to a newtype constructor
by GHC 29 Jan '18

29 Jan '18

#7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418, | Differential Rev(s): #13290 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.6.1 Comment: I'm adding a milestone because I suspect we may have enough machinery to make this work . Consider this code: {{{#!hs import Data.Functor.Identity import Data.Coerce hello :: (a -> b) -> a -> b hello f x = f x {-# INLINE [1] hello #-} {-# RULES "not good" forall (f :: Identity a -> a) x. hello f (Identity x) = x "also bad" forall f (x :: a). hello f (Identity x :: Identity a) = x "yes good" forall (f :: Identity a -> a) x. hello f (coerce x) = x "also good" forall f (x :: a) . hello f (coerce x :: Identity a) = x "just fine" forall f (x :: a). hello f (coerce @a @(Identity a) x) = x #-} test :: (Identity a -> a) -> a -> a test f x = hello f (Identity x) {-# NOINLINE test #-} }}} The rule labeled "not good" doesn't fire, but the one labeled "yes good" fires. The only difference is the spelling of `coerce`! This seems to suggest that we can apply some of the machinery for `coerce` rules to sometimes make good things happen. In particular, it seems likely that after type checking the rule, we can simply replace each `newtype` constructor/accessor with an appropriately typed invocation of `coerce`, and make the rules engine work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2893: Implement "Quantified contexts" proposal
by GHC 28 Jan '18

28 Jan '18

#2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedContexts Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've build an implementation of `QuantifiedConstraints`, held on `wip/T2893`. Here's the commit message {{{ commit dbcf8d0b9076ae32b9138623eb84f67c18ed3dab Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Sat Jan 27 14:32:34 2018 +0000 Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * TcSMonad.InertCans gets an extra field, inert_insts, which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Still to come - User manual documentation - A GHC Proposal }}} I'll try to get it up on Phabricator on Monday, unless someone would care to beat me to it. Please give it a try! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14716: indexM-style accessor for arrays?
by GHC 28 Jan '18

28 Jan '18

#14716: indexM-style accessor for arrays? -------------------------------------+------------------------------------- Reporter: Zemyla | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 8.2.2 (other) | Keywords: array | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Pretty much everything I've seen being done with basic `Array`s says something along the lines of "You have to force the argument; otherwise, you get a thunk that holds a reference to the array". An example of that is `fromArray` in `Data.Sequence`. But it really shouldn't be this way. The `Array` from `primitive` and the `Vector`s from `vector` have ways of obtaining a value from an array that doesn't leave a thunk hanging around. The basic prototype is {{{#!hs indexArrayM :: Monad m => Array a -> Int -> m a }}} And having this sort of thing available for standard `Array`s would be useful because `Array` is one of the first packages users see when they look for something like arrays in Haskell. Also, it's tagged `Trustworthy`, unlike `primitive` or `vector`, and there are references to them in `containers`, which is again a package lots of people use. It'd also mean that the `Functor`, `Foldable`, and `Traversable` instances don't leak memory. As a sort-of-related side note, we should also have a function `(!?)`, which functions like the similarly-named function in `vector`, and has the signature {{{#!hs (!?) :: (IArray a e, Ix i) => a i e -> i -> Maybe e }}} This would, in addition to not leaving a thunk when the `Maybe` is deconstructed, also eliminate a common use pattern when it comes to arrays: The user of `(!)` checks the bounds of the array, does something if it's outside, then passes the index to `(!)` which... checks the bounds again. Having a function which works like `lookup` on `Map`s would be a boon here. Having this work for all `IArray`s, not just `Array`, would require a new function in the `IArray` typeclass, which might break existing packages that derive a new `IArray`. However, the function added could be along the lines of: {{{#!hs unsafeAtM :: (Applicative f, Ix i) => a i e -> i -> f e unsafeAtM a i f = pure (unsafeAt a i) }}} which would be a default that, while it doesn't grant the benefits of using a monadic-type accessor, would ensure the code doesn't break while the packages that use/derive it are upgraded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3070: floor(0/0) should not be defined
by GHC 28 Jan '18

28 Jan '18

#3070: floor(0/0) should not be defined -------------------------------------+------------------------------------- Reporter: carette | Owner: squadette Type: bug | Status: new Priority: lowest | Milestone: Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9276 | Blocking: Related Tickets: #10754 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by cblp): * cc: cblp (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3070#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10754: truncate /= double2Int
by GHC 28 Jan '18

28 Jan '18

#10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: truncate, | Operating System: Unknown/Multiple double2Int, rewrite, rule | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- There is a rule in libraries/base/GHC/Float.hs: {{{#!hs "truncate/Double->Int" truncate = double2Int }}} But it is not true for some values. Particularly, {{{#!hs let infinity = 1/0 :: Double truncate infinity :: Int == 0 double2Int infinity == -9223372036854775808 -- minBound }}} As a result, the value of {{{truncate (1/0 :: Double) :: Int}}} depends on optimization level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 28 Jan '18

28 Jan '18

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12567 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) * related: => #12567 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE
by GHC 27 Jan '18

27 Jan '18

#12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE --------------------------------------+---------------------------------- Reporter: pggiarrusso | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- I have here a ~600MB core dump on GHC 8.0.1 x86_64 linux triggered under low memory (1GB RAM total, no swap, trying to build aeson with optimizations), with a stacktrace blaming the GHC runtime system. Based on code review, it appears that when requesting memory from the OS fails, the error is ignored and GHC segfaults as soon as it writes to the newly "allocated" memory. == Diagnosis == My diagnosis is that osCommitMemory calls the potentially failing `my_mmap` but returns void (hence not propagating failures); it should instead probably use `my_mmap_or_barf` or handle the failure anyhow: https://github.com/ghc/ghc/blob/a6111b8cc14a5dc019e2613f6f634dec4eb57a8a/rt… However, while I'm very convinced that's a bug, I'm only mostly confident that's the culprit, since the segfault happens later; I've just looked for bugs on allocation failures in the code ran shortly before the crash. == Raw data == The core dump is on a VM from the reporter of https://github.com/commercialhaskell/stack/issues/2575, https://github.com/jiakai0419, which graciously gave me access to the VM and bothered reporting in the first place—I'd like to thank her. I'd like to avoid copying the dump here unless strictly needed. == Reproduction == The bug is deterministic on that machine, but it requires a failure in mmap without triggering an OOM, so I'm not 100% sure how easy it is to reproduce but it should be easy on a VM with 1GB RAM and 1 core. Here's the output of `free`: {{{ $ free total used free shared buff/cache available Mem: 1015352 95864 71396 51244 848092 733132 Swap: 0 0 0 }}} Instructions to produce a dump. First, as root: {{{ echo /tmp/core > /proc/sys/kernel/core_pattern }}} that's needed because otherwise the core file is produced in a temporary folder that stack removes. Then (as non-root, root has privileged access to memory), install stack, and run: {{{ ulimit -c unlimited git clone https://github.com/jiakai0419/snowflake.git stack build --verbose }}} Below is some raw data from the core dump. In short, an initializer for newly allocated data segfaults, and gdb tells that the address it's trying to write (bd->start) to can't be accessed, even though it's lower than mblock_high_watermark so it should have been committed (mmap'ed) by getFreshMBlocks (I don't get getReusableMBlocks in detail, but it also calls `osCommitMemory`, so I guess there's the same invariant). The existence of mblock_high_watermark (beyond other reasons) should confirm this is using USE_LARGE_ADDRESS_SPACE. If this diagnosis is correct, the bug exists since USE_LARGE_ADDRESS_SPACE was introduced in https://github.com/ghc/ghc/commit/0d1a8d09f452977aadef7897aa12a8d41c7a4af0, so it's a regression in 8.0.1. {{{ (gdb) bt #0 initMBlock (mblock=0x225c00000) at rts/sm/BlockAlloc.c:676 #1 alloc_mega_group (mblocks=mblocks@entry=1) at rts/sm/BlockAlloc.c:328 #2 0x00007fe650438d98 in allocGroup (n=1) at rts/sm/BlockAlloc.c:379 #3 allocGroup (n=1) at rts/sm/BlockAlloc.c:336 #4 0x00007fe65043ed55 in allocBlock_sync () at rts/sm/GCUtils.c:38 #5 0x00007fe65043ef7d in alloc_todo_block (ws=ws@entry=0x13196b0, size=size@entry=3) at rts/sm/GCUtils.c:330 #6 0x00007fe65043f13a in todo_block_full (size=size@entry=3, ws=0x13196b0) at rts/sm/GCUtils.c:292 #7 0x00007fe65041baed in alloc_for_copy (gen_no=<optimized out>, size=3) at rts/sm/Evac.c:81 #8 copy_tag (tag=2, gen_no=<optimized out>, size=3, src=0x21b353868, info=<optimized out>, p=0x225b13f10) at rts/sm/Evac.c:99 #9 evacuate1 (p=p@entry=0x225b13f10) at rts/sm/Evac.c:596 #10 0x00007fe65041d65c in scavenge_block1 (bd=0x225b004c0) at rts/sm/Scav.c:570 #11 0x00007fe6504415dc in scavenge_find_work () at rts/sm/Scav.c:2040 #12 scavenge_loop1 () at rts/sm/Scav.c:2103 #13 0x00007fe65043cee2 in scavenge_until_all_done () at rts/sm/GC.c:968 #14 0x00007fe65043d75a in GarbageCollect (collect_gen=collect_gen@entry=1, do_heap_census=do_heap_census@entry=rtsFalse, gc_type=gc_type@entry=2, cap=cap@entry=0x7fe650669a80 <MainCapability>) at rts/sm/GC.c:403 #15 0x00007fe65042ff81 in scheduleDoGC (force_major=rtsFalse, task=0x13228a0, pcap=<optimized out>) at rts/Schedule.c:1652 #16 scheduleDoGC (pcap=<optimized out>, task=0x13228a0, force_major=rtsFalse) at rts/Schedule.c:1433 #17 0x00007fe650430c1a in schedule (initialCapability=initialCapability@entry=0x7fe650669a80 <MainCapability>, task=task@entry=0x13228a0) at rts/Schedule.c:551 #18 0x00007fe650431cf8 in scheduleWaitThread (tso=0x20000b388, ret=ret@entry=0x0, pcap=pcap@entry=0x7ffc4ee22c08) at rts/Schedule.c:2361 #19 0x00007fe65042c528 in rts_evalLazyIO (cap=cap@entry=0x7ffc4ee22c08, p=p@entry=0x7895c0, ret=ret@entry=0x0) at rts/RtsAPI.c:500 #20 0x00007fe65042e3a7 in hs_main (argc=96, argv=0x7ffc4ee22dc8, main_closure=0x7895c0, rts_config=...) at rts/RtsMain.c:64 #21 0x0000000000428414 in main () (gdb) info locals bd = 0x225c00100 block = 0x225c04000 <Address 0x225c04000 out of bounds> (gdb) print/x mblock_high_watermark $11 = 0x225d00000 (gdb) print bd->start Cannot access memory at address 0x225c00100 (gdb) print *bd Cannot access memory at address 0x225c00100 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14606: ghc-exactprint not up to date
by GHC 27 Jan '18

27 Jan '18

#14606: ghc-exactprint not up to date -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 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 have created this ticket to track that ghc-exactprint has not yet been updated, and this should happen before a final release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14719: Caret diagnostics for GADT constructor error message don't span the whole constructor
by GHC 27 Jan '18

27 Jan '18

#14719: Caret diagnostics for GADT constructor error message don't span the whole constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Inspecting the caret diagnostics in the error message for this program: {{{#!hs {-# LANGUAGE GADTs #-} module Bug where data Foo1 where MkFoo1 :: Bool newtype Foo2 where MkFoo2 :: Foo2 }}} {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:3: error: • Data constructor ‘MkFoo1’ returns type ‘Bool’ instead of an instance of its parent type ‘Foo1’ • In the definition of data constructor ‘MkFoo1’ In the data type declaration for ‘Foo1’ | 5 | MkFoo1 :: Bool | ^ Bug.hs:8:3: error: • The constructor of a newtype must have exactly one field but ‘MkFoo2’ has none • In the definition of data constructor ‘MkFoo2’ In the newtype declaration for ‘Foo2’ | 8 | MkFoo2 :: Foo2 | ^ }}} We notice something fishy: the carets don't span the entirey of the constructor! Contrast this with the carets for the error message in this program: {{{#!hs {-# LANGUAGE GADTs #-} module Bug where data Foo where MkFoo, MkFoo :: Foo }}} {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:3: error: Multiple declarations of ‘MkFoo’ Declared at: Bug.hs:5:3 Bug.hs:5:3 | 5 | MkFoo, MkFoo :: Foo | ^^^^^^^^^^^^^^^^^^^ }}} Where the carets span everything that is relevant. I know what is causing this: patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3