- ghc-tickets - Haskell.org

[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

[GHC] #14307: Nonexistent constructor name + NamedFieldPuns + DuplicateRecordFields can cause ambiguous occurrence message
by GHC 11 Oct '17

11 Oct '17

#14307: Nonexistent constructor name + NamedFieldPuns + DuplicateRecordFields can cause ambiguous occurrence message -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: 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: -------------------------------------+------------------------------------- This is a minor issue with error message clarity. I was confused for a few minutes because in a more complicated example I did not see the out of scope error, and was instead focused on the ambiguity error. {{{ {-# LANGUAGE DuplicateRecordFields #-} {-# LANGUAGE NamedFieldPuns #-} data A = A { field :: Int } data B = B { field :: Int } f :: A -> Int f C { field } = field }}} yields {{{ duplicate_records_bug.hs:8:3: error: Not in scope: data constructor ‘C’ | 8 | f C { field } = field | ^ duplicate_records_bug.hs:8:7: error: Ambiguous occurrence ‘field’ It could refer to either the field ‘field’, defined at duplicate_records_bug.hs:5:14 or the field ‘field’, defined at duplicate_records_bug.hs:4:14 | 8 | f C { field } = field | ^^^^^ }}} I actually think it would make sense to allow ambiguous identifiers in field puns even if DuplicateRecordFields is not enabled. This makes sense, because for an unambiguous constructor, a particular field name is always unambiguous. So, that might be another way to frame this issue: Should ambiguous field identifiers always be allowed in puns? In particular, this would make things more consistent with RecordWildCards, which does not care if the field names shadow anything that is in scope / other field names. I realize that broadening the code allowed by NamedFieldPuns could lead to issues where code written for newer GHC versions does not work with older GHC versions. This certainly will not change the meaning of older code. What's the policy on this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14337: typeRepKind can perform substantial amounts of allocation
by GHC 11 Oct '17

11 Oct '17

#14337: typeRepKind can perform substantial amounts of allocation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.2.1 Libraries | Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I came up with a (rather contrived) test case to demonstrate that Phab:D4082 reduced big-O time complexity in pathological cases. But I expected it to increase space usage by a constant factor. What I found was very much the opposite: it dramatically reduced allocation. The reason for this is obvious in hindsight. Every time we call `typeRepKind`, we recalculate the kind entirely from scratch. That recalculation is only a potential ''time'' problem for `TrApp`, because we only need to walk down links, but it's also a ''space'' problem for `TrTyCon`, because we're building up a `TypeRep` from a `KindRep`. The solution, assuming we choose to keep `typeRepKind`, seems fairly clear: whether or not we choose to cache the kind in `TrApp`, we should almost certainly do so in `TrTyCon`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

10 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 nakaji_dayo): Replying to [comment:22 mgsloan]: I agree. I think "-Wpartial-fields" is good name. I have submitted code review about `-Wpartial-fields`.\\ On the other hand, I don't have any commit about `-Wpartial-field-usages`. > I think it also makes sense to have an option to emit warnings for partial record fields. Perhaps call it -Wpartial-field-usages? The reason this is helpful is that some libraries may export partial fields. It's still helpful as a sanity check for users of a library to have this as an optional warning. I think that this is helpful in this case too. But as far as I know, GHC doesn't have warnings for usage of partial function.\\ In case of implement this, it seems that design considering the whole is necessary.\\ Is my understanding correct? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14334: Large static object : getLabelBc: Ran out of labels
by GHC 10 Oct '17

10 Oct '17

#14334: Large static object : getLabelBc: Ran out of labels -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- stack ghci The following GHC options are incompatible with GHCi and have not been passed to it: -threaded Configuring GHCi with the following packages: gcc-haskell Using main module: 1. Package `gcc-haskell' component exe:gcc-haskell-exe with main-is file: /home/mdupont/experiments/g\ cc-haskell/gcc-haskell/app/Main.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 3] Compiling LibData ( LibData.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): getLabelBc: Ran out of labels Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Compiling this project file here that is basically a large data object emitted from the rdf4h lib. I wanted to put the data into static space to improve load times and remove IO. https://github.com/h4ck3rm1k3/gcc-haskell/blob/master/src/LibData.hs -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14334> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10