- ghc-tickets - Haskell.org

[GHC] #15100: `ApplicativeDo` needlessly uses `join` too much
by GHC 30 Apr '18

30 Apr '18

#15100: `ApplicativeDo` needlessly uses `join` too much -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (CodeGen) | 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 foo = do A 1 B 2 C 3 return () }}} produces very different code than {{{#!hs foo = do A 1 B 2 C 3 }}} for no good reason. Currently we check to see if the last clause is a `return` or something else, and then bolt a `join` in if it isn't `return`. But this check is too conservative. If it isn't a `return` but doesn't reference any of the variables above, you can still desugar it with `(<*>)`. We found this during a twitch livestream in front of an audience of 127 people. =) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15089: Compiling stage2 with -g causes spurious test suite failures due to stderr mismatches
by GHC 29 Apr '18

29 Apr '18

#15089: Compiling stage2 with -g causes spurious test suite failures due to stderr mismatches -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 you compile stage2 libraries with -g by using `GhcLibHcOpts` then many tests fail with stderr mismatch errors. It would perhaps be more robust to pass `-dsuppress-ticks` by default to tests so that it is possible to compile with debugging information and still run tests successfully. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15097: Missing instance Applicative (K1 i c)
by GHC 28 Apr '18

28 Apr '18

#15097: Missing instance Applicative (K1 i c) -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.2 Libraries | 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.Generics has common instances for various haskell classes. It is missing the instance for Applicative (K1 i c) -- `K1 i` is morally like `Const` so it should have the same set of instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15083: cannot install GHC on CentOS
by GHC 27 Apr '18

27 Apr '18

#15083: cannot install GHC on CentOS -------------------------------------+------------------------------------- Reporter: kbrown | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is the information of my system: {{{ > cat /etc/*release CentOS Linux release 7.4.1708 (Core) NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" }}} I want to build a Stack project on this system, but I receive an "impossible" error even when I try to build a trivial project. {{{ >wget https://www.stackage.org/stack/linux-x86_64-static >tar -xzf linux-x86_64-static > cp stack-1.6.5-linux-x86_64-static/stack .local/bin/ > stack new stacktest Downloading template "new-template" to create project "stacktest" in stacktest/ ... The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username You can provide them in /home/users/ksb/.stack/config.yaml, like this: templates: params: author-email: value author-name: value category: value copyright: value github-username: value Or you can pass each one as parameters like this: stack new stacktest new-template -p "author-email:value" -p "author- name:value" -p "category:value" -p "copyright:value" -p "github- username:value" Looking for .cabal or package.yaml files to use to init the project. Using cabal packages: - stacktest/ Selecting the best among 13 snapshots... * Matches lts-11.6 Selected resolver: lts-11.6 Initialising configuration using resolver: lts-11.6 Total number of user packages considered: 1 Writing configuration to file: stacktest/stack.yaml All done. > stack build [1 of 2] Compiling Main ( /home/users/ksb/.stack/setup-exe-src /setup-mPHDZzAJ.hs, /home/users/ksb/.stack/setup-exe-src/setup-mPHDZzAJ.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): toStgWord: Unknown platformWordSize: 0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building simple Setup.hs using: /home/users/ksb/.stack/programs/x86_64-linux/ghc-8.2.2/bin/ghc -rtsopts -threaded -clear-package-db -global-package-db -hide-all-packages -package base -main-is StackSetupShim.mainOverride -package Cabal-2.0.1.0 /home/users/ksb/.stack/setup-exe-src/setup-mPHDZzAJ.hs /home/users/ksb/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -o /home/users/ksb/.stack/setup-exe-cache/x86_64-linux/tmp-Cabal- simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 Process exited with code: ExitFailure 1 }}} Can you help me identify why this build failed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15057: Lint types created by newFamInst
by GHC 27 Apr '18

27 Apr '18

#15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15012 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #15012, we observed a terrible failure resulting from `newFamInst` creating a type family instance with an unbound type variable on the right-hand side. What's worse, `-dcore-lint` didn't catch it! Let's fix that by calling `lintType` on the types involved in `newFamInst`. A wrinkle in this plan is that `lintType` currently expands all type synonyms, but the offending type in #15012 had the unbound variable occur in a type synonym application, so expanding type synonyms would make this naughtiness seemingly vanish (from Core Lint's perspective). We should configure `lintType` so that one can control its type synonym expansion behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15057> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14149: Tyepchecker generates top-level unboxed coercion
by GHC 27 Apr '18

27 Apr '18

#14149: Tyepchecker generates top-level unboxed coercion -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Consider this code {{{ {-# OPTIONS_GHC -fdefer-out-of-scope-variables #-} module Foo where import Data.Coerce f :: Bool f = coerce (k :: Int) }}} It generates a lint error: {{{ *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: [RHS of cobox_a11N :: (Int :: *) ~R# (Bool :: *)] The type of this binder is unlifted: cobox_a11N Binder's type: (Int :: *) ~R# (Bool :: *) *** Offending Program *** $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Foo"#) cobox_a11N :: (Int :: *) ~R# (Bool :: *) [LclId[CoVarId]] cobox_a11N = typeError @ ('TupleRep '[]) @ ((Int :: *) ~R# (Bool :: *)) "Foo.hs:8:5: error:\n\ \ \\226\\128\\162 Couldn't match representation of type \\226\\128\\152Int\\226\\128\\153 with that of \\226\\128\\152Bool\\226\\128\\153\n\ \ arising from a use of \\226\\128\\152coerce\\226\\128\\153\n\ \ \\226\\128\\162 In the expression: coerce (k :: Int)\n\ \ In an equation for \\226\\128\\152f\\226\\128\\153: f = coerce (k :: Int)\n\ \(deferred type error)"# f :: Bool [LclIdX] f = (typeError @ 'LiftedRep @ Int "Foo.hs:8:13: error: Variable not in scope: k :: Int\n\ \(deferred type error)"#) `cast` (cobox_a11N :: (Int :: *) ~R# (Bool :: *)) *** End of Offense *** }}} Reason: this rather hacky test in `TcUnify.buildImplication` {{{ ; if null skol_tvs && null given && (not deferred_type_errors || not (isTopTcLevel tc_lvl)) }}} did take account of `Opt_DeferOutOfScopeVariables`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14955: Musings on manual type class desugaring
by GHC 27 Apr '18

27 Apr '18

#14955: Musings on manual type class desugaring -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: SpecConstr | 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 wrote a short post explaining why manual type class desugaring was different to actually writing a type class because of how they are optimised. http://mpickering.github.io/posts/2018-03-20-recordsvstypeclasses.html I implement 4 different equivalent programs which are all optimised differently. I paste the whole file below as it is not very big. Implementation 1 is in terms of a type class. Implementation 2 is in terms of explicit dictionary passing. Implementation 3 wraps a dictionary in a type class Implementation 4 wraps a dictionary in a type class with an additional dummy argument. Naively, a user would expect all 4 implementations to be as fast as each other. {{{ {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE AllowAmbiguousTypes #-} module Prop where import Prelude (Bool(..), (||), (&&)) -- Implementation 1 class Prop r where or :: r -> r -> r and :: r -> r -> r true :: r false :: r instance Prop Bool where or = (||) and = (&&) true = True false = False -- Implementation 2 data PropDict r = PropDict { dor :: r -> r -> r , dand :: r -> r -> r , dtrue :: r , dfalse :: r } boolDict = PropDict { dor = (||) , dand = (&&) , dtrue = True , dfalse = False } -- Implementation 3 class PropProxy r where propDict :: PropDict r instance PropProxy Bool where propDict = boolDict -- Implementation 4 class PropProxy2 r where propDict2 :: PropDict r dummy :: () instance PropProxy2 Bool where propDict2 = boolDict dummy = () ors :: Prop r => [r] -> r ors [] = true ors (o:os) = o `or` ors os {-# INLINABLE ors #-} dors :: PropDict r -> [r] -> r dors pd [] = dtrue pd dors pd (o:os) = dor pd o (dors pd os) pors :: PropProxy r => [r] -> r pors [] = dtrue propDict pors (o:os) = dor propDict o (pors os) {-# INLINABLE pors #-} porsProxy :: PropProxy2 r => [r] -> r porsProxy [] = dtrue propDict2 porsProxy (o:os) = dor propDict2 o (porsProxy os) {-# INLINABLE porsProxy #-} }}} Then using the 4 different implementations of `ors` in another module implementations 1 and 4 are fast whilst 2 and 3 are slow. https://github.com/mpickering/rtcwrao-benchmarks/blob/master/Prop2.hs {{{ benchmarking tc/Implementation 1 time 3.510 ms (3.509 ms .. 3.512 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 2.976 ms (2.886 ms .. 3.060 ms) std dev 241.1 μs (195.4 μs .. 293.1 μs) variance introduced by outliers: 51% (severely inflated) benchmarking tc/Implementation 2 time 25.05 ms (21.16 ms .. 30.43 ms) 0.912 R² (0.849 R² .. 0.984 R²) mean 19.18 ms (16.20 ms .. 21.45 ms) std dev 5.627 ms (4.710 ms .. 6.618 ms) variance introduced by outliers: 89% (severely inflated) benchmarking tc/Implementation 3 time 20.06 ms (15.33 ms .. 23.57 ms) 0.856 R² (0.755 R² .. 0.934 R²) mean 18.43 ms (16.92 ms .. 19.85 ms) std dev 3.490 ms (3.003 ms .. 4.076 ms) variance introduced by outliers: 74% (severely inflated) benchmarking tc/Implementation 4 time 3.498 ms (3.484 ms .. 3.513 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 3.016 ms (2.935 ms .. 3.083 ms) std dev 205.7 μs (162.6 μs .. 261.8 μs) variance introduced by outliers: 42% (moderately inflated) }}} I compiled the module with `-O2`. If I turn off `-fno-worker-wrapper` and `-fno-spec-constr` then implementation 3 is also fast. Implementation 2 is always slow. This ticket is querying what could be done to improve the robustness of these different refactorings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15092: Optionally bounds-check primops
by GHC 27 Apr '18

27 Apr '18

#15092: Optionally bounds-check primops -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | 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: -------------------------------------+------------------------------------- It would be awfully nice if there were a way to optionally get bounds- checked versions of array primitives. The idea would be that if GHC is compiled with a bounds-checking option, then the code generator would use primops that verify indices are in bounds. Based on [https://mail.haskell.org/pipermail/haskell-cafe/2018-April/128992.html a question by Henning Thielemann], I suspect such a feature would get some use. The biggest challenge: `SomeException`, `Typeable`, `Show`, `String`, `CallStack`, etc., all live in an entirely different universe than the primops, so it's not exactly obvious how to get started. I don't know if it would be possible to inject references to such things into a lower level. Sounds hard, but maybe it's possible. An alternative, probably much simpler, approach would be to crash hard with an error message instead of trying to throw a proper exception. Ideally, the error message would include the name of the primop and (for modules compiled with profiling) some call stack info. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14421: LambdaCase should be suggested if it is used but not enabled
by GHC 26 Apr '18

26 Apr '18

#14421: LambdaCase should be suggested if it is used but not enabled -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | 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: -------------------------------------+------------------------------------- If I try to make a multiparameter typeclass GHC (well, GHCi here) advises me to turn on {{{MultiParamTypeClasses}}} {{{ Prelude> class C a b where ... (Use MultiParamTypeClasses to allow multi-parameter classes) }}} But if I try to use {{{\case}}} it doesn't give me a helpful suggestion {{{ Prelude> :t \case (_,_) -> () <interactive>:1:2: error: parse error on input ‘case’ }}} Could it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13520: instance Alternative ZipList
by GHC 26 Apr '18

26 Apr '18

#13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- The paper "From monoids to near-semirings: the essence of MonadPlus and Alternative`" mentions > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. Like the `Alternative` instance for `Maybe`, the one for `ZipList` has a left bias. > > {{{#!hs > instance Alternative ZipList where > empty :: ZipList a > empty = ZL [] > > (<|>) :: ZipList a -> ZipList a -> ZipList a > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > }}} Has this been considered for base? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11