October 2017 - ghc-tickets

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 12 Oct '17

12 Oct '17

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: nakaji_dayo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4083 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > In case of implement this, it seems that design considering the whole is necessary. It's not clear; determining partiality is in general quite tricky whereas partial selectors is a class of partiality that we can easily identify. Consequently it may make sense to handle it separately. I also don't have a strong opinion on this, however. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14236: Typeable App pattern doesn't match function types
by GHC 12 Oct '17

12 Oct '17

#14236: Typeable App pattern doesn't match function types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- Consider the type representation, {{{#!hs rep = typeRep @(Int -> Char) }}} We would expect this to match the pattern, {{{#!hs (App (App arrowRep intRep) charRep) }}} However, this is currently not the case. Fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14344: `ghc: panic!` when loading module
by GHC 12 Oct '17

12 Oct '17

#14344: `ghc: panic!` when loading module -------------------------------------+------------------------------------- Reporter: javi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm learning Haskell from an online book (haskellbook.com) and when I loaded an answers module, this happened: {{{#!hs Prelude> :l ex.hs [1 of 1] Compiling Ex ( ex.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): repSplitAppTys a_a1qJ[sk:1] Bool [] 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/types/Type.hs:808:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} notice that the Prelude module got unloaded. The source code for my `ex.hs` module: {{{#!hs module Ex where import Data.Char myAny :: (a -> Bool) [a] -> Bool myAny pred [] = False myAny pred (x:xs) = pred x || myAny pred xs }}} You'll notice that I missed a `->` in `myAny`'s type signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14344> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14043: GHC.Stack.callStack throws exception
by GHC 11 Oct '17

11 Oct '17

#14043: GHC.Stack.callStack throws exception -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- This program, {{{#!hs import GHC.Stack main :: IO () main = putStrLn (prettyCallStack $ id (\_ -> callStack) ()) }}} terminates with, {{{ Hi: popCallStack: empty stack }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13678: Overhaul the linker
by GHC 11 Oct '17

11 Oct '17

#13678: Overhaul the linker -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 8.3 (Linking) | 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: -------------------------------------+------------------------------------- The linker has gained support for aarch64/macho, and aarch64/elf, as well as improved arm/elf code, this code introduces separate mapping of sections into different pages, to allow for `W^X` protection. This is essentially a requirement on iOS, and I believe a sane default to have. To this extend the symbol extras logic needed to be split up into GOT and PLTs, where the PLTs are allocated alongside the sections, as the architecture may not allow arbitrary jumps (arm/aarch64). The introduction aarch64/elf has also been done through a pseudo interface so that the actual relocation logic can be contained within it's own files. Ideally we'd improve the linker by migrating the existing (heavily #ifdef'd) to the new separate section mapping (`W^X`) and pseudo interface approach. The separate section mapping logic has an inherent memory inefficiency (which might be improved a bit by aggregating similar sections into the same page), and might also cause a performance penalty due to separate mapping instead of a single file mmap. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11654: User Guide: Generate command line options table from ghc-flags directives
by GHC 11 Oct '17

11 Oct '17

#11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.10.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: -------------------------------------+------------------------------------- Since the move to ReStructuredText and Sphinx we've generated the options summary tables and manpage with `utils/mkUserGuidePart`. The options are described in a set of Haskell modules which are a pain to edit and may easily fall out of date. It would be far better if we could generate these tables from the `.. ghc- flags` directives already present in the users guide. This will involve a bit of hacking with Sphinx, although it should be more than up to the task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #14003: Allow more worker arguments in SpecConstr
by GHC 11 Oct '17

11 Oct '17

#14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Keywords: JoinPoints, | Operating System: Unknown/Multiple Fusion | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Starting with GHC 8.2 (rc1 -- head) I noticed that the SpecConstr pass does not always optimize completely with SpecConstr-heavy code. Setting ```-fmax-worker-args=100``` leads to complete specialization again. However, given that code annotated with ```SPEC``` should be optimized until no more ```SPEC``` arguments are alive, shouldn't ```callToNewPats``` in ```compiler/specialise/SpecConstr.hs``` specialize *irrespective* of the size of the worker argument list? Code that actually fails to specialize is fairly large, hence no test case -- though I have some files with core output showing insufficient specialization. (I'd be willing to write a patch for this) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14289: Pretty-printing of derived multi-parameter classes omits necessary parentheses
by GHC 11 Oct '17

11 Oct '17

#14289: Pretty-printing of derived multi-parameter classes omits necessary parentheses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Parser) | 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: -------------------------------------+------------------------------------- Take this file: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS -ddump-splices #-} import Language.Haskell.TH class C a b main :: IO () main = putStrLn $([d| data Foo a = Foo a deriving (C a) |] >>= stringE . show) }}} When this is compiled, `-ddump-splices` does not faithfully print back what was written by the user: {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:10:19-77: Splicing expression [d| data Foo_a4l1 a_a4l3 = Foo_a4l2 a_a4l3 deriving C a_a4l3 |] >>= stringE . show ======> "[DataD [] Foo_6989586621679026555 [PlainTV a_6989586621679026557] Nothing [NormalC Foo_6989586621679026556 [(Bang NoSourceUnpackedness NoSourceStrictness,VarT a_6989586621679026557)]] [DerivClause Nothing [AppT (ConT Main.C) (VarT a_6989586621679026557)]]]" }}} In particular, this pretty-prints `deriving C a_a4l3`, which doesn't even parse correctly. It should print `deriving (C a_a4l3)`. Ultimately, there is an off-by-one error in the number of parentheses being printed, since if you tweak the original example by adding another set of parentheses: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS -ddump-splices #-} import Language.Haskell.TH class C a b main :: IO () main = putStrLn $([d| data Foo a = Foo a deriving ((C a)) |] >>= stringE . show) }}} Then it pretty-prints exactly one set of parentheses (as opposed to two): {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:10:19-79: Splicing expression [d| data Foo_a1zI a_a1zK = Foo_a1zJ a_a1zK deriving (C a_a1zK) |] >>= stringE . show ======> "[DataD [] Foo_6989586621679026522 [PlainTV a_6989586621679026524] Nothing [NormalC Foo_6989586621679026523 [(Bang NoSourceUnpackedness NoSourceStrictness,VarT a_6989586621679026524)]] [DerivClause Nothing [AppT (ConT Main.C) (VarT a_6989586621679026524)]]]" }}} There are two suspicious parts of the GHC codebase that contribute to this bug: * This parser production: http://git.haskell.org/ghc.git/blob/4364f1e7543b6803cfaef321105d253e0bdf08a… This recognizes singleton derived classes that are surrounded by a set of parentheses, and "strips off" the parentheses. * This `Outputable` instance: http://git.haskell.org/ghc.git/blob/4364f1e7543b6803cfaef321105d253e0bdf08a… This code detects lists of two or more derived classes and surrounds them with extra parentheses to make up for the set that was removed during parsing. But this fails to detect the case of `deriving (C a)`, since this only contains a single class. Indeed, trying to distinguish between, say, `deriving T` and `deriving (T)` at this level would be quite tricky. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14289> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14340: Rename AND typecheck types before values
by GHC 11 Oct '17

11 Oct '17

#14340: Rename AND typecheck types before values -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In a few cases, we get in trouble during renaming of values because we don't have access to information that would be computed during typechecking. Two examples of this: * https://ghc.haskell.org/trac/ghc/ticket/13905 - Here, we need to determine if a Name is a newtype constructor or data type constructor during renaming (desugaring of applicative do), which is not known until after typechecking * https://ghc.haskell.org/trac/ghc/ticket/12088 - Perhaps? We want to rename and typecheck instance declarations at the same time, since they can occur between the type declarations. One nit: you can't compute SCCs until you rename. But if you just rename ALL of the types at once, then SCC them, that should be fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10816: Fixity declaration for associated type rejected
by GHC 11 Oct '17

11 Oct '17

#10816: Fixity declaration for associated type rejected -------------------------------------+------------------------------------- Reporter: goldfire | 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 Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeOperators, TypeFamilies #-} module Bug where class C a where type a # b infix 4 # }}} I get {{{ Bug.hs:7:11: ‘#’ is not a (visible) method of class ‘C’ }}} But it really should just assign a fixity to the type `#`. It works if the fixity declaration is outside of the class. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3