September 2017 - ghc-tickets

[GHC] #13222: Update formalism for join points
by GHC 30 Oct '17

30 Oct '17

#13222: Update formalism for join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | 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 rather flagrantly violated the entreaties in `CoreLint` about updating the formalism (namely by adding join points). Need to fix that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release
by GHC 30 Oct '17

30 Oct '17

#14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14054: Cabal generates ill-typed Paths module when relocatable
by GHC 30 Oct '17

30 Oct '17

#14054: Cabal generates ill-typed Paths module when relocatable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | Keywords: Cabal | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A PR has been submitted https://github.com/haskell/cabal/pull/4638 and we know this bug affects the Cabal fixed with GHC. When we do 8.2.2 we should make sure we get a fixed version of Cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13945: make install fails when registering packages
by GHC 30 Oct '17

30 Oct '17

#13945: make install fails when registering packages -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- In the final part of installation when packages are registered, the following command fails {{{ "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708" '' '/home/pgrads/mp16005/linux/installed-ghc' '/home/pgrads/mp16005/linux /installed-ghc/lib/ghc-8.2.0.20170708' '/home/pgrads/mp16005/linux /installed-ghc/share/doc/ghc-8.2.0.20170708/html/libraries' NO }}} with the following output {{{ Registering library for ghc-prim-0.5.0.0.. ghc-cabal: '/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg' exited with an error: ghc-pkg: Couldn't open database /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d for modification: {handle: /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) }}} It might be something to do with the permissions I have on my machine but I used to be able to install ghc if I gave it a suitable prefix other than `/usr/local`. Here is the call stack from the crash if that's useful. {{{ CallStack (from HasCallStack): die', called at libraries/Cabal/Cabal/Distribution/Simple/Program/Run.hs:142:7 in main:Distribution.Simple.Program.Run runProgramInvocation, called at libraries/Cabal/Cabal/Distribution/Simple/Program/HcPkg.hs:167:5 in main:Distribution.Simple.Program.HcPkg register, called at libraries/Cabal/Cabal/Distribution/Simple/GHC.hs:1709:5 in main:Distribution.Simple.GHC registerPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Register.hs:350:14 in main:Distribution.Simple.Register registerPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Register.hs:172:16 in main:Distribution.Simple.Register registerAll, called at libraries/Cabal/Cabal/Distribution/Simple/Register.hs:125:5 in main:Distribution.Simple.Register register, called at libraries/Cabal/Cabal/Distribution/Simple.hs:770:10 in main:Distribution.Simple defaultRegHook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:584:20 in main:Distribution.Simple regHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:120:5 in main:Distribution.Simple.UserHooks regHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:120:5 in main:Distribution.Simple.UserHooks cmd_hook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:452:38 in main:Distribution.Simple cmd_hook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:469:4 in main:Distribution.Simple hookedActionWithArgs, called at libraries/Cabal/Cabal/Distribution/Simple.hs:451:5 in main:Distribution.Simple hookedAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:430:5 in main:Distribution.Simple registerAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:184:50 in main:Distribution.Simple defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:133:28 in main:Distribution.Simple defaultMainWithHooksArgs, called at utils/ghc-cabal/Main.hs:214:6 in main:Main }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13945> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #13825: Allow multiple constructor fields occupy the same word
by GHC 30 Oct '17

30 Oct '17

#13825: Allow multiple constructor fields occupy the same word -------------------------------------+------------------------------------- Reporter: michalt | 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: -------------------------------------+------------------------------------- The main goal is to reduce the overhead of things like: {{{#!hs data Bloated = Bloated {-# UNPACK #-} !Word8 {-# UNPACK #-} !Int8 {-# UNPACK #-} !Bool }}} Assuming 64-bit architecture, currently those fields will take 8 bytes each! So for this example we'd need: 8 bytes for header + 3 * 8 bytes for fields = 32 bytes. But we should be able to pack the fields into a single word (a word is 8 bytes and each field really only needs 1 byte) for a total of 16 bytes (8 bytes header + 8 bytes for fields, with the 5 bytes being "overhead" due to heap alignment). My understanding is that we need a few things to make this happen: - Ability to refer to fields that are packed into a single word (currently everything in GHC assumes that each field occupies a single word). Simon Marlow started working on this in https://phabricator.haskell.org/D38 - Introduce primitives like `Word8#`, `Int8#`, ... (currently `WordX` and `IntX` are defined as wrappers of `Word#` and `Int#` respectively) and change `WordX`/`IntX` definitions to use those primitives. - Figure out what to do with `Bool` (should it be just `Word8#`? should we have `Bool#`?) and change its definition (using pattern synonyms for `True`/`False`) Some additional info: - Thread on ghc-devs: https://mail.haskell.org/pipermail/ghc- devs/2017-June/014304.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13038: implementation of Modus ponens and Modus tollens
by GHC 29 Oct '17

29 Oct '17

#13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 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: -------------------------------------+------------------------------------- Can we have in Prelude - Booleans, Modus ponens and Modus tollens implemented? Or in another module? reminder:[[BR]] P is a proposition and v(p) is the logic value of P.[[BR]] P is true, v(P) = 1[[BR]] P is false, v(P) = 0[[BR]] P -> Q is always true in propositional logic. Modus ponens:[[BR]] v(P) = 1[[BR]] v(P -> Q) = 1[[BR]] v(Q) = 1[[BR]] v(P) and v(P -> q) are premiss, v(q) is the conclusion.[[BR]] or in a more general form[[BR]] P : X is A[[BR]] P -> Q : A -> B[[BR]] Q : X is B[[BR]] Modus tollens:[[BR]] v(Q) = 0[[BR]] v(P -> Q) = 1[[BR]] v(P) = 0[[BR]] v(Q) and v(P -> Q) are premiss, v(P) is the conclusion.[[BR]] or in a more general form[[BR]] not Q : X is not B[[BR]] P -> Q : A -> B[[BR]] not P : X is not A[[BR]][[BR]] As well as using the numbers 0 and 1 for the respective values false and true, we'll use the letters F for False and T for True.[[BR]] We are always:[[BR]] v(F) = 0[[BR]] v(T) = 1[[BR]] v(P -> Q) = 1[[BR]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD
by GHC 27 Oct '17

27 Oct '17

#13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `purescript-0.10.7` fails to build with GHC HEAD at the moment due to an apparent regression in the way pattern synonyms and overloaded strings interact. Here is a simplified example: {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE PatternSynonyms #-} module Bug where import Data.ByteString newtype ProperName = ProperName { runProperName :: ByteString -- purescript actually uses the Text type, but this works -- just as well for the purposes of illustrating the bug } newtype ModuleName = ModuleName [ProperName] pattern TypeDataSymbol :: ModuleName pattern TypeDataSymbol = ModuleName [ProperName "Type",ProperName "Data", ProperName "Symbol"] }}} Compiling this with GHC 7.10.3 or 8.0.2 works without issue. In GHC HEAD, if you compile this with optimization enabled, it'll trigger a GHC panic: {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 -O1 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170303 for x86_64-unknown-linux): isUnliftedType r_a28T :: TYPE rep_a28S Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1961:10 in ghc:Type }}} The presence of optimization is crucial for reproducing this bug, as compiling it with `-O0` does not trigger the panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters
by GHC 25 Oct '17

25 Oct '17

#13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters -------------------------------------+------------------------------------- Reporter: Tikhon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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: -------------------------------------+------------------------------------- The following function definition works without TypeApplications but fails to parse with the extension enabled: {{{#!hs {-# LANGUAGE TypeApplications #-} module Mininal where foo x₁@True = 10 }}} It also parses correctly with "x" in place of "x₁". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13986> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14214: Users guide lies about default optimization level
by GHC 25 Oct '17

25 Oct '17

#14214: Users guide lies about default optimization level -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- #14208 points out that the users guide claims that the default optimization level is `-O0`. However this apparently isn't true. We should decide whether this should be the default and, if so, identify and fix the differences. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13707: xmobar crashes with segmentation faults?
by GHC 25 Oct '17

25 Oct '17

#13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Markus Trippelsdorf on `ghc-devs` reports that 8.2.1-rc2 produces crashing `xmobar` executables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26