- ghc-tickets - Haskell.org

[GHC] #14408: error in refineFromInScope
by GHC 08 Nov '17

08 Nov '17

#14408: error in refineFromInScope -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- There are several instances of the following line in the output in a validate build: {{{ WARNING: file compiler/simplCore/SimplEnv.hs, line 678 $j_setr }}} For example: https://phabricator.haskell.org/harbormaster/build/36855/?l=0, the harbourmaster build of 609f2844b92d5aa474f34b989c6ec5ad9fdb2ce3. That line indicates that said warning "is an error!" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14408> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12791: Superclass methods could be more aggressively specialised.
by GHC 08 Nov '17

08 Nov '17

#12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- Say `R` is a superclass of `MR` but only uses one of the type variables. If this type variable is fixed then we know that we are going to use the specific dictionary. Thus, the optimiser *could* specialise all methods from the superclass at this point leading to better code. {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleContexts #-} module Foo where class R t => MR t m where push :: t -> m -> Int class R t where pull :: t -> Int --type MR2 t m = (R t, MR t m) instance MR Int Int where push = max instance R Int where pull = negate myf :: (MR Int a) => a -> Int -> Int myf _ = pull }}} To give a concrete example, `R` is a super class of `MR` but only mentions the first type variable. Thus when we fix it in `myf`, we could optimise the definition to `myf _ = negate` by inlining the class method. Reid points out that if you have a definition like {{{ data X = X f :: R X => Int -> Int f = pull }}} then the instance for `R X` could be provided by another module. However it is common to structure large applications with super class constraints so it would be desirable to do better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #14433: Windows10 GHCI Crash, it can't run correctly
by GHC 08 Nov '17

08 Nov '17

#14433: Windows10 GHCI Crash, it can't run correctly --------------------------------------+---------------------------------- Reporter: Shizumi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- I followed the Haskel Platform website download the version 8.2.1 and installed it sucessfully, i add the extra path too.But when I open GHCI in start menu or in PowerShell,it cant run sucessfully, below are the error message, ps: here is Windows 10 Pro Insider Preview, does it matter or what? PS C:\Users\SHIZU-NOTEBOOK\Desktop> ghci GHCI, version 8.2.1: http://www.haskell.org/ghc/ :? for help ghc.exe: internal error: mkPath failed converting char* to wchar_t* (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #83: typo: %lt; should be <
by GHC 08 Nov '17

08 Nov '17

#83: typo: %lt; should be < ---------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 5.04.1 Resolution: Fixed | Keywords: Type of failure: None/Unknown | ---------------------------------+-------------------- Changes (by Mateusz Kowalczyk <fuuzetsu@…>): * failure: => None/Unknown Comment: In [changeset:"ed18f47f931361a9adbb109085c6feb432ec41aa/ghc" ed18f47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ed18f47f931361a9adbb109085c6feb432ec41aa" Factor out builds into steps. Address ghc/ghc#83 comments. This should greatly improve log output. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/83#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14410: Windows 10 freeze caused by infinite recursion in WinGHCi
by GHC 08 Nov '17

08 Nov '17

#14410: Windows 10 freeze caused by infinite recursion in WinGHCi -------------------------------------+------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: freeze | Operating System: Windows infinite recursion | Architecture: x86_64 | Type of failure: Other (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Got Windows freeze after I typed this in WinGHCi : {{{ Prelude> fib2 a b n = fib2 b (a+b) (n-1) Prelude> fib2 3 3 1 }}} With option +RTS -M1000m I didn't get the Windows freeze but the termination of the calculation didn't work in WinGHCi . Operating system : Windows 10 64 Bit . -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14410> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14395: Redefining pattern synonym in GHCi triggers "‘p’ is untouchable" error
by GHC 08 Nov '17

08 Nov '17

#14395: Redefining pattern synonym in GHCi triggers "‘p’ is untouchable" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Load this file into GHCi: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} module Bug where data Foo a where FooInt :: Foo Int pattern Bar :: () => (a ~ Int) => Foo a pattern Bar = FooInt }}} And attempt to redefine `Bar` as follows: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, 1 module loaded. λ> pattern Bar = Nothing <interactive>:1:15: error: • Couldn't match expected type ‘p’ with actual type ‘Maybe a0’ ‘p’ is untouchable inside the constraints: a ~ Int bound by a pattern with pattern synonym: Bar :: forall a. () => a ~ Int => Foo a, in an equation for ‘pattern’ at <interactive>:1:9-11 ‘p’ is a rigid type variable bound by the inferred type of pattern :: Foo a -> p at <interactive>:1:1-21 Possible fix: add a type signature for ‘pattern’ • In the expression: Nothing In an equation for ‘pattern’: pattern Bar = Nothing • Relevant bindings include pattern :: Foo a -> p (bound at <interactive>:1:1) }}} There are two issues here: 1. There are several places in the error message that refer to a `pattern` with no name! {{{ in an equation for ‘pattern’ }}} {{{ the inferred type of pattern :: Foo a -> p at <interactive>:1:1-21 }}} {{{ • Relevant bindings include pattern :: Foo a -> p (bound at <interactive>:1:1) }}} 2. Why is this error happening in the first place? The error message mentions the type `Foo a -> p`, but in `pattern Bar = Nothing`, there isn't anything that should touch `Foo`. Note that this bug does not occur if a slightly different (but ostensibly equivalent) type signature for `Bar` is given in the original source file: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} module Works where data Foo a where FooInt :: Foo Int pattern Bar :: Foo Int pattern Bar = FooInt }}} {{{ λ> pattern Bar = Nothing λ> :i Bar pattern Bar :: Foo Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14438: Using a (meaningless) generic currency sign (¤) instead of $ causes panicing
by GHC 07 Nov '17

07 Nov '17

#14438: Using a (meaningless) generic currency sign (¤) instead of $ causes panicing --------------------------------------+--------------------------------- Reporter: Izmaki | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.0.2 Keywords: ¤ | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The following two lines of HS produces the reported error. It was actually a mistype and probably not that serious, but I was told to report it. The issue is combining the "generic currency" symbol ¤ with the Integral constraint (using e.g. Integer instead as the constraint does not produce the same error). {{{#!hs Prelude> let ones x = snd $ divMod x 10 Prelude> ones ¤ (5 :: Integral) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] ¤_a2l9 :: t_a2l8[tau:1] (CHoleCan: ¤) [W] ¤_a2lJ :: t_a2lI[tau:1] (CHoleCan: ¤)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14436: Teach TemplateHaskell to generate less eye-hurting names
by GHC 07 Nov '17

07 Nov '17

#14436: Teach TemplateHaskell to generate less eye-hurting names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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 you look at the Haddocks for, e.g., the `singletons` package, one sees dozens of signatures containing unsightly names containing long integers. For instance, in the equation list for `Data.Singletons.Prelude.Either.IsLeft` we have {{{ IsLeft (Left _z_6989586621679437436) = TrueSym0 IsLeft (Right _z_6989586621679437439) = FalseSym0 }}} For definitions with lots of variables things quickly become unreadable. These names appear this way because they are generated by TemplateHaskell's `newName` function. This name is ultimately converted to a GHC `System` name by `Convert.thRdrName`. Such `Name`s are then pretty- printed including their uniques (see `Name.pprSystem`). I'm not sure I see the rationale for this. Surely if the names are tidied properly (e.g. using `TyConRep.tidyType`) there should be no need for the unique suffix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever
by GHC 07 Nov '17

07 Nov '17

#14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Thanks to Christiaan Baaij for noticing this. Take this program: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Type.Equality import GHC.TypeLits type family Replicate (n :: Nat) (x :: a) :: [a] where Replicate 0 _ = '[] Replicate n x = x : Replicate (n - 1) x replicateSucc :: (Replicate (k + 1) x) :~: (x : Replicate k x) replicateSucc = Refl }}} Note that this program does not typecheck (nor should it). In GHC 8.0.2 and 8.2.1, if you compile this with no tracing flags, it'll give the error: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:16:17: error: • Couldn't match type ‘Replicate (k + 1) x’ with ‘x : Replicate k x’ Expected type: Replicate (k + 1) x :~: (x : Replicate k x) Actual type: (x : Replicate k x) :~: (x : Replicate k x) • In the expression: Refl In an equation for ‘replicateSucc’: replicateSucc = Refl • Relevant bindings include replicateSucc :: Replicate (k + 1) x :~: (x : Replicate k x) (bound at Bug.hs:16:1) | 16 | replicateSucc = Refl | ^^^^ }}} Things become interesting when you compile this program with `-ddump-tc- trace`. In GHC 8.0.2, it'll trace some extra output and eventually reach the same error as above. In 8.2.1, however, the tracing hangs, causing compilation to never terminate! Here is the output right before it hangs: {{{ lk1 : tc_infer_args (invis) @a_11 tc_infer_args (vis) [anon] a_11 x_a1Dt lk1 x_a1Dt u_tys tclvl 1 k0_a1GD[tau:1] ~ a0_a1GF[tau:1] arising from a type equality k0_a1GD[tau:1] ~ a0_a1GF[tau:1] found filled tyvar k_a1GD[tau:1] :-> a0_a1GE[tau:1] u_tys tclvl 1 * ~ * arising from a kind equality arising from a0_a1GE[tau:1] ~ a0_a1GF[tau:1] u_tys tclvl 1 'GHC.Types.LiftedRep ~ 'GHC.Types.LiftedRep arising from a kind equality arising from a0_a1GE[tau:1] ~ a0_a1GF[tau:1] u_tys yields no coercion u_tys yields no coercion writeMetaTyVar a_a1GE[tau:1] :: * := a0_a1GF[tau:1] u_tys yields no coercion checkExpectedKind k0_a1GD[tau:1] a0_a1GF[tau:1] <a0_a1GF[tau:1]>_N tc_infer_args (vis) [anon] [a_11] Replicate (n_a1Ds - 1) x_a1Dt lk1 Replicate instantiating tybinders: @a_a1Dp := a0_a1GG[tau:1] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout
by GHC 06 Nov '17

06 Nov '17

#14415: Win32 SEH unwinding should print segfaults to stderr, not stdout -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Looking at ghc/rts/win32/veh_excn.c we can see that on segfaults, e.g. null pointer access, GHC calls: {{{ fprintf(stdout, "Access violation in generated code" }}} Given these are segfaults, it seems that stderr would be a more appropriate stream to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3