- ghc-tickets - Haskell.org

[GHC] #16380: HPC's CLI is awkward
by GHC 03 Mar '19

03 Mar '19

#16380: HPC's CLI is awkward -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Code Coverage | Version: 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: -------------------------------------+------------------------------------- hpc's command line interface could be brought more in line with other Haskell tools (and most CLIs I've used). I would expect all of the following commands to work: {{{ hpc --version hpc --help hpc markup --help }}} Currently these commands are: {{{ hpc version hpc help hpc help markup }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16372: GHC can't constant fold even basic power (^) applications for Int (and others?)
by GHC 03 Mar '19

03 Mar '19

#16372: GHC can't constant fold even basic power (^) applications for Int (and others?) -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!hs [nix-shell:/tmp]$ ghc -O2 -fforce-recomp -ddump-simpl S.hs 2>&1 | tail [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 50 20}] foo = case GHC.Real.$wf1 2# 1# of ww2_a2zt { __DEFAULT -> GHC.Types.I# ww2_a2zt } [nix-shell:/tmp]$ cat S.hs module S (fuck) where foo :: Int foo = (2 :: Int) ^ (1 :: Int) }}} This seems like a fairly strange thing to not optimise when constants are known on both sides. I'm complaining about Int for this particular ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16363: Modular constant folding
by GHC 03 Mar '19

03 Mar '19

#16363: Modular constant folding -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 code (taken from #16329): {{{#!hs func :: Int -> IO Int func n = foldM step 0 xs where xs = map (n+) [1,2,3] step acc x = case x `mod` 3 of 0 -> pure acc 1 -> pure $ acc + 1 2 -> pure $ acc + 2 func' n = foldl step 0 xs where xs = map (n+) [1,2,3] step acc x = case x `mod` 3 of 0 -> acc 1 -> acc + 1 2 -> acc + 2 }}} is simplified to the following core code: {{{#!hs func n = case n + 1 `mod` 3 of 0 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 0 1 -> pure 1 2 -> pure 2 1 -> case n + 3 `mod` 3 of 0 -> pure 1 1 -> pure 2 2 -> pure 3 2 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 1 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 1 1 -> pure 2 2 -> pure 3 1 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 2 -> case n + 3 `mod` 3 of 0 -> pure 3 1 -> pure 4 2 -> pure 5 2 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 1 -> case n + 3 `mod` 3 of 0 -> pure 3 1 -> pure 4 2 -> pure 5 2 -> case n + 3 `mod` 3 of 0 -> pure 4 1 -> pure 5 2 -> pure 6 func' n = join j2 w2 = join j1 w1 = case n + 3 `mod` 3 of 0 -> w1 1 -> w1 + 1 2 -> w1 + 2 in case n + 2 `mod` 3 of 0 -> jump j1 w2 1 -> jump j1 (w2 + 1) 2 -> jump j1 (w2 + 2) in case n + 1 `mod` 3 of 0 -> jump j2 0 1 -> jump j2 1 2 -> jump j2 2 }}} Case-folding with modular arithmetic should remove the nesting. (patch coming) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13002: :set -O does not work in .ghci file
by GHC 03 Mar '19

03 Mar '19

#13002: :set -O does not work in .ghci file --------------------------------------+---------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{#!hs {-# OPTIONS_GHC -Wall #-} module Foo where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) }}} {{{ cat ~/.ghci :set +s :set -fobject-code :set -O bash-3.2$ touch Foo.hs bash-3.2$ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 8,885,888 bytes) Prelude Foo> :quit :quit Leaving GHCi. bash-3.2$ touch Foo.hs bash-3.2$ ghci -fobject-code -O GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 98,400 bytes) }}} While supplying -fobject-code -O as an argument to ghci seems like an easy workaround that isn't feasible as far as I know when using emacs thus setting priority to normal rather than low. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2
by GHC 03 Mar '19

03 Mar '19

#12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Other Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From IRC: I have a module that takes around 10 seconds to compile on ghc --make -O2, but only around 3 seconds on ghci -fobject-code -O2. > bgamari: that is surprising I've put the -v timing output of the two cases into https://gist.github.com/nh2/e9bc4732111bfe422d8e606c10f8f0ac I'm comparing the 2 files with `meld` for spotting differences easily. Check e.g. `Result size of Tidy Core` which seems to have 3x as many terms for ghc, and `Simplifier [Mymodule]` doesn't seem to run in ghci The first time terms are different is at `Desugar, the first time a factor 3 comes in is after `Specialize`. > bgamari: wow, it sounds like the simplifier isn't getting run as aggressively in GHCi I'm running this on Ubuntu 16.04 inside nix (but happens the same way outside nix). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15857: Need for better warnings arising from StarIsType extension
by GHC 02 Mar '19

02 Mar '19

#15857: Need for better warnings arising from StarIsType extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.1 Keywords: StarIsType | Operating System: Unknown/Multiple NoStarIsType | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I redefine `type (*) = (,)` I am given not given a warning that it doesn't do what I expect, when building with cabal new-repl or cabal new- build, because the `StarIsType` extension is now enabled by default. Instead or a warning, I get (correct but confusing) error messages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15857> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14069: RTS linker maps code as writable
by GHC 02 Mar '19

02 Mar '19

#14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime | Version: 8.0.1 System (Linker) | 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's RTS linker maps executable code in writable pages, representing a significant potential exploit point for arbitrary code execution. OpenBSD disallows running program that do this by default. Fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #16377: `TypeError` in a pattern should flag inaccessible code
by GHC 01 Mar '19

01 Mar '19

#16377: `TypeError` in a pattern should flag inaccessible code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Type checker) | 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 we pattern match, if the context ends up having a custom `TypeError`, we should probably report it, as we've essentially found some inaccessible code. At present this doesn't happen and the custom error is only triggered if the function is applied to an invalid argument. Here is an example to illustrate the issue: {{{ {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE GADTs #-} module Test where import GHC.TypeLits import Data.Kind(Constraint) type family F a :: Constraint type instance F Int = () type instance F Char = TypeError ('Text "Nope") type instance F Bool = (Int ~ Char) data T where A :: F Int => T B :: F Char => T C :: F Bool => T exhaustive :: T -> () exhaustive A = () exhaustive B = () -- this is not flagged as inaccessible, but it should -- exhaustive C = () -- this is flagged as inaccessible, as expected }}} If the match with constructor `C` is added to the program, GHC detects that this equation is inaccessible because `Int` will never match `Char`. I think that we'd like the same to happen in the second equation when we match on `B`, except we should report the custom type error, instead of GHC's message about unreachable code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11503: TypeError woes (incl. pattern match checker)
by GHC 01 Mar '19

01 Mar '19

#11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: 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: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeFamilies, UndecidableInstances #-} {-# OPTIONS_GHC -fwarn-incomplete-patterns #-} module Bug where import GHC.TypeLits import GHC.Exts ( Constraint ) type family NotInt a where NotInt Int = TypeError (Text "That's Int, silly.") NotInt _ = (() :: Constraint) data T a where MkT1 :: a -> T a MkT2 :: NotInt a => T a foo :: T Int -> Int foo (MkT1 x) = x }}} I get {{{ Bug.hs:19:1: warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: MkT2 }}} But I shouldn't. Even worse, perhaps, GHC accepts my pattern-match against `MkT2` if I add it. If I change the `TypeError` to `False ~ True`, I get the correct behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11503> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16199: GHC 8.6's bundled version of transformers doesn't correspond to a Hackage release
by GHC 01 Mar '19

01 Mar '19

#16199: GHC 8.6's bundled version of transformers doesn't correspond to a Hackage release -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14678 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.6 claims to be bundled with `transformers-0.5.5.0`, but this isn't true. That's because it's using transformers commit https://gitlab.haskell.org/ghc/packages/transformers/tree/80557845cdc0e72bc05cec19cf7a1bf5495e9e69, which happened //after// the commit corresponding to the Hackage release of 0.5.5.0 (https://gitlab.haskell.org/ghc/packages/transformers/commit/33b3c8a71778ae3…) This is not the first time this has happened: see #14678. While we were able to catch #14678 before a major release was shipped, but unfortunately, that didn't happen this time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14