- ghc-tickets - Haskell.org

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 10 Oct '17

10 Oct '17

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: nakaji_dayo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4083 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nakaji_dayo): * differential: D4083 => Phab:D4083 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 10 Oct '17

10 Oct '17

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: nakaji_dayo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4083 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nakaji_dayo): * differential: => D4083 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 10 Oct '17

10 Oct '17

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by duog): It looks like trac:14092 could lead to nondeterministic interface files when using parallel --make. Single threaded --make does not seem to be nondetermistic, though I believe it is uncomfortably sensitve to the order in which modules are compiled, which can be determined by the order they are imported or passed to ghc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO
by GHC 09 Oct '17

09 Oct '17

#14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- When ghc 8.2.1 compiled using DYNAMIC_GHC_PROGRAMS=NO attemps at using TH results in all sorts of exciting errors: source files: {{{ % cat A.hs {-# LANGUAGE TemplateHaskell #-} module Numeric.Sum where import B b }}} this file makes little sense, but it was segfaulting when it had more code as well {{{ % cat B.hs {-# LANGUAGE TemplateHaskellQuotes #-} module B where import Language.Haskell.TH b :: DecsQ b = return [ InstanceD Nothing [] (ConT ''Show `AppT` undefined) [] ] }}} Let's try running it a few times - note illegal hardware instruction {{{ % ghc -O2 A.hs [1 of 2] Compiling B ( B.hs, B.o ) [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: segmentation fault ghc -O2 A.hs % ghc -O2 A.hs [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: segmentation fault ghc -O2 A.hs % ghc -O2 A.hs [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: illegal hardware instruction ghc -O2 A.hs % ghc -O2 A.hs [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: segmentation fault ghc -O2 A.hs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

Re: [GHC] #4017: Unhelpful error message in GHCi
by GHC 08 Oct '17

08 Oct '17

#4017: Unhelpful error message in GHCi -------------------------------------+------------------------------------- Reporter: simonpj | Owner: supersven Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by supersven): Looks like things (or symptoms) changed a bit over time - The problem seems to be the same. Starting a current version of GHC in interactive mode: {{{ [nix-shell:~/src/ghc]$ inplace/bin/ghc-stage2 --interactive GHCi, version 8.3.20170930: http://www.haskell.org/ghc/ :? for help }}} `:i GHC.Integer.Type.Integer` now responds with a "Not in scope" error. `:i Integer` still shows that `GHC.Integer.Type.Integer` is reachable: {{{ Prelude> :i GHC.Integer.Type.Integer <interactive>:1:1: error: Not in scope: ‘GHC.Integer.Type.Integer’ Prelude> :i Integer data Integer = integer-gmp-1.0.1.0:GHC.Integer.Type.S# GHC.Prim.Int# | integer-gmp-1.0.1.0:GHC.Integer.Type.Jp# {-# UNPACK #-}integer- gmp-1.0.1.0:GHC.Integer.Type.BigNat | integer-gmp-1.0.1.0:GHC.Integer.Type.Jn# {-# UNPACK #-}integer- gmp-1.0.1.0:GHC.Integer.Type.BigNat -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ instance Eq Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ instance Ord Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ instance Show Integer -- Defined in ‘GHC.Show’ instance Read Integer -- Defined in ‘GHC.Read’ instance Enum Integer -- Defined in ‘GHC.Enum’ instance Num Integer -- Defined in ‘GHC.Num’ instance Real Integer -- Defined in ‘GHC.Real’ instance Integral Integer -- Defined in ‘GHC.Real’ }}} Setting the "integer-gmp" package doesn't change the situation: {{{ Prelude> :set -package integer-gmp package flags have changed, resetting and loading new packages... Prelude> :i Integer data Integer = integer-gmp-1.0.1.0:GHC.Integer.Type.S# GHC.Prim.Int# | integer-gmp-1.0.1.0:GHC.Integer.Type.Jp# {-# UNPACK #-}integer- gmp-1.0.1.0:GHC.Integer.Type.BigNat | integer-gmp-1.0.1.0:GHC.Integer.Type.Jn# {-# UNPACK #-}integer- gmp-1.0.1.0:GHC.Integer.Type.BigNat -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ instance Eq Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ instance Ord Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ instance Show Integer -- Defined in ‘GHC.Show’ instance Read Integer -- Defined in ‘GHC.Read’ instance Enum Integer -- Defined in ‘GHC.Enum’ instance Num Integer -- Defined in ‘GHC.Num’ instance Real Integer -- Defined in ‘GHC.Real’ instance Integral Integer -- Defined in ‘GHC.Real’ Prelude> :i GHC.Integer.Type.Integer <interactive>:1:1: error: Not in scope: ‘GHC.Integer.Type.Integer’ }}} `GHC.Integer.Type` is still a hidden module: {{{ Prelude> import GHC.Integer.Type <no location info>: error: Could not find module ‘GHC.Integer.Type’ it is a hidden module in the package ‘integer-gmp-1.0.1.0’ }}} === Summary === The error message of `:i GHC.Integer.Type.Integer` changed to "Not in scope". But `:i Integer` still shows that the requested information would be available. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4017#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4017: Unhelpful error message in GHCi
by GHC 08 Oct '17

08 Oct '17

#4017: Unhelpful error message in GHCi -------------------------------------+------------------------------------- Reporter: simonpj | Owner: supersven Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * owner: (none) => supersven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4017#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13652: Add integer division to GHC.TypeLits
by GHC 08 Oct '17

08 Oct '17

#13652: Add integer division to GHC.TypeLits -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- GHC.TypeLits currently lacks integer division type families and I can't see why. What is the reason for not having these methods of the `Integral` class at type level: {{{#!hs quot rem div mod quotRem divMod }}} ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14320: Brackets change meaning of value-constructor type
by GHC 07 Oct '17

07 Oct '17

#14320: Brackets change meaning of value-constructor type -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: GADT, | Operating System: Linux existential type | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some legacy code from GHC 7.x does not compile under 8.0 or 8.2. The issue seems to be that I have wrapped brackets around the type of a value constructor, and 8.x does not want to see those brackets. To try to learn if this change was deliberate, I have searched the release notes. Found nothing. I am hoping this is an actual bug, as I would hope to be able to wrap any type or term in brackets without changing its meaning (except of course for fixity). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14256: GHCi is faster than compiled code
by GHC 06 Oct '17

06 Oct '17

#14256: GHCi is faster than compiled code -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- A stackoverflow user Milad Zahedi reports that running his code in GHCi is 50x faster than compiling it and running the compiled binary. > Today I did little benchmarking on my local machine to compare plain text speed of different Haskell web frameworks, and I noticed something strange. Almost all the frameworks that I tested, performed better when they were run from GHCi compared to compiled version. here are my results > {{{ +------------------------------------ |framework| GHCi rpm | compiled rpm +---------+------------+------------- |snap | 8000 | 150 +---------+------------+------------- |yesod | 6000 | 2500 +---------+------------+------------- |scotty | 22000 | 9500 +---------+------------+------------- |servant | 17000 | 8500 +---------+------------+------------- |spock | 3300 | 2700 +---------+------------+------------- }}} > I know that these numbers do not reflect on these frameworks speed, since they are not well tuned or optimized, but my question is why are these frameworks performing better when launched from GHCi. Am I doing something wrong ? > > in order to build them I simply run stack build The benchmarks are from https://github.com/miladz68/haskell-webframework- comparison This ticket is to verify and investigate these claims. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14327: Type error in program caused by unrelated definition
by GHC 06 Oct '17

06 Oct '17

#14327: Type error in program caused by unrelated definition -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ''Adapted from [https://stackoverflow.com/q/46595162/465378 this Stack Overflow question].'' The following program raises two type errors: {{{#!hs import Prelude hiding (readFile, writeFile) import Control.Monad.Free import Data.Functor.Sum data FileSystemF a = ReadFile FilePath (String -> a) | WriteFile FilePath String a deriving (Functor) data ConsoleF a = WriteLine String a deriving (Functor) data CloudF a = GetStackInfo String (String -> a) deriving (Functor) type App = Free (Sum FileSystemF (Sum ConsoleF CloudF)) readFile :: FilePath -> App String readFile path = liftF (InL (ReadFile path id)) writeFile :: FilePath -> String -> App () writeFile path contents = liftF (InL (WriteFile path contents ())) writeLine :: String -> App () writeLine line = liftF (InR (WriteLine line ())) }}} {{{ /private/tmp/free-sandbox/src/FreeSandbox.hs:26:27: error: • Couldn't match type ‘ConsoleF’ with ‘Sum ConsoleF CloudF’ arising from a functional dependency between constraints: ‘MonadFree (Sum FileSystemF (Sum ConsoleF CloudF)) (Free (Sum FileSystemF (Sum ConsoleF CloudF)))’ arising from a use of ‘liftF’ at src/FreeSandbox.hs:26:27-66 ‘MonadFree (Sum FileSystemF ConsoleF) (Free (Sum FileSystemF (Sum ConsoleF CloudF)))’ arising from a use of ‘liftF’ at src/FreeSandbox.hs:29:18-48 • In the expression: liftF (InL (WriteFile path contents ())) In an equation for ‘writeFile’: writeFile path contents = liftF (InL (WriteFile path contents ())) | 26 | writeFile path contents = liftF (InL (WriteFile path contents ())) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /private/tmp/free-sandbox/src/FreeSandbox.hs:29:18: error: • Couldn't match type ‘Sum ConsoleF CloudF’ with ‘ConsoleF’ arising from a functional dependency between: constraint ‘MonadFree (Sum FileSystemF ConsoleF) (Free (Sum FileSystemF (Sum ConsoleF CloudF)))’ arising from a use of ‘liftF’ instance ‘MonadFree f (Free f)’ at <no location info> • In the expression: liftF (InR (WriteLine line ())) In an equation for ‘writeLine’: writeLine line = liftF (InR (WriteLine line ())) | 29 | writeLine line = liftF (InR (WriteLine line ())) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The second of the two errors (the one on line 29) makes sense—it’s an error I would expect (there is a missing use of `InL`). However, the first error seems incorrect, as the definition of `writeFile` is, in fact, well- typed. In fact, if the definition of `writeLine` is commented out, the program typechecks! It gets weirder: if the definition of `writeLine` is moved in between the definitions of `readFile` and `writeFile`, then the unexpected error is reported for the definition of ''`readFile`'', and if `writeLine` is moved above both of them, then the error isn’t reported at all! This implies that a well-typed function (`writeFile`) can actually become ill-typed after the addition of an unrelated, ill-typed definition (`writeLine`). That seems like a bug to me. I was able to reproduce this issue on GHC 7.10.3, 8.0.2, and 8.2.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4