September 2017 - ghc-tickets

[GHC] #14277: Missing release version number in <title> in the HTML User's Guide
by GHC 26 Sep '17

26 Sep '17

#14277: Missing release version number in <title> in the HTML User's Guide -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See, for example, here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html The `<title>` of that page is `6.6. Flag reference — Glasgow Haskell Compiler <release> User's Guide`. It should be the actual version number (in this case, 8.2.1) instead of the `<release>` placeholder. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14277> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa)
by GHC 26 Sep '17

26 Sep '17

#12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose I write in a signature: {{{ data Type = TArrow t1 t2 | TApp String [Type] }}} But it turns out that the real data type only has TApp (and uses "->" as the TyCon for TArrow). It would be nice if a pattern synonym could be used to implement this "concrete abstract data type" instead. Signature matching would have to typecheck the pattern synonyms against each other, and also check for totality. Note that in this example, App would need a guard against the Arrow case; otherwise the patterns overlap, whereas in the data type above it shouldn't matter what order the patterns go in. The converse might be useful too: {{{ data Type pattern TArrow :: Type -> Type -> Type pattern TInt :: Type }}} These patterns would be available for matching, with the assumption that they weren't total. If they were implemented directly using constructors, that should not be a problem. (In fact, do we even support abstract pattern synonyms?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14162: Core Lint error
by GHC 26 Sep '17

26 Sep '17

#14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Options_GHC -dcore-lint #-} {-# Language TypeOperators, KindSignatures, DataKinds, PolyKinds, TypeFamilies, GADTs, TypeInType #-} import Data.Kind data family Sing (a :: k) data SubList :: [a] -> [a] -> Type where SubNil :: SubList '[] '[] Keep :: SubList xs ys -> SubList (x ': xs) (x ': ys) Drop :: SubList xs ys -> SubList xs (x ': ys) data instance Sing (x :: SubList ys xs) where SSubNil :: Sing SubNil SKeep :: Sing x -> Sing (Keep x) SDrop :: Sing x -> Sing (Drop x) }}} running it gives a massive core lint error, attached as a `lint.log`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14162> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14275: Large Haskell value unexpectedly gets an unfolding
by GHC 26 Sep '17

26 Sep '17

#14275: Large Haskell value unexpectedly gets an unfolding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- While working on #14272 I was surprised to find that modifying `PrelRules` resulted in a great deal of recompilation. Afterall, it has only three exports: * `primOpRules`: A function headed by a rather large case analysis totaling a few hundred lines of code * `builtinRules`: A large `[CoreRule]` (consisting of a literal list with six entries concatenated with the much-larger `builtInIntegerRules`) * `caseRules`: A function of moderate size Intuitively, none of these things seemed particularly beneficial to inline. This is why I was slightly surprised to find that `builtinRules` (and all of its floated entries) had an unfolding, {{{ builtinRules :: [CoreRule] {- Strictness: m2, Unfolding: (: @ CoreRule builtinRules255 builtinRules1) -} }}} Of course, determining whether unfoldings are helpful is in general quite difficult. However, I can't help but wonder whether our heuristic isn't quite right. Afterall, the Haskell for `builtinRules` is quite large and consequently most users would be surprised to see GHC try to inline it. The only reason it looks so small is that GHC broke up the structure via float-out. I don't have any concrete ideas for addressing this at the moment but felt like I should write down the concern so it isn't lost. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14144: Standardize binary distribution doc files
by GHC 26 Sep '17

26 Sep '17

#14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- I'm making a pass at the documentation in general, and next up on my list is simplifying the building process a bit. I hope to create something like `docs/dist-install` that would collect and hold all of the generated documentation. This would help in writing the docs, as you could verify links, say, from the user's guide to the library documentation. This would also allow installation and distribution to mainly be a `cp`. While looking into this, I ran into some discrepancies between releases. The contents of !https://downloads.haskell.org/~ghc/VERSION/docs for [https://downloads.haskell.org/~ghc/7.10-latest/docs 7.10], [https://downloads.haskell.org/~ghc/8.0-latest/docs 8.0], and [https://downloads.haskell.org/~ghc/latest/docs 8.2] are all different. 8.0 dropped `*.ps` files and `haddock.pdf`. 8.2 now additionally holds a `windows` folder that has a wide array of binaries and documentation. Going back further, the `Cabal` user's guide used to be included. I searched around for a reason that it was dropped and only found a git commit citing the change from `docbook`. But now most sources use `Sphinx`, so we could generate and include them if we so wished. The `Cabal` guide can be found at: * https://www.haskell.org/cabal/users-guide/ (Version 1.24.2) * https://cabal.readthedocs.io/en/latest/ (Versions 2.0 and HEAD) The `Haddock` guide can be found at: * https://www.haskell.org/haddock/doc/html (Version 2.15.0) * https://haskell-haddock.readthedocs.io/en/latest/ (Versions 2.18.0 and HEAD) * https://downloads.haskell.org/~ghc/latest/docs/haddock.html.tar.xz (GHC release version) Unfortunately, the www.haskell.org links are the most prominent when Googled. To bring this back to a point, I would like to clean up the `docs` folder of the distribution. The `windows` folder inside seems like it might be a mistake. Additionally, `Cabal` and `Haddock` have ended up in strange positions, and I think they probably could both use the same solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14265: kinded holes
by GHC 26 Sep '17

26 Sep '17

#14265: kinded holes -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature | Status: new request | Priority: normal | 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: -------------------------------------+------------------------------------- For value-level holes, ghc kindly mentions the expected type. It does not do the same for holes in type signatures: mentioning the expected kind. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14153: Change worker thread name to something mentioning original process name
by GHC 25 Sep '17

25 Sep '17

#14153: Change worker thread name to something mentioning original process name ----------------------------------------+--------------------------------- Reporter: enolan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Worker OS thread are renamed to `ghc_worker` when spawned. This is annoying when reading debugging messages that print the process name. For example, at work I'm debugging a segfault in a Haskell program and the kernel message just says `ghc_worker[21992]: segfault at 0 ip...` which doesn't tell me which of our Haskell programs is having the problem. I'd like to change this so it mentions the original name. On Linux, we can get that from the `program_invocation_name` global. `pthread_setname_np` has a maximum length of 15 characters, so we'll have to truncate it. I propose the first 13 characters of the original name followed by ":w". I'd just as soon not change the name in the first place but apparently this change was made to make it easier to distinguish worker threads from the main thread when debugging processes in gdb (commit 674c631ea111233daa929ef63500d75ba0db8858). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14276: T13168 is broken on Windows
by GHC 25 Sep '17

25 Sep '17

#14276: T13168 is broken on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Due to the lack of shared library support. {{{ Actual stderr output differs from expected: diff -uw "./typecheck/T13168/T13168.run/T13168.stderr.normalised" "./typecheck/T13168/T13168.run/T13168.run.stderr.normalised" --- ./typecheck/T13168/T13168.run/T13168.stderr.normalised 2017-09-26 00:20:55.835321400 -0400 +++ ./typecheck/T13168/T13168.run/T13168.run.stderr.normalised 2017-09-26 00:20:55.836298600 -0400 @@ -1,4 +0,0 @@ -Warning: -rtsopts and -with-rtsopts have no effect with -shared. - Call hs_init_ghc() from your main() function to set these options. -Warning: -rtsopts and -with-rtsopts have no effect with -shared. - Call hs_init_ghc() from your main() function to set these options. *** unexpected failure for T13168(normal) }}} Really this output is spurious anyways and in principle shouldn't affect the test passage. That being said, I don't see an easy way to filter it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #420: O'Haskell
by GHC 25 Sep '17

25 Sep '17

#420: O'Haskell -------------------------------------+--------------------------------- Reporter: mlbm | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: None | Version: None Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A -------------------------------------+--------------------------------- Comment (by Tamar Christina <tamar@…>): In [changeset:"abca29f3f3e19c4af452c1714be1bf33f4ac9180/ghc" abca29f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="abca29f3f3e19c4af452c1714be1bf33f4ac9180" Adds mingw64 to the valid GHC OSs. Summary: This fixes hadrian#420 (https://github.com/snowleopard/hadrian/issues/420) specifically the "Unknown OS mingw64". Reviewers: austin, hvr, bgamari, Phyx Reviewed By: Phyx Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4016 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/420#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14274: Host normalization causes problem with configure.
by GHC 25 Sep '17

25 Sep '17

#14274: Host normalization causes problem with configure. ----------------------------------------+---------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- The host normalization we do causes problems with configure, because we change the triple autoconf seems to think we're always cross compiling on Windows. So `AC_CHECK_TARGET_TOOL` always fails and ends up looking for `-<toolname>`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1