November 2018 - ghc-tickets

[GHC] #15901: Assert and record that code generation requires distinct uiques for let-binders
by GHC 19 Nov '18

19 Nov '18

#15901: Assert and record that code generation requires distinct uiques for let- binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Simon writes in [https://ghc.haskell.org/trac/ghc/ticket/15754#comment:10 #15754]: Another invariant that the code generator needs is (I believe) that every let-binder has a distinct unique. We can't re-use the same unique, even in a different scope, let alone shadowing. Why? Because (I believe) that the code generator uses these uniques to generate unique top level labels for the entry code and info table for the closure. Now, it's probably the case that they are unique anyway; but we should either * Write this down as a invariant of STG, or * Establish this invariant in the immediately-before-codegen pass that gets the free vars right, or * Not assume it in the code generator -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15855: Warn about incomplete NamedFieldPuns patterns
by GHC 18 Nov '18

18 Nov '18

#15855: Warn about incomplete NamedFieldPuns patterns -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- In certain situations it's nice to be able to ensure that record pattern matches are exhaustive: {{{#!haskell data R = R {a, b :: Int} -- should warn f R{a} = a -- should not warn g R{a, b} = a + b -- should not warn h R{a, ..} = a + b -- should not warn i R{a, b = _} = a }}} It's useful when there are several functions that inspect a record (e.g. handlers that update a subset of fields in a database) and we want to make certain that when a new field is added to the record, the programmer won't forget to update functions working with that record (either by handling the field or explicitly discarding it). Currently the only non-hacky way to do it is writing `f (R a _) = ...`, which is obviously not ideal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15855> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15126: Opportunity to compress common info table representation.
by GHC 18 Nov '18

18 Nov '18

#15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've looked at a lot of GHC produced assembly recently and noticed that most info tables describing stacks have the form: {{{ .align 8 .long SDjR_srt-(block_cHmk_info)+296 .long 0 .quad 6151 .quad 4294967326 }}} I haven't managed to dig fully into the description however some observations: * I noticed that the second .long directive almost always ends up being zero. * When figuring out what is what I realized the first quad (describing the pointers) is almost never fully used. * The last entrie (closure type + ?), here `4294967326` also seems quite repetitive given the size reserved. So I looked in detail at spectral/simple: * There are 2012 info tables of this sort with all of them having a zero in the second long. * We also reserve 8 byte for the stack layout. However only a single of these tables requires more than 4 byte. The compiled module has a size of 276384 Bytes, with 16092 being redundant: * 4 bytes for 0 * 4 bytes unused stack description * times 2012 info tables. That is an overhead of 5,8% which seems like quite a lot to me. The questions where to put that information is a different one. But only looking at the data and not how it is used tagging the pointer to the SRT table seems like a possibility. The info table description `4294967326` also appeared over 1k times. Maybe it's possible to come up with a more efficient encoding there as well. I didn't give it much thought yet since I don't have the time to do anything about it in the near future. But putting it here in case anyone is interested or looks into this in the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9207: Detect obvious cases of infinite recursion.
by GHC 18 Nov '18

18 Nov '18

#9207: Detect obvious cases of infinite recursion. --------------------------------------+------------------------------------ Reporter: mrugiero | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: infinite recursion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: --------------------------------------+------------------------------------ Pure functions are guaranteed to return the same value if the same arguments are used. Because of that, a compiler could be able to detect infinite recursion in the form of a function calling itself with the same arguments (case, some distracted programmer forgot to apply the function tail to a list). The way I see it, one of Haskell's main selling points is that it helps the programmer to avoid sources of bugs as much as it can, and infinite recursion is one of the few that stand unchecked. I specifically point to this example because both, I'm a newbie and made that newbie mistake, and think it shouldn't be hard to implement to the parsing stage of the compiler/interpreter. It probably should throw an error when this happens in pure functions, and maybe an opt-in warning if it happens in monads. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15912: Output hadrian build data for cabal-helper tool support
by GHC 18 Nov '18

18 Nov '18

#15912: Output hadrian build data for cabal-helper tool support -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Keywords: cabal-helper | Operating System: Unknown/Multiple hadrian tool support | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As a step in the direction of adding tool support for ghc development we can output some meta data from Hadrian to better support the cabal-helper tool. Proposed changes: 1. Add a <ghc-root>/cabal.helper file that points to the 3 stage build directories under the default Hadrian build dir: _build. 2. Add a "--cabal-helper" command line option to Hadrian that enables this output. 3. Output <build-root>/stage<x>/build.helper in JSON format containing per package: * .cabal file path relative to <ghc-root> (achieved by prefixing paths with $PROJECTDIR) e.g $PROJECTDIR/libraries/binary/binary.cabal * source path e.g. $PROJECTDIR/libraries/binary/binary.cabal * Build "dist directory", which is the directory containing the setup- config file generated by cabal on build. this is a relative path e.g. libraries/binary/setup-config ## TODO * decide on the naming of files ## Implementation * See: * Packages.ghcPackages * Hadrian.Package.pkgCabalFile -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15891: Excessive system time during execution of GHC-built executables on macOS
by GHC 17 Nov '18

17 Nov '18

#15891: Excessive system time during execution of GHC-built executables on macOS ----------------------------------------+--------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- It seems that the executables built by GHC on my configuration of macOS are slow, clocking in 80% of my machine's cycles in system time. Here is what I know. - Everything tested bootstrapping with both GHC 8.6.1 and GHC 8.6.2. There is no observable difference between these bootstrapping compilers. The detailed data reported is all from GHC 8.6.1. - When I try to build GHC, stage 1 builds snappily. But once stage-1 gets used, it slows to a crawl. - Activity Monitor reports that my computer is spending roughly 80% of its time in the System space, not the User space. (While building ghc-stage1 itself, there is barely any system activity.) - I have sampled ghc-stage1 during a rts_dist_HC call. Samples are at https://gist.github.com/goldfirere/7316920ad37d776c25c15dbb0ed5996f - I then `dtruss`d the same, with output at https://gist.github.com/goldfirere/621ce9072e1204d30e96e7daecc80d02 - System information: * macOS High Sierra, 10.13.6 * Processor: 3.5 GHz Intel Core i5 * Memory: 16 GB 2400 MHz DDR4 * SSD main storage, formatted with APFS * happy 1.19.9 * alex 3.2.4 * XCode 10.1 * gcc is clang-1000.11.45.5, Apple LLVM version 10.0.0, thread model: posix Others (see [https://mail.haskell.org/pipermail/ghc- devs/2018-November/016507.html thread]) have not been able to repro, but this is very reliable for me. Any ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15891> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15910: GHC missreports import as redundant.
by GHC 17 Nov '18

17 Nov '18

#15910: GHC missreports import as redundant. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- In the following code GHC claims the first import is redundant. {{{ import Data.Map (Map) import qualified Data.Map as M type MT = Map }}} {{{ test.hs:5:1: warning: [-Wunused-imports] The qualified import of `Data.Map' is redundant except perhaps to import instances from `Data.Map' To import instances alone, use: import Data.Map() | 5 | import qualified Data.Map as M }}} Reproduceable on 8.4 and HEAD at least. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15910> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15887: It would be very nice to have a better GHCi editing experience
by GHC 17 Nov '18

17 Nov '18

#15887: It would be very nice to have a better GHCi editing experience -------------------------------------+------------------------------------- Reporter: Anchpop | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: Research needed Component: Compiler | Version: 8.6.2 Keywords: QoL | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a two annoyances when writing Haskell code in GHCi which I will enumerate here. While minor, I think if these were fixed there would be a marked improvement of the GHCi editing experience. 1) Syntax/Keyword Highlighting. Haskell has some very common keywords. Simply writing `if`, `then`, `else`, `where`, `do`, etc. in some color other than the default when not inside a string literal would be a huge improvement in my opinion, and might not be very difficult. 2) Multiline editing Writing multiline expressions in Haskell is somewhat difficult for four reasons. Firstly, to even start a multiline expression you must enter `:{` end end it with `:}`. Secondly, GHCi does not attempt to automatically indent your code, which is usually (always?) required when writing a multiline expression. Thirdly, you cannot navigate the curor to previous lines to edit them. Lastly, pressing the up arrow on the keyboard shows the last line of the multiline expression which is useless because it's almost always `:}`. My proposal is as follows. 1) The issue of how to enter multiline mode without needing to enter `:{` and exit it without needing `:}`. Instead of entering multiline mode only when the user enters `:{`, we add the following additional criteria. When I discuss haskell keywords in here, assume I mean "while not in a string literal". a) When the input code contains an odd number of unescaped quotation marks and ends in a backslash. b) When the input code ends with `where`, `let`, `in`, `if`, `then`, `else`, `do`, `of`, `case`, or `->` preceeded by and in the same level of parenthetical nesting of `case`. c) When the input code contains a `let` that is not eventually followed by `in`, an `if` not followed by `then`, or a `then` not followed by `else`. d) When the input code contains a `case` followed by `of`, not enclosed by parentheses. e) When the input code contains a `[` that is not followed by a `]`, or an `(` that is not followed by a `)`. f) When the input starts with two or more consecutive space- seperated tokens that do not contain haskell keywords (other than the backtick) followed by `=`. g) i) When the input contains a single token that is not a haskell keyword, followed by `::`, ending in `=>` or `->`. ii) When the input contains a single token that is not a haskell keyword, followed by `::`, not ending in `=>` or `->`. e) When the user hits `shift-return` instead of simply `return`, or hits `return` when there are non-whitespace characters after the cursor. This should cover the majority of cases where it can be safely assumed one would want to enter multiline mode. Criterion f is intended to enter multiline mode when defining any function, to make it simple to define functions that use pattern matching. Criterion g is to make it simple to place a function signature right above a function definition. In situations where multiline mode was not entered with `:{`, you should be able to exit it and submit your code to GHCi for execution by pressing `return` twice, or `meta-return`. 2) The issue of GHCi not attempting to indent your code. How to indent depends on the reason GHCi entered multiline mode. If GHCi entered multiline mode because the user entered `:{`, no indentation should take place. If the user is in multiline mode but their code does not match criteria a-f, the default indentation should be the same as the indentation on the previous line. If the line is just whitespace and the user presses enter, indentation should be the same as the previous line. For criteria a-f, here is how to respond (I've ordered these from greatest to least precedence I think they should take, but I could be entirely wrong here). a) Indent to the same column as the last unescaped quotation mark. For bonus points add a backslash too. b) Indent to two columns as the token that caused the activation of multiline mode. c) Indent to the same column as the token that caused the activation of multiline mode. d) Indent to the character after the final `of` not contained in parentheses e) Indent to the column of the next non-whitespace character after `(` or `[`, if one exists. Otherwise, indent one column farther than the `(`/`[`. f) No indentation. g) i) Indent to the column of the first non- whitespace character after the `::` ii) No indentation. e) No indentation If the user is not editing the last line, use the code up to the point of their cursor for advice on how to indent. 3) The issue of not being able to navigate the curor to previous lines in order to edit them when in multiline editing mode. I think this would require a complete rewrite of the user interface for multiline editing, and I anticipate it would be the hardest part of this whole endevor. I don't have the knowledge to suggest how one might go about implementing it, though. If possible, pressing ctrl-c should cancel the current code and make a new `Prelude> ` prompt. 4) The issue of pressing `up` only displaying one line at a time. See above. I would be happy to try to implement some of these, but I have never contributed to GHC or GHCi before and would need some pointers on where to start (Either in here or in the #ghc irc channel). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15887> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12906: GHC fails to typecheck Main module without main
by GHC 17 Nov '18

17 Nov '18

#12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given a `Main` module without a `main` value, GHC 8 reports the missing `main` and then exits, without bothering to typecheck the rest of the module. Previous versions, I believe, had the more useful behavior of reporting type errors regardless. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12525: Internal identifiers creeping into :show bindings
by GHC 17 Nov '18

17 Nov '18

#12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.1 Keywords: | 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: -------------------------------------+------------------------------------- When binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list. {{{#!html <pre class="wiki"> GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help > :show bindings > x = () > :show bindings <b>$trModule :: GHC.Types.Module = _</b> x :: () = _ > class Foo a > :show bindings x :: () = _ class Foo a <b>$tcFoo :: GHC.Types.TyCon = _ $tc'C:Foo :: GHC.Types.TyCon = _ $trModule :: GHC.Types.Module = _</b> </pre> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5