August 2016 - ghc-devs

hsc2hs fix
by Richard Cook 31 Aug '16

31 Aug '16

Ben et al, I'm responding to your last call for merge requests ( https://mail.haskell.org/pipermail/ghc-devs/2016-August/012693.html) I would really like to get this fix to hsc2hs in if it all possible: https://phabricator.haskell.org/D2478 Thanks, Richard.

2 1

RE: [commit: ghc] master: Remove unused DerivInst constructor for DerivStuff (f4384ef)
by Simon Peyton Jones 30 Aug '16

30 Aug '16

Ryan I just wanted to thank you for all the work you are doing on 'deriving' and generics. It's a very useful part of GHC, but it's sufficiently complicated that it's hard to dive in and make a quick fix. You are giving it sustained attention, and have become very familiar with the code, which is exactly what it needs. Thank you! It's extremely valuable work. I am conscious that I owe you a code review on D2280, but this week is bad and next week is worse. If I don't get to it, let's sit down at ICFP. I should not be standing in the way. Has anyone else given it a good review? Simon -----Original Message----- From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of git(a)git.haskell.org Sent: 29 August 2016 20:29 To: ghc-commits(a)haskell.org Subject: [commit: ghc] master: Remove unused DerivInst constructor for DerivStuff (f4384ef) Repository : ssh://git@git.haskell.org/ghc On branch : master Link : https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell… >--------------------------------------------------------------- commit f4384ef5b42bb64b55d6c930ed9850a021796f36 Author: Ryan Scott <ryan.gl.scott(a)gmail.com> Date: Mon Aug 29 15:26:53 2016 -0400 Remove unused DerivInst constructor for DerivStuff Summary: Back when derived `Generic` instances used to generate auxiliary datatypes, they would also generate instances for those datatypes. Nowadays, GHC generics uses a `DataKinds`-based encoding that requires neither auxiliary datatypes (corresponding to the `DerivTyCon` constructor of `DerivStuff`) nor instances for them (the `DerivInst` constructor of `DerivStuff`). It appears that `DerivTyCon` constructor was removed at some point, but `DerivInst` never was. No `DerivInst` values are ever constructed, so we can safely remove it. Test Plan: It builds Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2481 >--------------------------------------------------------------- f4384ef5b42bb64b55d6c930ed9850a021796f36 compiler/typecheck/TcDeriv.hs | 5 ++--- compiler/typecheck/TcGenDeriv.hs | 22 +++++++++------------- 2 files changed, 11 insertions(+), 16 deletions(-) diff --git a/compiler/typecheck/TcDeriv.hs b/compiler/typecheck/TcDeriv.hs index 70eaf5c..e38cfdc 100644 --- a/compiler/typecheck/TcDeriv.hs +++ b/compiler/typecheck/TcDeriv.hs @@ -387,13 +387,12 @@ tcDeriving deriv_infos deriv_decls ; let (inst_infos, deriv_stuff, maybe_fvs) = unzip3 (insts1 ++ insts2) ; loc <- getSrcSpanM - ; let (binds, famInsts, extraInstances) = - genAuxBinds loc (unionManyBags deriv_stuff) + ; let (binds, famInsts) = genAuxBinds loc (unionManyBags + deriv_stuff) ; dflags <- getDynFlags ; (inst_info, rn_binds, rn_dus) <- - renameDeriv is_boot (inst_infos ++ (bagToList extraInstances)) binds + renameDeriv is_boot inst_infos binds ; unless (isEmptyBag inst_info) $ liftIO (dumpIfSet_dyn dflags Opt_D_dump_deriv "Derived instances" diff --git a/compiler/typecheck/TcGenDeriv.hs b/compiler/typecheck/TcGenDeriv.hs index 2eb8c07..dce0b16 100644 --- a/compiler/typecheck/TcGenDeriv.hs +++ b/compiler/typecheck/TcGenDeriv.hs @@ -70,7 +70,6 @@ import Lexeme import FastString import Pair import Bag -import TcEnv (InstInfo) import StaticFlags( opt_PprStyle_Debug ) import ListSetOps ( assocMaybe ) @@ -90,12 +89,11 @@ data AuxBindSpec data DerivStuff -- Please add this auxiliary stuff = DerivAuxBind AuxBindSpec - -- Generics + -- Generics and DeriveAnyClass | DerivFamInst FamInst -- New type family instances -- New top-level auxiliary bindings | DerivHsBind (LHsBind RdrName, LSig RdrName) -- Also used for SYB - | DerivInst (InstInfo RdrName) -- New, auxiliary instances {- ************************************************************************ @@ -2346,11 +2344,11 @@ genAuxBindSpec loc (DerivMaxTag tycon) max_tag = case (tyConDataCons tycon) of data_cons -> toInteger ((length data_cons) - fIRST_TAG) -type SeparateBagsDerivStuff = -- AuxBinds and SYB bindings - ( Bag (LHsBind RdrName, LSig RdrName) - -- Extra bindings (used by Generic only) - , Bag (FamInst) -- Extra family instances - , Bag (InstInfo RdrName)) -- Extra instances +type SeparateBagsDerivStuff = + -- AuxBinds and SYB bindings + ( Bag (LHsBind RdrName, LSig RdrName) + -- Extra family instances (used by Generic and DeriveAnyClass) + , Bag (FamInst) ) genAuxBinds :: SrcSpan -> BagDerivStuff -> SeparateBagsDerivStuff genAuxBinds loc b = genAuxBinds' b2 where @@ -2363,16 +2361,14 @@ genAuxBinds loc b = genAuxBinds' b2 where genAuxBinds' :: BagDerivStuff -> SeparateBagsDerivStuff genAuxBinds' = foldrBag f ( mapBag (genAuxBindSpec loc) (rm_dups b1) - , emptyBag, emptyBag) + , emptyBag ) f :: DerivStuff -> SeparateBagsDerivStuff -> SeparateBagsDerivStuff f (DerivAuxBind _) = panic "genAuxBinds'" -- We have removed these before f (DerivHsBind b) = add1 b f (DerivFamInst t) = add2 t - f (DerivInst i) = add3 i - add1 x (a,b,c) = (x `consBag` a,b,c) - add2 x (a,b,c) = (a,x `consBag` b,c) - add3 x (a,b,c) = (a,b,x `consBag` c) + add1 x (a,b) = (x `consBag` a,b) + add2 x (a,b) = (a,x `consBag` b) mkParentType :: TyCon -> Type -- Turn the representation tycon of a family into _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel…

1 0

Action Required: Status of Harbormaster for Differentials
by Ben Gamari 30 Aug '16

30 Aug '16

tl;dr. I am working on restoring Harbormaster support for Differentials. Towards this end, GHC's Phabricator instance will soon require that you add an SSH public key to your account in order to upload patches with `arc diff`. Hello everyone, As you are no doubt aware Harbormaster has not been building Differentials for a very long time now. I am currently looking at options for restoring this service but it appears that doing so will require a bit of action on the part of our contributors. Specically, you will need to add an SSH key to Phabricator. You can do so by navigating to the Phabricator Settings [1] page, selecting the "Personal Account Settings" option, and selecting "SSH Public Keys" from the list on the left. There you can click on the "SSH Key Actions" menu on the top-right corner and click on the "Upload Public Key" item. Here you can specify a key name and paste the key contents (e.g. the contents of $HOME/.ssh/id_rsa.pub). The reason for this new requirement is that `arc diff` will soon push submitted diffs to a "staging area", a Git repository managed by Phabricator containing a branch for each submitted Differential. This will allow more reliable Harbormaster builds and merges as we will no longer need to rely on Phabricator correctly applying Differential patches (which has historically been problematic, especially for Differentials where the base commit is unavailable). If there are no objections, I would like to enable the staging area for the rGHC repository in three days, on Monday, 29 August 2016. After this date `arc diff` will try to push submitted differentials to the staging area, which will require a public key. Note, however, that pushing to the staging area can always be disabled with `arc diff`'s `--skip-staging` flag (although we won't be able to run CI builds on Differentials submitted in this way). To be clear: I would have liked to provide an option that did not require key-based authentication, but sadly neither Phabricator nor Gitolite provide any such option. I apologize for the added friction that this new requirement imposes. If enough people feel strongly that this is too onerous then I'm happy to entertain alternative solutions. Cheers, - Ben [1] https://phabricator.haskell.org/settings/

5 12

Trying to refactor DeriveAnyClass, stuck on typechecker-related code
by Ryan Scott 27 Aug '16

27 Aug '16

Simon, I'm currently working on a solution to #12144, which changes the way inferred contexts for DeriveAnyClass works, as per your suggestion here [1]. I've made some good progress in that instances derived using DeriveAnyClass now emit contexts that are gathered from the default signatures of the derived class itself. However, I've come to an impasse. This approach currently fails to work with most GHC Generics-style classes, for reasons that I'll explain below. Consider this example (abridged from here [2]): data StrictMaybe a = StrictNothing | StrictJust !a deriving (FullyStrict, Generic) class FullyStrict a where fullyStrict :: proxy a -> Bool default fullyStrict :: (GFullyStrict (Rep a)) => proxy a -> Bool fullyStrict _ = gfullyStrict (Proxy :: Proxy (Rep a p)) With the new approach, the derived FullyStrict instance for StrictMaybe a will emit the context (GFullyStrict (Rep (StrictMaybe a)), but then fail with the error: No instance for (GFullyStrict (Rep (StrictMaybe a)) I think I understand why this is happening: if you look at the definition of tcDeriving in TcDeriv [3], it calls simplifyInstanceContexts, which would normally reduce type families like Rep. But the problem is that the Rep (StrictMaybe a) instance is also being derived at the same time (via the derived Generic instance)! What's worse, the call to simplifyInstanceContexts happens before the code that adds Rep (StrictMaybe a) to the type family instance environment (tcExtendLocalFamInstEnv (bagToList famInsts)). So simplifyInstanceContexts is unable to reduce Rep (StrictMaybe a), and as a result the context fails to simplify, resulting in the above error. This leads me to think we need to be adding Rep (StrictMaybe a) to the instance environment before calling simplifyInstanceContexts. But with the way the code is structured currently, I don't see an easy way to do this. The problem is that the genInst function [4] generates all of the following at the same time in one large bundle: * The instance code itself (InstInfo RdrName) * The associated type family instances (BagDerivStuff) * Auxiliary top-level bindings (BagDerivStuff) And within tcDeriving, the call to genInst takes as input the output of simplifyInstanceContexts, making it impossible to get the type family instances before calling simplifyInstanceContexts. Here are my questions: is it possible to take type family instances out of BagDerivStuff and instead add them to the instance environment before simplifyInstanceContexts? Would there be any typechecking issues involved with having the associated family instances in the local environment before the actual class instances themselves? Ryan S. ----- [1] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012276.html [2] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8… [3] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8… [4] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8…

2 2

RE: [Diffusion] [Build Failed] rGHCae66f356fb0d: Allow typed holes to be levity-polymorphic
by Simon Peyton Jones 26 Aug '16

26 Aug '16

Ben or others Something is wrong with the .stderr file for T12531 (typed holes), which I just fixed. Not easy for me to sort out at home..might someone look? Or mark it as expect fail and I'll deal with it on Monday Thanks Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 26 August 2016 18:24 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHCae66f356fb0d: Allow typed holes to be levity-polymorphic Harbormaster failed to build B10796: rGHCae66f356fb0d: Allow typed holes to be levity-polymorphic! BRANCHES master USERS simonpj (Author) O7 (Auditor) O11 (Auditor) COMMIT https://phabricator.haskell.org/rGHCae66f356fb0d EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

1 0

Trac commit notifications on stable branches
by Ben Gamari 26 Aug '16

26 Aug '16

Hello everyone, For a long time we've had a Git hook which adds comments to Trac tickets mentioned in commits on the master branch. Today I enabled similar notifications for the commits on the stable branches (e.g. ghc-8.0) in an attempt at reducing the overhead of maintaining the stable branches. Please let me know if you find these additional notifications too noisy. Cheers, - Ben

2 3

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