September 2015 - ghc-tickets

[GHC] #10625: Spurious unused quantified type variable warning with ExistentialQuantification
by GHC 07 Jan '16

07 Jan '16

#10625: Spurious unused quantified type variable warning with ExistentialQuantification -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: | warning at compile-time Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #5331 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When using an existentially quantified type variable that shadows another variable in a data declaration, {{{-Wall}}} produces more warnings than necessary: {{{ $ ghci -XExistentialQuantification -Wall GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help λ> data Ex a = forall a. Ex a <interactive>:2:20: Warning: Unused quantified type variable ‘a’ In the definition of data constructor ‘Ex’ <interactive>:2:20: Warning: This binding for ‘a’ shadows the existing binding bound at <interactive>:2:9 }}} The unused quantified type variable warning seems wrong, since it ''is'' being used (as the shadowing warning indicates). Curiously, this warning doesn't seem to appear when doing something similar with {{{RankNTypes}}}: {{{ $ ghci -XRankNTypes -Wall GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help λ> data Ex a = Ex (forall a. a) <interactive>:2:24: Warning: This binding for ‘a’ shadows the existing binding bound at <interactive>:2:9 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10625> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options
by GHC 05 Jan '16

05 Jan '16

#10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As discussed in this issue: https://github.com/commercialhaskell/stack/issues/680 stack is one example of a program that optimistically turned on "-N". Indeed, it feels like a reasonable and even safe option for a multithreaded program. Unfortunately, -N currently guarantees bad performance on large machines and especially on large machines with hyperthreading. Pretty much one should ship an executable with -N by default as of GHC 7.8 and 7.10 IMHO. Unfortunately, even if stack did get a speedup at, say, 4 or 8 cores, it would not be good to ship it with "-N8" either. This would be an unreasonable choice on small, one or two core machines. What we need is a way to say that the program can productively use parallelism up to a certain upper bound, but that fewer threads should be used if there are not enough cores available. I propose "-N<=8" as a potential syntax. Currently, this behavior can be achieved with `setNumCapabilities`/`getNumProcessors`, but I think it's worth a command line RTS option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10728> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122
by GHC 05 Jan '16

05 Jan '16

#8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This may be an artifact of issue #8128 (see https://ghc.haskell.org/trac/ghc/ticket/8128#comment:5) but I'm seeing examples involving data kinds where Typeable isn't deducible. This could be an artifact of other problems, BUT since with 7.7 onwards, we have baked in polykinded Typeable, things should always "just work™" right? the error with current head is as follows (and i'm attaching the code + current finger print too) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9968: DeriveAnyClass fails on multi-parameter type classes
by GHC 05 Jan '16

05 Jan '16

#9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 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: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DeriveAnyClass, MultiParamTypeClasses #-} module Bug where class C a b data X deriving (C Int) }}} and load that into GHCi, I see this: {{{ *Main> :load "/Users/rae/temp/DeriveAny.hs" [1 of 1] Compiling Bug ( /Users/rae/temp/DeriveAny.hs, interpreted ) Var/Type length mismatch: [b_a2YW] [] Var/Type length mismatch: [b_a2YW] [] Ok, modules loaded: Bug. *Bug> :info C class C a b -- Defined at /Users/rae/temp/DeriveAny.hs:5:1 instance C X -- Defined at /Users/rae/temp/DeriveAny.hs:7:13 }}} It seems my `Int` parameter to `C` is being dropped. I don't believe I have a debug build in this example, so that debugging output is shipping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10487: Unhelpful error from instance Generic
by GHC 05 Jan '16

05 Jan '16

#10487: Unhelpful error from instance Generic -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- That's the error you like too see, or rather not. ;( {{{ [180 of 289] Compiling Agda.TypeChecking.Serialise ( src/full/Agda/TypeChecking/Serialise.hs, dist-2.4.2.4/build/Agda/TypeChecking/Serialise.o ) src/full/Agda/TypeChecking/Serialise.hs:1:1: Duplicate instance declarations: instance GHC.Generics.Datatype Agda.TypeChecking.Serialise.D1Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 instance GHC.Generics.Datatype Agda.TypeChecking.Serialise.D1Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 src/full/Agda/TypeChecking/Serialise.hs:1:1: Duplicate instance declarations: instance GHC.Generics.Constructor Agda.TypeChecking.Serialise.C1_0Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 instance GHC.Generics.Constructor Agda.TypeChecking.Serialise.C1_0Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 }}} Problems: * no position in file * system generated names D1Name, C1_0Name * obvious bogus (same instance cannot be defined twice at same location) * leads me to suspect bug in Generics rather than in my code Reproduce: * git clone agda/agda from github, * checkout this commit https://github.com/agda/agda/commit/46823536559276807639488eae151a0e855fdb95 * and try to compile with {{{ make install-bin }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10487> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation
by GHC 05 Jan '16

05 Jan '16

#10716: Metadata in GHC.Generic should give access to strictness annotation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: feature | Status: new request | 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 Revisions: | -------------------------------------+------------------------------------- Currently, the metadata in the GHC.Generics module do not give access to the strictness annotations attached to a field of a datatype. It would be great if this piece of information could be added. Background: we are using a class FullyStrict for ensuring that a datatype is fully strict (in the sense that all fields have bang patterns and the types of all fields are also fully strict). Currently we are using TemplateHaskell to derive the instances automatically. The TemplateHaskell function also checks that all fields have bang patterns. To improve compilation speed, I would like to derive the instances with DeriveGeneric. But this is not possible because then I cannot implement the check whether all fields have bang patterns. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10579: full module names of names not in scope have gone missing in ghci
by GHC 05 Jan '16

05 Jan '16

#10579: full module names of names not in scope have gone missing in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compare {{{ rwbarton@morphism:/tmp$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :t GHC.Read.readPrec GHC.Read.readPrec :: Read a => Text.ParserCombinators.ReadPrec.ReadPrec a }}} with {{{ rwbarton@morphism:/tmp$ ~/ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20150624: http://www.haskell.org/ghc/ :? for help Prelude> :t GHC.Read.readPrec GHC.Read.readPrec :: Read a => ReadPrec a }}} The `Text.ParserCombinators.ReadPrec.` bit can be quite helpful, was it suppressed intentionally? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10643: GHC cannot import submodules when run from subfolder
by GHC 05 Jan '16

05 Jan '16

#10643: GHC cannot import submodules when run from subfolder -------------------------------------+------------------------------------- Reporter: FPtje | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: subfolder | Operating System: Unknown/Multiple import submodule cd | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm taking a huge risk in looking like an idiot, but it's worth trying to attack the elephant in the room. The first response I expect is ''"This is expected behaviour!"''. This is what intuition says, but I disagree. It's a simple problem and the fix should be easy, unless there's some advanced import mechanism that would conflict with the solution that I don't know about. That is exactly where I'm taking the risk in reporting this issue. The problem is simple: 1. Create a folder called "Yes". 2. Create Yes/A.hs with the following code: {{{#!hs module Yes.A where import Yes.B }}} 3. Create Yes/B.hs with the following code: {{{#!hs module Yes.B where }}} 4. Open a terminal in the folder that contains "Yes" and run: {{{ $ ghc Yes/A.hs }}} '''This works fine'''. Now try the following: {{{ $ cd Yes Yes/ $ ghc A.hs }}} You'll be greeted with the beautiful error: {{{ A.hs:3:8: Could not find module ‘Yes.B’ Use -v to see a list of the files searched for. }}} A screenshot is worth the above thousand words: http://i.imgur.com/8AxRa0K.png '''This is silly'''. Running with the -v option shows that ghc is not looking for Yes/B.hs, but Yes/Yes/B.hs. I can understand ''why'' it looks there, but not why ghc isn't just this ''tiny'' bit more intelligent in knowing where to look. After all, the module name tells ghc ''exactly'' in which subfolder it is located: {{{#!hs module Yes.A where -- This module is very likely to be in Yes/, because otherwise a name inconsistency error is thrown. }}} '''Proposed solution:''' The module name tells ghc exactly where it is located. If Yes.A imports Yes.B, then you know that they're in the same subfolder. Simple as that. Instead of ignoring that information and looking for Yes/Yes/B.hs, it should simply look for Yes/B.hs. Relative to ghc (which is run from Yes/) this would be ./B.hs. This solution is scalable. Imagine a module Ding.Dong.Biddly.Bong that imports Ding.Dong.Doodle.Bell. Running "ghc Bong.hs" from Ding/Dong/Biddly/ should '''not''' make it look for "Ding/Dong/Biddly/Ding/Dong/Doodle/Bell.hs", but for Ding/Dong/Doodle/Bell.hs. Relative to ghc (run from Ding/Dong/Biddly/), this would be ../Doodle/Bell.hs. So yeah, right now ghc is arbitrarily restricted to run from the root of the source directory. This '''looks''' like intended behaviour until you realise that the silly bug mentioned here is probably the only thing that prevents ghc from running from ''any'' subfolder. Of course there are the -i and :set options for ghc that allows one to work around this, but one should not be expected to jump through all the -iFile hoops to be allowed to run ghc from any arbitrary subdirectory of the source folder. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi
by GHC 04 Jan '16

04 Jan '16

#10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: GHCi | 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 Revisions: | -------------------------------------+------------------------------------- We missed the opportunity to merge this for GHC 7.10 but I hope this can make it for GHC 8.0 See https://github.com/chrisdone/ghci-ng/blob/master/README.md for a description of the new GHCi commands I've started rebasing the changes from Chris' ghci-ng repo against GHC HEAD and pushed the work-in-progress state as branch `wip/T10874`. One blocker right now is the use of SYB to traverse the AST which I don't want to drag into GHC as a dependency. So one thing that needs to be done is rewrite those 20 lines of code without relying on SYB. Other than that some minor polishing needs to be done. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10874> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10045: type holes related ghc panic
by GHC 04 Jan '16

04 Jan '16

#10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ sample.hs:9:13: Couldn't match expected type ‘t’ with actual type ‘()’ ‘t’ is untouchable inside the constraints () bound by the inferred type of foo :: Meta -> t1 at sample.hs:(6,1)-(9,17)ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.0 for x86_64-unknown-linux): No skolem info: t_avJ[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug sample.hs: module Blah where newtype Meta = Meta () foo (Meta ws1) = let copy :: _ copy w from = copy w 1 in copy ws1 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13