August 2018 - ghc-tickets

[GHC] #15523: GHC Panic on malformed newtype and StrictData
by GHC 15 Aug '18

15 Aug '18

#15523: GHC Panic on malformed newtype and StrictData -------------------------------------+------------------------------------- Reporter: rdnetto | Owner: (none) Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- The following source causes a panic: {{{#!hs {-# LANGUAGE StrictData #-} module Main where newtype Duration = Foo data Literal = LitDuration Duration }}} Result: {{{ [1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64 -linux-tinfo6/Cabal-2.2.0.1/build/tcalc/tcalc-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): mkNewTyConRhs Foo [] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/iface/BuildTyCl.hs:77:27 in ghc:BuildTyCl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If we remove the StrictData pragma, then we get a syntax error as expected: {{{ /home/reuben/tcalc/src/Main.hs:3:20: error: • The constructor of a newtype must have exactly one field but ‘Foo’ has none • In the definition of data constructor ‘Foo’ In the newtype declaration for ‘Duration’ | 3 | newtype Duration = Foo | ^^^ }}} I was able to reproduce this with GHC 8.4.3 and 8.2.2 (using Stack LTS snapshots). GHC 8.0.2 is not affected. A test case buildable with Stack can be found at https://github.com/rdnetto/tcalc/tree/ghc-bug (i.e. on the ghc-bug branch). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32
by GHC 15 Aug '18

15 Aug '18

#15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Was support for `WORD_SIZE_IN_BITS < 32` dropped? According to [https://github.com/ghc/ghc/commit/b38f08350d5c0efaa613f2f6c67dad5366aac271 this GHC commit], it appears that that support was dropped about seven years ago. Also, `find -type f | xargs -n 5 egrep 'WORD_SIZE_IN_BITS\s*<\s*32'` only finds mention of it in `primops.txt.pp`. If support for that was dropped, [https://github.com/ghc/ghc/blob/9897f6783a58265d5eaef5fb06f04320c7737e87/co… the current version of compiler/prelude/primops.txt.pp] has dead code and misleading documentation (that's apparently propagated to [https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html GHC.Prim documentation]) that might cause programmers to expend unnecessary effort supporting `WORD_SIZE_IN_BITS < 32` in their own code. The following documentation describes a situation that can no longer happen and continues on incorrectly past these two paragraphs: >Haskell98 specifies that signed integers (type `Int` must contain at least 30 bits. GHC always implements `Int` using the primitive type `Int#`, whose size equals the `MachDeps.h` constant `WORD_SIZE_IN_BITS`. > >This is normally set based on the `config.h` parameter `SIZEOF_HSWORD`, i.e., 32 bits on 32-bit machines, 64 bits on 64-bit machines. However, it can also be explicitly set to a smaller number, e.g., 31 bits, to allow the possibility of using tag bits. Currently GHC itself has only 32-bit and 64-bit variants, '''but 30 or 31-bit code can be exported as an external core file for use in other back ends'''. The following is dead code. Further, `INT32` and `WORD32` throughout the document should be replaced with `Int#` and `Word#`: {{{#!c #if WORD_SIZE_IN_BITS < 32 #define INT32 Int32# #define WORD32 Word32# #else #define INT32 Int# #define WORD32 Word# #endif }}} Also, all code inclusively between `#if WORD_SIZE_IN_BITS < 32` lines and their matching `#endif`s can be eliminated. ---- On the other hand, if `WORD_SIZE_IN_BITS < 32` '''is''' still supported, there are a lot of cases wherein a 64-bit version of an instruction uses `INT64` or `WORD64` in its type signature, but the 32-bit version uses `Int#` or `Word#`, which robs programmers of the ability to use speedy hardware instructions on full untagged `Int32#`s or `Word32#`s. Also, the `Double#` decoder to two `Word#`s for the mantissa assumes that the `Word#`s can hold a full 32 bits according to its documentation. There are some other problems that I've forgotten as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15522: Cannot bind symbolic names in a rule
by GHC 15 Aug '18

15 Aug '18

#15522: Cannot bind symbolic names in a rule -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | 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: -------------------------------------+------------------------------------- I assumed the following would be accepted: {{{ {-# RULES "blah" forall (+++). id (+++) = (+++) #-} }}} But it's not, as the parser doesn't like my `+++`. I find this inconsistent with the way that GHC normally treats term-level variables, which can generally be symbolic. That said, I have no need for this feature, and allowing it creates more headaches (it potentially creates parsing challenges, especially with #2600; and soon people will want to specify fixities). I thus propose simply to document that we don't allow it and move on. If you agree (for any definition of "you"), please post, as I'd love other opinions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2600: Bind type variables in RULES
by GHC 15 Aug '18

15 Aug '18

#2600: Bind type variables in RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2110 | Differential Rev(s): Phab:D4894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D4894 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2600#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
by GHC 14 Aug '18

14 Aug '18

#5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5518#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
by GHC 14 Aug '18

14 Aug '18

#5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * owner: (none) => ulysses4ever -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5518#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
by GHC 14 Aug '18

14 Aug '18

#5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * status: closed => new * differential: => Phab:D5066 * resolution: fixed => * version: 7.0.3 => Comment: I renewed the Unicode tables as described [https://github.com/ghc/ghc/blob/24e56ebd010846683b236b6ef3678c2217640120/li… here], and this fixed the issue. Merge? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5518#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
by GHC 14 Aug '18

14 Aug '18

#5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by ulysses4ever): I can confirm this for 8.4.3 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5518#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12980: Unlifted class method rejected
by GHC 14 Aug '18

14 Aug '18

#12980: Unlifted class method rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- If I say {{{#!hs class C a where meth :: Array# a }}} I get {{{ • Expecting a lifted type, but ‘Array# a’ is unlifted • In the type signature: meth :: Array# a In the class declaration for ‘C’ }}} This definition looks OK to me. I don't see why we can't have an unlifted member of a class. (As @oerjan points out in comment:25:ticket:12708, we can't have a ''levity-polymorphic'' class member, but this is solidly levity- monomorphic.) I'm happy to lift this restriction in ongoing work in this area, but I wanted to double-check before doing so. For the record, the same error occurs even when the class has more than one member, so it's not the no-unlifted-newtypes restriction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
by GHC 14 Aug '18

14 Aug '18

#5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by joeyh): Similarly, with ghc 8.2.2 (debian), this is not accepted: main = putChar '🥖' That's U+1F956 baguette. ghc says: lexical error in string/character literal at character '\129366' My system is fully utf-8 enabled and the original problem character works ok. Guess this is just lag getting the unicode character tables updated. However, while it seems reasonable for ghc to not let me define a function eg (🥖) = (</>) since it doesn't know what kind of symbol baguette is, it seems much less reasonable to not accept any unicode inside a string. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5518#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0