November 2018 - ghc-devs

perf stats
by Simon Peyton Jones 15 Nov '18

15 Nov '18

This has just started happening in my local build tree Appending 0 stats to git notes. fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). An error occured while writing the performance metrics to git notes. This is usually due to a lock-file existing somewhere in the git repo. ../../mk/test.mk:344: recipe for target 'test' failed make: *** [test] Error 1 Should I worry? it looks bad. I definitely don’t want to monkey with git notes when I’m just developing/testing/validating, which I do endlessly Simon

1 1

Unused RTS symbols disappearing in some flavors?
by Ömer Sinan Ağacan 15 Nov '18

15 Nov '18

Hi, When I build RTS with flavors other than quick (and maybe others) unused symbols get removed, which makes debugging harder. Does anyone know what setting to add to build.mk to make sure symbols won't be removed? Ideally I should be able to add one line at the end of build.mk and the symbols should not be removed regardless of the flavor. Thanks, Ömer

1 0

slow execution of built executables on a Mac
by Richard Eisenberg 13 Nov '18

13 Nov '18

Hi devs, I have a shiny, new iMac in my office. It's thus frustrating that it takes my iMac longer to build GHC than my trusty 28-month-old laptop. Building devel2 on a fresh checkout takes just about an hour. By contrast, my laptop is done after 30 minutes of work (same build settings). The laptop has a 2.8GHz Intel i7 running macOS 10.13.5; the desktop has a 3.5GHz Intel i5 running macOS 10.13.6. Both bootstrapped from the binary distro of GHC 8.6.1. Watching GHC build, everything is snappy enough during the stage-1 build. But then, as soon as we start using GHC-produced executables, things slow down. It's most noticeable in the rts_dist_HC phase, which crawls. Stage 2 is pretty slow, too. So: is there anything anyone knows about recent Macs not liking locally built executables? Or is there some local setting that I need to update? The prepackaged GHC seems to work well, so that gives me hope that someone knows what setting to tweak. Thanks! Richard

6 11

RE: [commit: ghc] wip/az-namemap: Introduce map from RdrName to Name for GHC API (2745981)
by Simon Peyton Jones 12 Nov '18

12 Nov '18

Alan Interesting. The GlobalRdrEnv is such a mapping. I'm not sure what the goal is here. Would it be worth a ticket and/or wiki page to explain the problem you are trying to solve? Simon | -----Original Message----- | From: ghc-commits <ghc-commits-bounces(a)haskell.org> On Behalf Of | git(a)git.haskell.org | Sent: 12 November 2018 18:32 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/az-namemap: Introduce map from RdrName to Name | for GHC API (2745981) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/az-namemap | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haskel | l.org%2Ftrac%2Fghc%2Fchangeset%2F2745981fb8a558cd486b674e4b15db8528f0cc78% | 2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9d848ba78ecd428ff7a508d | 648cd2a74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636776443360189215& | amp;sdata=o7swv001G%2Bc%2FQAw23xr6GA18iXS8YratFJahszIIRH4%3D&reserved= | 0 | | >--------------------------------------------------------------- | | commit 2745981fb8a558cd486b674e4b15db8528f0cc78 | Author: Alan Zimmerman <alan.zimm(a)gmail.com> | Date: Mon Nov 12 20:26:40 2018 +0200 | | Introduce map from RdrName to Name for GHC API | | Tools need to work with the ParsedSource as a accurate representation | of the compiled source, but sometimes need access to the actual Names | used from the renaming phase. | | Introduce a function that initialises a NameMap from a TypechedModule, | for use by GHC API consumers. | | | >--------------------------------------------------------------- | | 2745981fb8a558cd486b674e4b15db8528f0cc78 | compiler/main/GHC.hs | 133 | +++++++++++++++++++++++++++++++++++++++++++++++++++ | 1 file changed, 133 insertions(+) | | diff --git a/compiler/main/GHC.hs b/compiler/main/GHC.hs | index cf9c74f..9d9cf17 100644 | --- a/compiler/main/GHC.hs | +++ b/compiler/main/GHC.hs | @@ -1,5 +1,6 @@ | {-# LANGUAGE CPP, NondecreasingIndentation, ScopedTypeVariables #-} | {-# LANGUAGE TupleSections, NamedFieldPuns #-} | +{-# LANGUAGE RankNTypes #-} | | -- ---------------------------------------------------------------------- | ------- | -- | @@ -125,6 +126,7 @@ module GHC ( | -- ** Looking up a Name | parseName, | lookupName, | + initRdrNameMap, NameMap, | | -- ** Compiling expressions | HValue, parseExpr, compileParsedExpr, | @@ -306,6 +308,7 @@ import TcRnTypes | import Packages | import NameSet | import RdrName | +import Var | import HsSyn | import Type hiding( typeKind ) | import TcType hiding( typeKind ) | @@ -352,7 +355,9 @@ import TcRnDriver | import Inst | import FamInst | import FileCleanup | +import Unique ( mkUnique ) | | +import Data.Data ( Data, gmapQ, cast ) | import Data.Foldable | import qualified Data.Map.Strict as Map | import Data.Set (Set) | @@ -1531,6 +1536,134 @@ lookupName :: GhcMonad m => Name -> m (Maybe | TyThing) | lookupName name = | withSession $ \hsc_env -> | liftIO $ hscTcRcLookupName hsc_env name | +-- ---------------------------------------------------------------------- | ------- | + | +-- | Map of 'SrcSpan's from 'Located' 'RdrName's in the 'ParsedSource' | +-- to the corresponding 'Name' from renaming. | +type NameMap = Map.Map SrcSpan Name | + | +-- | Tools prefer to work with the 'ParsedSource' because it more | +-- closely reflects the actual source code, but must be able to work | +-- with the renamed representation of the names involved. This | +-- function constructs a map from every 'Located' 'RdrName' in the | +-- 'ParsedSource' to its corresponding name in the 'RenamedSource' and | +-- 'TypecheckedSource'. | +initRdrNameMap :: TypecheckedModule -> NameMap | +initRdrNameMap tm = r | + where | + parsed = pm_parsed_source $ tm_parsed_module tm | + renamed = tm_renamed_source tm | + typechecked = tm_typechecked_source tm | + | + checkRdr :: Located RdrName -> Maybe [(SrcSpan,RdrName)] | + checkRdr (L l n@(Unqual _)) = Just [(l,n)] | + checkRdr (L l n@(Qual _ _)) = Just [(l,n)] | + checkRdr (L _ _)= Nothing | + | + checkName :: Located Name -> Maybe [Located Name] | + checkName ln = Just [ln] | + | + rdrNames = fromMaybe (panic "initRdrNameMap") | + $ everything mappend (nameSybQuery checkRdr ) parsed | + names1 = fromMaybe (panic "initRdrNameMap") | + $ everything mappend (nameSybQuery checkName) renamed | + names2 = names1 ++ everything (++) ([] `mkQ` fieldOcc | + `extQ` hsRecFieldN) renamed | + names = names2 ++ everything (++) ([] `mkQ` hsRecFieldT) | typechecked | + | + fieldOcc :: FieldOcc GhcRn -> [Located Name] | + fieldOcc (FieldOcc n (L l _)) = [(L l n)] | + fieldOcc XFieldOcc {} = [] | + | + hsRecFieldN :: LHsExpr GhcRn -> [Located Name] | + hsRecFieldN (L _ (HsRecFld _ (Unambiguous n (L l _) ))) = [L l n] | + hsRecFieldN _ = [] | + | + hsRecFieldT :: LHsExpr GhcTc -> [Located Name] | + hsRecFieldT (L _ (HsRecFld _ (Ambiguous n (L l _)) )) | + = [L l (Var.varName n)] | + hsRecFieldT _ = [] | + | + nameMap = Map.fromList $ map (\(L l n) -> (l,n)) names | + | + -- If the name does not exist (e.g. a TH Splice that has been | + -- expanded, make a new one) | + -- No attempt is made to make sure that equivalent ones have | + -- equivalent names. | + lookupName l n i = case Map.lookup l nameMap of | + Just v -> v | + Nothing -> | + case n of | + Unqual u -> mkNewGhcNamePure 'h' i Nothing (occNameString u) | + Qual q u -> mkNewGhcNamePure 'h' i | + (Just (Module (stringToUnitId "") q)) | (occNameString u) | + _ -> panic "initRdrNameMap" | + | + r = Map.fromList $ map (\((l,n),i) -> (l,lookupName l n i)) | + $ zip rdrNames [1..] | + | + nameSybQuery :: (Typeable a, Typeable t) | + => (Located a -> Maybe r) -> t -> Maybe r | + nameSybQuery checker = q | + where | + q = Nothing `mkQ` worker | + | + worker (pnt :: (Located a)) | + = checker pnt | + | + mkNewGhcNamePure :: Char -> Int -> Maybe Module -> String -> Name | + mkNewGhcNamePure c i maybeMod name = | + let un = mkUnique c i -- H for HaRe :) | + n = case maybeMod of | + Nothing -> mkInternalName un (mkVarOcc name) | noSrcSpan | + Just modu -> mkExternalName un modu (mkVarOcc name) | noSrcSpan | + in n | + | + | +-- Copied from SYB | + | + | +-- | Generic queries of type \"r\", | +-- i.e., take any \"a\" and return an \"r\" | +-- | +type GenericQ r = forall a. Data a => a -> r | + | + | +-- | Make a generic query; | +-- start from a type-specific case; | +-- return a constant otherwise | +-- | +mkQ :: ( Typeable a | + , Typeable b | + ) | + => r | + -> (b -> r) | + -> a | + -> r | +(r `mkQ` br) a = case cast a of | + Just b -> br b | + Nothing -> r | + | +-- | Extend a generic query by a type-specific case | +extQ :: ( Typeable a | + , Typeable b | + ) | + => (a -> q) | + -> (b -> q) | + -> a | + -> q | +extQ f g a = maybe (f a) g (cast a) | + | + | + | +-- | Summarise all nodes in top-down, left-to-right order | +everything :: (r -> r -> r) -> GenericQ r -> GenericQ r | + | +-- Apply f to x to summarise top-level node; | +-- use gmapQ to recurse into immediate subterms; | +-- use ordinary foldl to reduce list of intermediate results | + | +everything k f x = foldl k (f x) (gmapQ (everything k f) x) | | -- ---------------------------------------------------------------------- | ------- | -- Pure API | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9d848ba78ecd428ff7a50 | 8d648cd2a74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63677644336018921 | 5&sdata=fLoupgPItcbuELQ%2B7bnPKHXZ595utTpqL%2FzwLELpSuk%3D&reserve | d=0

1 0

GHC's Fall 2018 HCAR submission
by Ben Gamari 12 Nov '18

12 Nov '18

Hello everyone, The Haskell Community Activities Report is coming up and I have prepared the skeleton for GHC's contribution [1]. If you have a project cooking or have recently had a patch land do have a look to make sure it's recognized in the submission. Cheers, - Ben https://ghc.haskell.org/trac/ghc/wiki/Status/Oct18

6 10

Help on tuple section in TH
by Yotam Ohad 11 Nov '18

11 Nov '18

Hello, I'm a wannabe ghc contributor on my first patch. I'm trying to do #15843 and I would like some help. I understand that I need to change repE in DsMeta.hs An explanation of the type signatures and the types would be very helpful. Also, What does repLEs do? Thanks for your help Yotam

3 2

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms
by Ryan Scott 09 Nov '18

09 Nov '18

You *can* put `LL` into a COMPLETE set, but under the stipulation that you specify which type constructor it's monomorphized to. To quote the wiki page on COMPLETE sets: In the case where all the patterns are polymorphic, a user must provide a type signature but we accept the definition regardless of the type signature they provide. The type constructor for the whole set of patterns is the type constructor as specified by the user. If the user does not provide a type signature then the definition is rejected as ambiguous. This design is a consequence of the design of the pattern match checker. Complete sets of patterns must be identified relative to a type. This is a sanity check as users would never be able to match on all constructors if the set of patterns is inconsistent in this manner. In other words, this would work provided that you'd be willing to list every single instance of `HasSrcSpan` in its own COMPLETE set. It's tedious, but possible. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs#Typing

5 9

trac ticket about missing in tree gmp on newest mac ghc builds
by Carter Schonwald 09 Nov '18

09 Nov '18

hey Ben, HVR https://ghc.haskell.org/trac/ghc/ticket/15769 seems to indicate there was quite a serious faux pas in the mac builds, do you folk need help? -Carter

1 0

StgRhsClosure freevar and argument name duplicates
by Csaba Hruska 07 Nov '18

07 Nov '18

Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) *[occ]* -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry *[bndr]* -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr bndr occ) -- body

2 15

GHC 8.8 freeze in three weeks
by Ben Gamari 05 Nov '18

05 Nov '18

Hello everyone, Incredibly enough we are quickly coming up on three months since the nominal GHC 8.6.1 release date. This means that the GHC 8.8 branch is quickly approaching. We will plan on cutting the branch on November 18th. Note that this is in three weeks. If you have a patch that you would like to see in GHC 8.8 and it isn't yet up on Phabricator, do let me know. Moreover, if you have something that will be in GHC 8.8 and you haven't yet added it to the release status page [1], please add it. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.8.1

2 2