June 2018 - ghc-tickets

[GHC] #15284: Can't parse ''(*) in GHC HEAD
by GHC 17 Jun '18

17 Jun '18

#15284: Can't parse ''(*) in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Parser) | 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 can't build the `reflection` library on GHC HEAD since the `''(*)` Template Haskell name no longer parses. Here is a smaller example which compares GHC 8.4.3 (what should happens) with HEAD (which fails): {{{ $ /opt/ghc/8.4.3/bin/ghci -XTemplateHaskell GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import GHC.TypeNats λ> ''(*) GHC.TypeNats.* }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive -XTemplateHaskell GHCi, version 8.5.20180617: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import GHC.TypeNats λ> ''(*) <interactive>:2:4: error: parse error on input ‘*’ }}} int-index, I believe this was caused by your commit d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60 (`Embrace -XTypeInType, add -XStarIsType`). Do you know what is going on here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows
by GHC 17 Jun '18

17 Jun '18

#15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows -------------------------------------+------------------------------------- Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHC rejects | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On appveyor I had a problem building pretty-show: {{{ -- While building custom Setup.hs for package pretty-show-1.7 using: C:\sr\setup-exe-cache\i386-windows\Cabal- simple_Z6RU0evB_2.2.0.1_ghc-8.4.2.exe --builddir=.stack-work\dist\ba067387 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure (-1073741819) }}} More details at https://github.com/yav/pretty-show/issues/27 . Converting the (otherwise standard) Setup.lhs to a non-literate Setup.hs seemed to fix it. Switching to 64-bit GHC seemed to also fix it (the Setup.lhs worked with 64-bit GHC). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13895: "Illegal constraint in a type" error - is it fixable?
by GHC 17 Jun '18

17 Jun '18

#13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- I recently sketched out a solution to #13327. Here is the type signature that I wanted to write: {{{#!hs dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) }}} But this doesn't typecheck: {{{ • Could not deduce (Typeable (t k0)) from the context: (Data a, Typeable (t k)) bound by the type signature for: dataCast1 :: forall a. Data a => forall k (c :: * -> *) (t :: forall k1. k1 -> *). Typeable (t k) => (forall d. Data d => c (t * d)) -> Maybe (c a) at NewData.hs:(170,3)-(173,26) The type variable ‘k0’ is ambiguous • In the ambiguity check for ‘dataCast1’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: dataCast1 :: forall a. Data a => forall k (c :: * -> *) (t :: forall k1. k1 -> *). Typeable (t k) => (forall d. Data d => c (t * d)) -> Maybe (c a) In the class declaration for ‘Data’ | 170 | dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). k -> Type). | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} This makes sense, since GHC has no way to conclude that the `k` in `t`'s kind is also `Typeable`. I tried to convince GHC of that fact: {{{#!hs dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). Typeable k => k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) }}} But this also doesn't work: {{{ NewData.hs:171:25: error: • Illegal constraint in a type: Typeable k0 • In the first argument of ‘Typeable’, namely ‘t’ In the type signature: dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). Typeable k => k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) In the class declaration for ‘Data’ | 171 | Typeable t | ^ NewData.hs:172:40: error: • Illegal constraint in a type: Typeable k0 • In the first argument of ‘c’, namely ‘(t d)’ In the type signature: dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). Typeable k => k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) In the class declaration for ‘Data’ | 172 | => (forall d. Data d => c (t d)) | ^^^ }}} At this point, I'm stuck, since I have no idea how to work around this `Illegal constraint in a type` error. This error message appears to have originated as a part of the `TypeInType` patch, since there's even a [http://git.haskell.org/ghc.git/blob/58c781da4861faab11e4c5804e07e6892908ef7… test case] checking for this behavior. But is this a fundamental limitation of kind equalities? Or would it be possible to lift this restriction? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13895> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C--
by GHC 17 Jun '18

17 Jun '18

#8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- So if I say "foobar" in C--, it turns into: {{{ section "rodata" { fresh_name : bits8[] "foobar\0"; } }}} This would let us fix the ASSERT macro in Cmm.h to also get the filename. Requires parser changes. Alternatively, we can redefine the ASSERT macro per C-- file to have a hardcoded filename with some preprocessor trickery. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1
by GHC 17 Jun '18

17 Jun '18

#15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- 60e4bb4d305bc1a65457ee79b1e69c11b9ed747d (#9136) triggers a bug in GHC 8.2.1 which causes the build to fail with, {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (r_aqbE :: TYPE rep_aqbD) rep_aqbD 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/simplStg/RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is a manifestation of #14393, which is fixed in 8.2.2 and later. We should probably add a `configure` check warning about this brokenness when the user tries to bootstrap with GHC 8.2.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 17 Jun '18

17 Jun '18

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"df0f148feae4c3b9653260edff843d561d6d5918/ghc" df0f148f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="df0f148feae4c3b9653260edff843d561d6d5918" Improve error message when importing an unusable package If a module cannot be found because it is ignored or from an unusable package, report this to the user and the reason it is unusable. Currently, GHC displays the standard "Cannot find module error". For example: ``` <no location info>: error: Could not find module ‘Control.Monad.Random’ Perhaps you meant Control.Monad.Reader (from mtl-2.2.2) Control.Monad.Cont (from mtl-2.2.2) Control.Monad.Error (from mtl-2.2.2) ``` GHC does, however, indicate unusable/ignored packages with the -v flag: ``` package MonadRandom-0.5.1-1421RgpXdhC8e8UI7D3emA is unusable due to missing dependencies: fail-4.9.0.0-BAHmj60kS5K7NVhhKpm9J5 ``` With this change, I took that message and added it to the output of the "Cannot find module" message. Reviewers: bgamari, dfeuer Reviewed By: bgamari Subscribers: Phyx, dfeuer, rwbarton, thomie, carter GHC Trac Issues: #4806 Differential Revision: https://phabricator.haskell.org/D4783 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14295: tagToEnum# leads to some silly closures
by GHC 17 Jun '18

17 Jun '18

#14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: datacon-tags | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't know how important this is in practice, but it smells pretty silly. Suppose I write {{{#!hs foo :: (Bool -> a) -> Int# -> a foo f x = f (tagToEnum# x) }}} Since `tagToEnum#` can fail, GHC compiles this to {{{#!hs foo = \ (@ a_a10v) (f_s1by [Occ=Once!] :: GHC.Types.Bool -> a_a10v) (x_s1bz [Occ=Once] :: GHC.Prim.Int#) -> let { sat_s1bA [Occ=Once] :: GHC.Types.Bool [LclId] sat_s1bA = GHC.Prim.tagToEnum# @ GHC.Types.Bool x_s1bz } in f_s1by sat_s1bA }}} That seems pretty silly! We know that `tagToEnum#` is applied to `Bool`, so we can transform this to something like {{{#!hs foo f x = case x <=# 1# of 1# -> f $! tagToEnum# x _ -> f (error "tagToEnum# was used at Bool with tag ...") }}} which avoids an extra closure at the cost of a single `Int#` comparison. The same goes for arbitrary known enumeration types. I suspect the right place to fix this up is in CorePrep. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12970: Add default implementation for Bits.bitSize
by GHC 17 Jun '18

17 Jun '18

#12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: libraries/base | 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 think it would be a good idea to provide a default implementation for bitSize, example: {{{#!hs bitSize b = fromMaybe (error "bitSize is undefined") (bitSizeMaybe b) }}} The advantage is that from now on new instances of Bits no longer need to define bitSize. And once bitSize has been removed there will be no errors about it not being a method of class Bits. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 16 Jun '18

16 Jun '18

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by newhoggy): Has any work been done to introduce the `VecFormat` type? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15134: enumFrom... aren't really documented.
by GHC 16 Jun '18

16 Jun '18

#15134: enumFrom... aren't really documented. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | 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 Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6