- ghc-devs - Haskell.org

RE: [GHC] #12067: warn-unused-imports does not detect coersions
by Simon Peyton Jones 25 Aug '16

25 Aug '16

ben is this a merge onto the 8.0 branch? On the ticket it just looks like a duplicate merge, which is jolly odd. This didn't use to happen... S | -----Original Message----- | From: GHC [mailto:ghc-devs@haskell.org] | Sent: 25 August 2016 16:04 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #12067: warn-unused-imports does not detect | coersions | | #12067: warn-unused-imports does not detect coersions | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: crockeea | Owner: | Type: bug | Status: merge | Priority: normal | Milestone: 8.0.2 | Component: Compiler | Version: 7.10.3 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: Incorrect | Test Case: | warning at compile-time | | typecheck/should_compile/T12067 | Blocked By: | Blocking: | Related Tickets: #10347 | Differential Rev(s): | Wiki Page: | | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Ben Gamari <ben@…>): | | In [changeset:"6c28f24aa8202f79db49b85b815011703d647fd9/ghc" | 6c28f24/ghc]: | {{{ | #!CommitTicketReference repository="ghc" | revision="6c28f24aa8202f79db49b85b815011703d647fd9" | Deal correctly with unused imports for 'coerce' | | We only do newtype unwrapping for Coercible constraints if the | newtype's data constructor is in scope. We were trying to record the | fact that the data constructor was thereby 'used', so that an import | statement would not be flagged as unnecsssary (by -Wunused-imports). | | But the code was simply wrong. It was wrong because it assumed that | only one level of unwrapping happened, whereas | tcTopNormaliseNewTypeTF_maybe actually unwraps multiple layers. | So we need to return a /list/ of data constructors that are used. | | This entailed a bit of refactoring, as usual. | | Fixes Trac #12067 | | (cherry picked from commit 23b80ac41cc945cea0fc6ff9ade6b4be8aa81b7f) | }}} | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.h | askell.org%2ftrac%2fghc%2fticket%2f12067%23comment%3a5&data=01%7c01%7c | simonpj%40microsoft.com%7c68b37c7d124e4b0a744d08d3ccf915f0%7c72f988bf8 | 6f141af91ab2d7cd011db47%7c1&sdata=vyQiwFoTB3ZXhI9%2fSxBlj8kE5cjEYw7gSR | 7jG575YvI%3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.h | askell.org%2fghc%2f&data=01%7c01%7csimonpj%40microsoft.com%7c68b37c7d1 | 24e4b0a744d08d3ccf915f0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2 | kFm1kxgSfvvlh%2f%2f3h53C4IPcBdY%2fo5k9wzmyXTO%2fjY%3d> | The Glasgow Haskell Compiler

2 2

Can we mark DataCon ptrs only in allocation sites and not generate entry code?
by Ömer Sinan Ağacan 25 Aug '16

25 Aug '16

As far as I can see in the native code compiler we mark DataCon pointers in two places: 1. In allocation sites (StgCmmCon.hs:240) 2. In DataCon entry code (StgCmm.hs:244) I was wondering why we can't get away with just doing (1). Can anyone give me an example where an allocation doesn't return a tagged pointer and we need to tag it in entry code? If every allocation returns a tagged pointer, then why do we need (2) ? Thanks

2 3

Re: Is there a stable URL for the latest GHC library haddocks?
by Ryan Scott 25 Aug '16

25 Aug '16

Hi Howard, I've never had much luck with the Haddocks hosted on haskell.org, for whatever reason. If you're willing to link to Hackage, how about hackage.haskell.org/package/base/docs/GHC-Exts.html ? That currently redirects to http://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-Exts.html, and will presumably continue to link to the most current Haddocks for GHC.Exts in the future. Best, Ryan S.

1 0

Is there a stable URL for the latest GHC library haddocks?
by Howard B. Golden 25 Aug '16

25 Aug '16

Hi, In https://wiki.haskell.org/Unboxed_type I noticed a broken link to the latest library Haddock for GHC-Exts: http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Exts.html This link doesn't work because the version of base is omitted, but that will change over time. It works (at the moment) as: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.9.0.0/GHC-Exts… Is there some stable URL that can be used in the wiki or other documentation to reference GHC library haddocks? Howard

1 0

Rewrapping with simple bidirectional pattern synonyms
by David Feuer 24 Aug '16

24 Aug '16

I'm trying to write a bidirectional pattern synonym which is morally simple, but as far as I can tell there's no way to write it as a simple bidirectional pattern synonym. What I want to say is pattern TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) (where TSnocList and Dual are both newtype constructors) But I don't see a way to do it without being explicitly bidirectional: pattern TSnoc xs x <- (tsViewR -> ViewR xs x) where TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) tsViewR :: TSnocList c x y -> ViewR c (TSnocList c) x y tsViewR (TSnocList CL.TNil) = EmptyR tsViewR (TSnocList (CL.TCons (Dual x) xs)) = ViewR (TSnocList xs) x Would it be possible to make this simple thing simple?

3 3

Errors when building users guide
by Harendra Kumar 23 Aug '16

23 Aug '16

I see errors like this when using 'make html' in the topdir of the ghc repo: ---- /vol/hosts/cueball/workspace/github/ghc/docs/users_guide/flags.rst:15: SEVERE: Problems with "include" directive path: InputError: [Errno 2] No such file or directory: 'docs/users_guide/flags-verbosity.gen.rst'. ---- What am I doing wrong or not doing? -harendra

2 5

Style or bug in user manual?
by Harendra Kumar 22 Aug '16

22 Aug '16

I was working to fix some documentation and noticed that the user manual lists options like this: -package⟨pkg⟩ Notice that there is no space between the argument and the option. Should this be fixed? All options on this page seem to be similarly formatted which makes me wonder whether its by design? -harendra

2 2

SSH failing on Windows
by Simon Peyton Jones 22 Aug '16

22 Aug '16

I'm continuing the saga of setting up my lovely Surface Book. Succeeding, just, but see below. Now my problem is that 'git push' doesn't work. My 'pushurl' is pushurl = ssh://git@git.haskell.org/ghc.git which is correct I think. I have a .ssh directory set up, with a copy of all the files that used to work. But 'git push' says /c/code/HEAD$ git push Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. So presumably it's a ssh problem. Turned out (via ssh -v) that I was getting debug1: Skipping ssh-dss key /c/users/simonpj/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes I solved this by adding to .ssh/config the line PubkeyAcceptedKeyTypes +ssh-dss But I guess this is bad practice. How would I (a) generate RSA keys (b) push them to git.haskell.org (or wherever they need to go) Is there a wiki page describing this? The (b) part at least is GHC specific, as is the strange pushurl. Thanks Simon

3 4

Re: Request for feedback: deriving strategies syntax
by Ryan Scott 22 Aug '16

22 Aug '16

Bardur, Since you don't like "bespoke", would you mind suggesting an alternative, or advocating for a previously mentioned idea? From [1], the ideas I've seen tossed around are: * builtin * standard (Elliot Cameron suggested it here [2]) * wiredin (Cater Schonwald suggested it here [3]) * magic (Andres Löh suggested it here [4]) * native * original * specialized (the above three are ad hoc suggestions I came up with in a hurry) Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategie… [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html

9 11

Moving ArgumentsDo forward
by Akio Takano 22 Aug '16

22 Aug '16

Hi, Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would love to see in GHC. It's a small syntactic extension that allows do, case, if and lambda blocks as function arguments, without parentheses. However, its differential revision [1] has been abandoned, citing a mixed response from the community. A message [2] on the ticket summarizes a thread in haskell-cafe on this topic. I, for one, think adding this extension is worthwhile, because a significant number of people support it. Also, given how some people seem to feel ambivalent about this change, I believe actually allowing people to try it makes it clearer whether it is a good idea. Thus I'm wondering: is there any chance that this gets merged? If so, I'm willing to work on whatever is remaining to get the change merged. Regards, Takano Akio [0]: https://ghc.haskell.org/trac/ghc/ticket/10843 [1]: https://phabricator.haskell.org/D1219 [2]: https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12

7 11