October 2013 - ghc-tickets

[GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining
by GHC 04 Aug '16

04 Aug '16

#8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining ------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I just remembered an old idea I put to the GHC user's list [http://www .mail-archive.com/glasgow-haskell-users(a)haskell.org/msg22119.html here], and thought I should present it here. As I understand it GHC inlines inlines only after a function is fully applied with respect to the syntactic left-hand side, so in order to control inlining and sharing, we sometimes see strange things like: {{{ {-# INLINE foo #-} foo :: a -> b -> c foo a = \b -> ... }}} It would be nice to be able to define the function syntactically in the way that's the most clear (e.g. in pointfree style, etc.) and specify at what point to inline something like this: {{{ foo :: a -> {-# INLINE #-} b -> c foo a b = ... -- or: foo = ... }}} ...which tells the compiler to inline after applying the arguments to the left of the pragma, and GHC would do whatever trivial (I assume?) eta- conversion was required. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8473: Generate table of cost-centre numbers with source locations
by GHC 01 Aug '16

01 Aug '16

#8473: Generate table of cost-centre numbers with source locations ------------------------------------+------------------------------------- Reporter: lars_e_krueger | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7105 | ------------------------------------+------------------------------------- .prof files contain a cost centre number, which I assume is cc_key from CostCentre.lhs. It would be immensely helpful if the compiler creates a simpe table. This way, one could look up the number in .prof, check the table and the exact source location. It would also help with #7105, I think. Suggestion for the format: {{{ no. file begin end 1 main.hs 127:7 128:14 }}} Meaning: Cost centre 1 is in file main.hs, begins at line 127, character 7 and ends at line 128, character 14. If somebody points me in the right direction, and the whole thing is not too complicated, I can try my hand at implementing it myself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8308: Resurrect ticky code for counting constructor arity
by GHC 12 Jul '16

12 Jul '16

#8308: Resurrect ticky code for counting constructor arity ----------------------------------------------+---------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: ----------------------------------------------+---------------------------- There is a dead piece of ticky profiling code that computes histograms of data constructor arities (including tuples) and size of vector returns. The function responsible is `bumpHistogram` in [[GhcFile(compiler/codeGen/StgCmmTicky.hs)]], which masks the commented out function `bumpHistogramE`. We can improve ticky profiling by resurrecting this dead code. There are following things that need to be done: 1. Replace current no-op `bumpHistogram` with `bumpHistogramE`. Note that current implementation of `bumpHistogramE` computes constructor arity at runtime. This is unnecessary because we know arity at compile time so we can avoid runtime check by doing sth like this: {{{ bumpHistogram lbl n = do let offset = n `min` 8 emit (addToMem cLong (cmmIndexExpr cLongWidth (CmmLit (CmmLabel (mkRtsDataLabel lbl))) (CmmReg (CmmInt (fromIntegral offset) cLongWidth))) 1) }}} Note that `mkRtsDataLabel` function does not exist anymore but we should be able to replace that call with `mkCmmDataLabel rtsPackageId lbl` (speculation). 2. We need to declare arrays that will store histogram values. Declarations of variables used for storing ticky statistics are in [[GhcFile(includes/stg/Ticky.h)]]. We also need to initialize the declared array to contain only zeros. 3. Having declared the arrays we need to fix printing of computed arities. This is done in [[GhcFile(rts/Ticky.c)]]. Note that there is a lot of code that is commented out (`/* krc: comment out some of this stuff temporarily */`) or disabled with `#if FALSE` pragma. We need to resurect *some* of it. There is a `PR_HST` macro for printing one histogram entry. This seems bad. We should probably rework the part of code responsible for printing out results of historgams. 4. Current code counts arities from 0 to 8. Everything above 8 is put into the same bin as 8. This magical 8 is spread all over the code. We should declare a constant that is visible both in Haskell sources (see `bumpHistogram` in 1.) and RTS files and have all code behave properly depending on that constant - we should have loops instead of statically printing 9 elements of histogram array. 5. Some ticky functions that count arity histograms are not used. For example `tickyReturnNewCon` should probably be called by `cgConApp` like this: {{{ ; emit =<< fcode_init ; tickyReturnNewCon ; emitReturn [idInfoToAmode idinfo] } }}} The above is a an outline, which should be fairly accurate, but unexpected things may show up along the way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8207: Show instance for Language in DynFlags
by GHC 17 May '16

17 May '16

#8207: Show instance for Language in DynFlags ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHC API | 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: | ------------------------------------+------------------------------------- I feel that the GHC API could benefit from a Show instance for Language in DynFlags.hs. Currently, if we want to display the language being used we have to do something like {{{ foo inf = case hmi_language inf of Nothing -> Nothing Just Haskell98 -> Just "Haskell98" Just Haskell2010 -> Just "Haskell2010" }}} This is pretty much just the Show instance (over Maybe) and Haskell can derive it for us automatically: we just need to change `deriving Enum` to `deriving (Enum, Show)`. The above solution is not the most robust ever as if this data type is ever changed, this starts to form an incomplete pattern. If we have a catch all `_`, GHC complains about overlapping patterns. Easily solved with `show <$> hmi_language inf`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8468: ghc panic in deriving Generic1 on Array#
by GHC 07 Apr '16

07 Apr '16

#8468: ghc panic in deriving Generic1 on Array# -----------------------------------+--------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Compiling the following code {{{ {-# Language DeriveGeneric, MagicHash #-} module Test where import GHC.Generics import GHC.Prim data Array a = Array (Array# a) newtype Vec a = MkVec {unVec :: Array a} deriving Generic1 }}} causes panic: {{{ [1 of 1] Compiling Test ( Test.hs, Test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): No match in record selector tyConTyVars Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} some comments from IRC: <monoidal> with deriving Generic1 we get "Can't make a derived instance of `Generic1 Array': Array must not have unlifted or polymorphic arguments" - so it seems the check is not done recursively on used types <monoidal> * deriving Generic1 on Array -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8416: GHC.Generics needs more documentation
by GHC 07 Apr '16

07 Apr '16

#8416: GHC.Generics needs more documentation -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Recently I tried to used `GHC.Generics` "in anger" for the first time, to fix some code in hashable that wasn't originally written by me. After a while I just gave up (and the generics support in hashable is now somewhat broken). The documentation for `GHC.Generics` is too incomprehensible for mere mortals. In particular, I find the documentation for `M1` and `K1` not very helpful. The documentation needs examples, more in-depth explanations of what each of the data types/constructors is used for, and finally an explanation of the up to 4 type parameters! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8132: Warning for Typeable instances misplaced
by GHC 17 Mar '16

17 Mar '16

#8132: Warning for Typeable instances misplaced -------------------------+------------------------------------------------- Reporter: | Owner: scottgw | Status: new Type: bug | Milestone: Priority: | Version: 7.7 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- There is currently a warning for hand-rolled instances of Typeable. However, this leads to some pretty surprising error messages: because the instance is ignored any code that relies on that instance in the same module just fails, which appears pretty weird to the user. {{{ #!haskell import Data.Typeable data K = K instance Typeable K where typeRep _ = undefined ex :: TypeRep ex = typeRep (undefined :: Proxy K) }}} Gives as an error: {{{ No instance for (Typeable * K) arising from a use of ‛typeRep’ In the expression: typeRep (undefined :: Proxy K) In an equation for ‛ex’: ex = typeRep (undefined :: Proxy K) }}} Which is of course surprising because the user just defined the instance. After commenting out the code that uses the instance, one gets: {{{ TypEx.hs:1:1: Warning: Typeable instances can only be derived; ignoring the following instance: instance Typeable * K -- Defined at TypEx.hs:5:10 }}} This information should clearly be somehow presented before or with the previous error if the user is to have any way to figure out what is going on. I suppose this could be fixed by: 1. Turning the Typeable instance warning into an error 2. Checking the missing instance in the existing error for Typeable and suggest that the user should look for hand written instances as a source of the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8176: Language extensions not registered
by GHC 20 Feb '16

20 Feb '16

#8176: Language extensions not registered --------------------------------+------------------------------------------ Reporter: duncan | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: tests/driver/T4437.hs Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ tests/driver/T4437.hs does not seem to be being used properly. That test is there to make sure that ghc developers do not forget to register their new extensions with Cabal. But it looks like it's just being silenced and they are being forgotten again. Recall, the protocol is that all Haskell implementations can register their extensions in the central location (which is Language.Haskell.Extensions in the Cabal package) when they are happy that they are ready for public consumption. This matters to users because extensions that are not ready for public consumption (ie not registered) cannot be used in packages uploaded to hackage. Currently `tests/driver/T4437.hs` contains: {{{ expectedGhcOnlyExtensions = [ "AllowAmbiguousTypes", "RelaxedLayout", "AlternativeLayoutRule", "AlternativeLayoutRuleTransitional", "ExplicitNamespaces", "TypeHoles", "OverloadedLists", "EmptyCase", "AutoDeriveTypeable", "NegativeLiterals", "NullaryTypeClasses"] }}} This looks like a much bigger list than it should be. Surely not all of these extensions are private to ghc or are still under development and not to be used? But if they are listed here, then the test doesn't complain about them. And the whole point of this test is to stop ghc devs from forgetting to register them. I think we need to change the test so that we distinguish between extensions that are really not ready, and ones that are on-track to be public. It should be a release blocker for the "on-track to be public" ones to still not be registered. The test should have comments giving this guidance for ghc contributors. I'm not quite sure how we adjust the test to make that happen (ie different behaviour for RC-build vs normal hacking validate). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8278: Improve error message when the same type is imported from two different library versions
by GHC 15 Feb '16

15 Feb '16

#8278: Improve error message when the same type is imported from two different library versions ------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When a package indirectly depends on different versions of the same library, ghc reports cryptic error: {{{ Couldn't match expected type `ByteString' with actual type `bytestring-0.9.2.1:Data.ByteString.Internal.ByteString' }}} Error contains fully qualified type with package name and version only when the type is imported from different versions on the library, so looks like ghc knows what is wrong. Is it possible to add something like the next: {{{ Note: ByteString is imported from different package versions: bytestring-0.9.2.1 and bytestring-0.10.0.1 }}} It is inspired by a number of StackOverflow questions (e.g. http://stackoverflow.com/questions/12576817/couldnt-match-expected-type- with-actual-type-error-when-using-codec-bmp/12577025#12577025, http://stackoverflow.com/questions/18767086/bytestring-to-lazy-text-and- vice-versa/18769431?noredirect=1#comment27676563_18769431) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8136: arr020 test fails randomly with ghci way
by GHC 08 Feb '16

08 Feb '16

#8136: arr020 test fails randomly with ghci way -----------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------- I noticed that when I run arr020 (`make TEST=arr020`) it randomly segfaults when running `ghci` way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4