May 2017 - ghc-tickets

[GHC] #13311: Audit shady uses of tcSplitSigmaTy
by GHC 12 Jul '17

12 Jul '17

#13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 (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 fixing #12918, I ended up needing to introduce a helper function called `tcSplitNestedSigmaTys`, which is quite similar to `tcSplitSigmaTy`, except that it attempts to look through as many nested `forall`s as possible. (See the documentation for `tcSplitNestedSigmaTys` [http://git.haskell.org/ghc.git/blob/611f998fd545b45167170d9e60b7d9147178f0a… here]). In the process, I accidentally discovered a bug! First, consider this program: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where class C a where op :: forall b c. (Monoid b, Monoid c, Eq a) => a -> b -> c }}} This should be (and is) rejected, since we're trying to constrain `a` with `Eq` in `op`, but we don't have `-XConstraintedClassMethods` enabled. But what about this equivalent program? {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where class C a where op :: forall b. Monoid b => forall c. Monoid c => Eq a => a -> b -> c }}} By the same logic, this should also be rejected. But in GHC 8.0.2, it wasn't! That's because we were checking for the presence of constrained class variables using `tcSplitSigmaTy`, which only gives you `Monoid b` as the constraint, totally ignoring the bogus constraint inside of `forall c. Monoid c => Eq a => a -> b -> c`. When I fixed #12918 (a seemingly unrelated task), I ended up replacing that very use of `tcSplitSigmaTy` with `tcSplitNestedSigmaTys`. Now it gives you `(Monoid b, Monoid c, Eq a)` as expected when checking the constraints, and the second program is now rightly rejected on GHC HEAD. But I fear that there may be many more bogus uses of `tcSplitSigmaTy`. I should go through and try flushing out bugs of a similar caliber, and see if subbing in `tcSplitNestedSigmaTys` fixes these bugs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12089: :kind command allows unsaturated type family,
by GHC 12 Jul '17

12 Jul '17

#12089: :kind command allows unsaturated type family, -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: -------------------------------------+------------------------------------- {{{#!hs data A = B type family F a where F B = String infixr 9 `Compose` class (f (g x)) => (f `Compose` g) x instance (f (g x)) => (f `Compose` g) x }}} GHCi accepts {{{ ghci> :kind Compose Eq F Compose Eq F :: A -> Constraint }}} but when used in code it gets rejected {{{ -- tvI6.hs:13:8-33: error: … -- • The type family ‘F’ should have 1 argument, but has been given none -- • In the type signature: -- foo :: (Eq `Compose` F) a => String -- Compilation failed. foo :: (Eq`Compose`F) a => String foo = undefined }}} Bug? Version 8.0.0.20160511 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8346: Rank 1 type signature still requires RankNTypes
by GHC 11 Jul '17

11 Jul '17

#8346: Rank 1 type signature still requires RankNTypes ----------------------------+---------------------------------------------- Reporter: | Owner: tinctorius | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #2605 | ----------------------------+---------------------------------------------- When trying to figure out which type variable names are *actually* bound in `ScopedTypeVariables`, I tried floating `forall`s into the covariant argument of the function type. Essentially, I ran into the problem that programs like the following are rejected: {{{ #!hs {-# LANGUAGE ExplicitForAll #-} tuple :: forall a. a -> (forall b. b -> (a, b)) tuple = (,) }}} The message is as follows: {{{ Main.hs:2:10: Illegal polymorphic or qualified type: forall b. b -> (a, b) Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `tuple': tuple :: forall a. a -> (forall b. b -> (a, b)) }}} As far as I know, the rank of a type is defined by how deep quantifiers are nested in contravariant parts of that type. Or something like that. Also, as far as I know, `forall a. a -> (forall b. b -> (a, b))` is equivalent to `forall a b. a -> b -> (a, b)`, and more importantly, both are rank-1 polymorphic. There should be no need to use extensions that allow higher-ranked polymorphism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13568: Name is reported as ambiguous and not in scope
by GHC 11 Jul '17

11 Jul '17

#13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- {{{ module A where data T = A }}} {{{ module B where import A data S = A foo :: A -> () foo = undefined }}} Compiling this example, the usage of `A` in `foo` is reported as both ambiguous and out of scope. I haven't mentioned data kinds at all so `A` should certainly refer to a type constructor which isn't in scope. The problem is that `DataKinds` is checked too late in `lookup_demoted`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12390: List rules for `Coercible` instances
by GHC 11 Jul '17

11 Jul '17

#12390: List rules for `Coercible` instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: -------------------------------------+------------------------------------- `:info` on [https://downloads.haskell.org/~ghc/7.8.2/docs/html/libraries/base-4.7.0.0 /Data-Coerce.html#t:Coercible Data.Coerce.Coercible] doesn't display any instances, it's a special class so it should be special-cased {{{ ghci> :i Coercible type role Coercible representational representational class a ~R# b => Coercible (a :: k) (b :: k) -- Defined in ‘GHC.Types’ }}} The base case would be easy to display: {{{#!hs instance Coercible a a -- Generated on the fly }}} but it's trickier to describe the … instance succinctly: {{{#!hs instance Coercible b b' => Coercible (D a b c) (D a b' c') }}} same for newtypes. ---- Maybe it's better to list concrete examples {{{#!hs coerce @(Reader _ _) :: Reader a b -> (a -> Identity b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10150: Suppress orphan instance warning per instance
by GHC 11 Jul '17

11 Jul '17

#10150: Suppress orphan instance warning per instance -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the same way we have overlapping/incoherent instance pragmas which can be applied on a per instance basis, it would be good to have a `-fno-warn- orphan-instance` pragma which can be applied on a per-instance basis. Annoyingly, there is not an obvious syntax to use for this case, since SOP for a module with orphan instances is `{-# GHC_OPTIONS -fno-warn-orphans #-}` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12921: initTc: unsolved constraints
by GHC 10 Jul '17

10 Jul '17

#12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on a small project of mine, GHC panicked with the following error: {{{ lua-types-0.1.0.0: build Preprocessing executable 'lua-types' for lua-types-0.1.0.0... [2 of 3] Compiling Lua.Parser ( src/Lua/Parser.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.1.0/build/lua-types/lua-types- tmp/Lua/Parser.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161117 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] explist_a3nf :: t_a3ne[tau:1] (CHoleCan: explist) [W] funccall_a4dv :: t_a4du[tau:1] (CHoleCan: funccall)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} From a quick google search, it seems like this is a bug in the type checker. I'm not willing nor able to dive any further into the GHC code myself, though. I'll attach the code as it is, before looking for a workaround. I'm using stack, GHC version 8.0.1.20161117 for x86_64-apple-darwin. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11954: Associated pattern synonyms not included in haddock
by GHC 07 Jul '17

07 Jul '17

#11954: Associated pattern synonyms not included in haddock -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 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: -------------------------------------+------------------------------------- Running haddock on: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo ( A(P) ) where data A a = A pattern P = A }}} Just gives a data type A with no constructors, and no mention of the associated pattern synonym P. Attached is a patch for haddock that prints associated patterns as GADT constructors -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11954> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13739: Very slow linking of profiled executables
by GHC 07 Jul '17

07 Jul '17

#13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While building profiled executables with 8.2.1rc2 I've noticed the link times seem to have significantly regressed. I don't have a minimal test case. Testing on cabal head source tree {{{ cabal --version >cabal-install version 2.1.0.0 >compiled using version 2.1.0.0 of the Cabal library cabal new-configure --enable-profiling --enable-newer --with- ghc=/opt/ghc-8.2.1/bin/ghc cabal build cabal-install # hit Ctrl-C during linking time cabal build cabal-install }}} gives real 1m54.833s user 1m52.936s sys 0m1.620s doing the same with 8.0.2 links in less than a second -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 43

[GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification
by GHC 03 Jul '17

03 Jul '17

#13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | 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: -------------------------------------+------------------------------------- {{{#!hs -- Panic.hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE ExistentialQuantification #-} module Panic where import Data.STRef import Control.Monad.ST data A = forall a. A a st :: ST s () st = do A _ <- pure $ A True ref <- newSTRef 1 readSTRef ref pure () }}} {{{ $ ghc Panic.hs [1 of 1] Compiling Panic ( Panic.hs, Panic.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170106 for x86_64-unknown-linux): StgCmmEnv: variable not found $dMonad_aGQ local binds for: $trModule $tcA $tc'A $tcA1_rSi $tc'A1_rSJ $trModule1_rSK $trModule2_rSL sat_sT5 sat_sT9 sat_sTa Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:137:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The above module fails to compile, giving the pasted panic message. Without the ApplicativeDo pragma compilation succeeds. Reproduced with GHC 8.0.2 and a recent head, courtesy of nixpkgs: {{{ gp84vpgar3n3rqvkwj47yyhxvsvbsmi6-ghc-8.1.20170106 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21