- ghc-tickets - Haskell.org

[GHC] #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic!
by GHC 11 Dec '15

11 Dec '15

#11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: numeric | Operating System: Unknown/Multiple literal, partial type signature, | the impossible happened, panic | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I use a partial type signature in a non-top-level let-binding (or where clause), ''and'' the type is sufficiently ambiguous, ''and'' the binding in question uses a numeric literal, I get a panic from GHC instead of a report of the inferred type of the hole. So, this breaks: {{{#!hs module Fails where fails :: a fails = let go :: _ go 0 a = a in go (0 :: Int) undefined }}} {{{ Fails.hs:7:11: Couldn't match expected type ‘a’ with actual type ‘Int’ ‘a’ is untouchable inside the constraints () bound by the type signature for fails :: a1 at Fails.hs:3:10ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): No skolem info: a_a1iD[sk] }}} ...but this succeeds: {{{#!hs module Succeeds where succeeds :: a succeeds = let go :: _ go _ a = a in go (0 :: Int) undefined }}} {{{ Succeeds.hs:13:14: Found hole ‘_’ with type: t -> t1 -> t1 Where: ‘t’ is a rigid type variable bound by the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8 ‘t1’ is a rigid type variable bound by the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8 To use the inferred type, enable PartialTypeSignatures <snip> }}} The '''only''' difference between these two modules is the use of a numeric literal in a pattern match; that is, the troublesome line boils down to: {{{#!hs go 0 a = a }}} vs. {{{#!hs go _ a = a }}} Note that GHC gives us several pieces of feedback before talking about the panic. Before the above-quoted error, we get: {{{ Fails.hs:5:14: Found hole ‘_’ with type: a2 -> t1 -> t1 Where: ‘t1’ is a rigid type variable bound by the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1 at Fails.hs:6:8 ‘a2’ is a rigid type variable bound by the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1 at Fails.hs:6:8 To use the inferred type, enable PartialTypeSignatures <snip> Fails.hs:6:8: No instance for (Eq a) When checking that ‘go’ has the specified type go :: forall t a. a -> t -> t Probable cause: the inferred type is ambiguous <snip> Fails.hs:7:7: Couldn't match expected type ‘a1’ with actual type ‘t’ because type variable ‘a1’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for fails :: a1 at Fails.hs:3:10 <snip> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 11 Dec '15

11 Dec '15

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * owner: thoughtpolice => * priority: high => normal Comment: Demoting priority as we have disabled dynamic linking on Windows (see comment:29). My understanding of this situation is that it is not an intrinsic limitation of PE. The relevant data structures are the `.edata` and `.idata` tables which are defined in sections 63 and 64 of the PE/COFF specification. The specification specifies that one means of referring to exported symbols is via a 16-bit ordinal. However, this is not the only way; if the lookup fails the loader will fall back to a standard name search. Indeed, Microsoft even explicitly says that ordinals [[https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx|are a legacy artifact]] and their use is discouraged in new code (this document describes the `.def` format, but the idea still applies), > You can use @ordinal to specify that a number, and not the function name, will go into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don’t recommend exporting functions by ordinal unless your DLL’s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL. For this reason I believe the problem is in fact that `ld.bfd` is producing DLLs with symbols exported by (or perhaps objects that are imported by) ordinal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11187: Odd interaction between type families and coercions (regression)
by GHC 10 Dec '15

10 Dec '15

#11187: Odd interaction between type families and coercions (regression) -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies #-} module Wonk where import Data.Type.Coercion type family X coercionXX :: Coercion X X coercionXX = Coercion }}} This works just fine in 7.8.3, but in 7.10.2 it gives the following peculiar error: {{{ Couldn't match representation of type ‘X’ with that of ‘X’ NB: ‘X’ is a type function, and may not be injective In the expression: Coercion In an equation for ‘coercionXX’: coercionXX = Coercion }}} I don't even know what it means for a ''nullary'' type function to be injective. I tried the following workarounds: {{{#!hs coercionXX1 :: Coercion X X coercionXX1 = c where c :: x ~ X => Coercion x x c = Coercion coercionXX2 :: Coercion X X coercionXX2 = c where c = Coercion }}} Interestingly, `coercionXX1` seems to work under all circumstances, with or without the top-level type signature; `coercionXX2` works if it's in a `.hs` file, but does ''not'' work if entered by hand at the `ghci` prompt (it produces a similar error). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11183: Numeric.showFFloat outputs decimal point when it should not.
by GHC 09 Dec '15

09 Dec '15

#11183: Numeric.showFFloat outputs decimal point when it should not. -------------------------------------+------------------------------------- Reporter: Dobiasd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: Numeric, | Operating System: Unknown/Multiple showFFloat, showFFloatAlt | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs showFFloat Nothing 42 "" }}} The expression above should give "42" but actually gives "42.0". Only showFFloatAlt should do this. Minimal example: http://ideone.com/yYvqrf -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11181: Program hands forever in sched_yield() / yield() unless -N is limited
by GHC 09 Dec '15

09 Dec '15

#11181: Program hands forever in sched_yield() / yield() unless -N is limited ---------------------------------------+---------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- We have a web application executable that, when run with -N24 (on our 24-core machine) hangs indefinitely, taking up 100% CPU. Introspecting with strace reveals that it's stuck in {{{yield}}} (on native SmartOS) and {{{shed_yield}}} (on both SmartOS LX and Linux emulation with KVM). If we run with +RTS -N2 -RTS, we do not observe this behavior. Attached is the output of truss(1) on an instance of a hung process. Other possibly-relevant information: this is an instance of the Warp web server and the Snap framework. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #609: Useful optimisation for set-cost-centre
by GHC 09 Dec '15

09 Dec '15

#609: Useful optimisation for set-cost-centre -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Is this ticket still valid? I just tried to reproduce this, but I don't think we're generating `scc` calls anymore. (maybe scc operation is done by the RTS now?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/609#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10527: Panic Simplifier ticks exhausted with type families
by GHC 09 Dec '15

09 Dec '15

#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've tried to compile my vinyl-like records with 7.10.2-rc1 and got: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op rreplace To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 225484 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attached self contained test compiles with 7.10.1, but fails with 7.10.2-rc1 when compiled with optimizations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #11169: Remove the word "skolem" from user error messages
by GHC 09 Dec '15

09 Dec '15

#11169: Remove the word "skolem" from user error messages -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Skolem variables are not, as best I can tell, part of the type system; they are part of the implementation of the type checking algorithm. As such, it seems inappropriate to mention them in error messages. Instead, the error messages should explain things at the Haskell level. {{{ Couldn't match expected type ‘t’ with actual type ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by... }}} I'd much rather see an explanation using words like "existentially quantified" and "right-hand side of a pattern match". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11169> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar.
by GHC 08 Dec '15

08 Dec '15

#11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Code: {{{#!hs module B where aaa x = aaa x bbb = aaa 1 }}} === In the renamed AST The reference is to the exported aaa (span 3:1-3, sort WiredIn), which is as expected (by me at least). (dump with ghc-dump-tree with some local mods compiled by GHC 7.10.2) {{{ (HsApp (L /tmp/B.hs:3:9-11 (HsVar here ------------> { n_loc = /tmp/B.hs:3:1-3 <----------- here , n_sort = { WiredIn = Module main B } , VarName = aaa })) (L /tmp/B.hs:3:13 (HsVar { n_loc = /tmp/B.hs:3:5 , n_sort = Internal , VarName = x }))))) }}} === In the typechecked AST Here the call target changes to internal (as described by the monomorphic binding abe_mono). {{{ (HsApp (L /tmp/B.hs:3:9-11 (HsVar { varType = { t -> t = FunTy (TyVarTy { varType = { * = TyConApp * [] } , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , TvName = t }) (TyVarTy { varType = { * = TyConApp * [] } , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , TvName = t }) } here -------------> , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , VarName = aaa })) (L /tmp/B.hs:3:13 (HsVar { varType = { t = TyVarTy { varType = { * = TyConApp * [] } , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , TvName = t } } , n_loc = /tmp/B.hs:3:5 , n_sort = Internal , VarName = x }))))) }}} (Just remarking, that GHC 7.8 and 7.10 seem to have improved the span ranges a bit over 7.6, so trying to reproduce with 7.6 the span will be the shorter one on the function name, but the sort will still be the internal). Note that referring the function in a non-recursive way seem to refer to the exported (abe_poly) binding. From the perspective of a tooling writer, this difference is somewhat surprising, and is a case to be handled separately. * Is there a fundamental reason why the reference changes after Typechecking? * Since I'm not deeply familiar with the AST, I might miss something. Does it happen in other cases too that sometimes abe_poly is referred, sometimes the abe_mono? If so, what is the rule? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11177: panic! tc_hs_type: record
by GHC 08 Dec '15

08 Dec '15

#11177: panic! tc_hs_type: record --------------------------------+--------------------------------- Reporter: apanagio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- when trying to compile a file where "deriving" was missing from a data type got the message: ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-linux): tc_hs_type: record Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug the source file is: {{{#!hs data Epafi = Epafi { } (Show) main :: IO () main = do print "hello" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3