August 2018 - ghc-tickets

[GHC] #15548: Make TABLES_NEXT_TO_CODE a dynflag
by GHC 22 Aug '18

22 Aug '18

#15548: Make TABLES_NEXT_TO_CODE a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 GHC API is used by programs that do not necessarily want to compile the same way as the normal GHC, so we want as much configuration in `DynFlags` and as little as possible hard-coded. One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used in these places: * It is (of course) used a lot in rts. That’s fine. * It is used via tablesNextToCode :: DynFlags -> Bool in the Cmm code, so that code is already prepared to read the information from `DynFlags`. * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some refactoring there might be needed to add a `DynFlag` there. (The motivation is similar to #13477) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15548> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15534: Allow associated types in Minimal pragmas
by GHC 22 Aug '18

22 Aug '18

#15534: Allow associated types in Minimal pragmas -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.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: -------------------------------------+------------------------------------- Missing associated type definitions can cause compile-time problems similar to the run-time problems that occur when necessary methods are missing. {{{#!hs {-# language TypeFamilies, UndecidableInstances #-} class Foo a where type X a type X a = Y a type Y a type Y a = X a instance Foo Int bob :: X Int bob = undefined }}} Compiling this gives {{{ Minim.hs:14:7: error: • Reduction stack overflow; size = 201 When simplifying the following type: Y Int Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: undefined In an equation for ‘bob’: bob = undefined | 14 | bob = undefined }}} That's not exactly the best error message in the world. I would like to be able to write {{{#!hs {-# MINIMAL X | Y #-} }}} which would mean that instances should give type instances for `X` or `Y`. I don't see any reason to prohibit mixing associated types and methods in a single `MINIMAL` pragma. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15556: Inconsistent kind output for (->)
by GHC 22 Aug '18

22 Aug '18

#15556: Inconsistent kind output for (->) -------------------------------------+------------------------------------- Reporter: cvlad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 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: -------------------------------------+------------------------------------- The kind for (->) seems to be (uniquely?) verbose in ghc >= 8.2.2: {{{(->) :: TYPE q -> TYPE r -> *}}} Unlike all other things I was able to check. Is this intended? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15556> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15492: Plugin recompilation check fails when profiling is enabled
by GHC 22 Aug '18

22 Aug '18

#15492: Plugin recompilation check fails when profiling is enabled -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: highest | 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: -------------------------------------+------------------------------------- When compiling with profiling enabled and using a plugin, GHC will panic as follows: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.1.20180803 for x86_64-unknown-linux): mkPluginUsage: no dylibs GraphMod Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:178:15 in ghc:DsUsage }}} Investigating determines that the following paths are being inspected: {{{ /nix/store/m0ylnbifx5ba1qwi8vzipxq4p7ma3073-graphmod- plugin-0.1.0.0/lib/ghc-8.6.1.20180803/x86_64-linux-ghc-8.6.1.20180803 /libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p- ghc8.6.1.20180803.so /nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSgraphmod- plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so /nix/store/hhzvw77vrmn5f506kfyb1yh1sdinkbwf-gmp-6.1.2/lib/libHSgraphmod- plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so }}} None of which exist. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15492> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 22 Aug '18

22 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: 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 dfeuer): Let me take that back... What I thought I saw in the wild wasn't what I saw. Maybe nobody is taking advantage of that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 22 Aug '18

22 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: 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 dfeuer): I've had more thoughts/details on garbage collection in the no-stable- name-table option. I don't think we actually need to store an underlying object pointer in an SNO at all. After running the collector (before compacting), traverse the keys and SNOs in the SN hash table to form the new one. If the key is dead, do nothing. If the SNO is dead, do nothing. If both have been evacuated, insert the new key and new SNO into the hash table for the next generation. The main remaining problem looks unfortunate, and has to do with `hashStableName#`. While that has never been documented as being injective, it actually ''is'' injective under certain circumstances, and indeed it appears that real code on Hackage relies on this (see, e.g., [http://hackage.haskell.org/package/stable-maps-0.0.5/docs/System-Mem- StableName-Map.html stable-maps]). In particular, the way it works now, we can implement a stable name map as `IntMap (StableName k, v)`. Because the map keeps the `StableName`s alive, their stable name table indices won't be reused. The only way to keep such code working is to make such a guarantee. That ''requires'' a way to allocate IDs uniquely. So we need a data structure that can keep track of which IDs are available and allocate them. Ugh. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families
by GHC 22 Aug '18

22 Aug '18

#14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | 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: -------------------------------------+------------------------------------- I've the following small example {{{ {-# LANGUAGE MagicHash, UnboxedSums, NoImplicitPrelude #-} {-# LANGUAGE TypeFamilies #-} -- {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs ,ExplicitNamespaces#-} {-# LANGUAGE UnboxedTuples #-} module Data.Unboxed.Maybe where import GHC.Exts import GHC.Types import Prelude (undefined) import Data.Void data family Maybe(x :: TYPE (r :: RuntimeRep)) data instance Maybe (a :: * ) where MaybeSum :: (# a | (# #) #) -> Maybe a data instance Maybe (x :: TYPE 'UnliftedRep) where MaybeSumU :: (# x | (# #) #) -> Maybe x }}} and then i get the error (made much saner to read by use of printing explicit kinds) {{{ Prelude> :r [1 of 1] Compiling Data.Unboxed.Maybe ( src/Data/Unboxed/Maybe.hs, interpreted ) src/Data/Unboxed/Maybe.hs:22:3: error: • Data constructor ‘MaybeSumU’ returns type ‘Maybe 'LiftedRep x’ instead of an instance of its parent type ‘Maybe 'UnliftedRep x’ • In the definition of data constructor ‘MaybeSumU’ In the data instance declaration for ‘Maybe’ | 22 | MaybeSumU :: (# x | (# #) #) -> Maybe x }}} this is a) a case where printing runtime reps makes things easier to debug :) b) a very confusing type error since the data instance clearly says "x :: TYPE 'UnliftedRep " is there something i'm overlooking, or is this a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #15540: GHCi does not follow the XDG Base Directory Specification
by GHC 22 Aug '18

22 Aug '18

#15540: GHCi does not follow the XDG Base Directory Specification -------------------------------------+------------------------------------- Reporter: rszibele | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.0.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: -------------------------------------+------------------------------------- Hello, GHCi does not follow the XDG Base Directory Specification by default on GNU/Linux based operating systems. It creates for instance the file $HOME/.ghc/ghci_history which belongs in $XDG_CACHE_HOME/ghc/ , or $HOME/.cache/ghc/ if $XDG_CACHE_HOME is not set. $ ghci --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15540> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers
by GHC 22 Aug '18

22 Aug '18

#15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tested with version 8.2.2 and 8.0.2 (stack lts-11.5, lts-9.21, nightly-2018-04-14) with GHC and GHCi on archlinux amd64. **Code that produces wrong results** {{{ map (/2) [9007199254740990..9007199254740991] }}} **Expected behaviour** same as with low values: {{{ map (/2) [5..6] }}} resulting in: {{{ [2.5,3.0] }}} **Actual behaviour** resulting in an infinite list: {{{ [4.503599627370495e15,4.5035996273704955e15,4.503599627370496e15..] }}} **Similar code that produces expected results** multiplication works: {{{ map (*2) [9007199254740990..9007199254740991] }}} slightly smaller number work: {{{ map (/2) [9007199254740989..9007199254740990] }}} using a comma to produce the same list works: {{{ map (/2) [9007199254740990,9007199254740991] }}} **Similar code that also produces unexpected results** more elements in the list: {{{ map (/2) [9007199254740990..9007199254740999] map (/2) [9007199254740990..9007199354740999] }}} substituting the number and doing calculations: {{{ map (/2) [9007199254740990..9007199254740990+1] let a = 9007199254740990 map (/2) [a..a+1] }}} using scan and fold: {{{ foldl1 (/) [9007199254740990..9007199254740991] scanl1 (/) [9007199254740990..9007199254740991] }}} **Notes** This somehow only happens with high numbers when using fractional operations and using .. to construct the list. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12674: GHC doesn't handle ./ prefixed paths correctly
by GHC 22 Aug '18

22 Aug '18

#12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC doesn't correctly handle paths preceded by `./` on the command line, if their first character (after any number of `./`s) is a `-`. For instance, `ghc ./-a.hs` fails, even if `a.hs` exists. Somewhere, `./-a.hs` is being converted to `-a.hs`. I have not been able to figure out where this happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11