I assume that if cost-centre-profiling is off then dsExpr (HsScc _ e) = dsExpr e
Looks like the dsExpr case for HsScc would need that test. Simon From: Alan & Kim Zimmerman [mailto:[email protected]] Sent: 03 December 2014 13:03 To: Simon Peyton Jones Cc: [email protected] Subject: Re: API Annotations and HsSCC / HsTickPragma If I look in DeSugar.lhs I see -- Desugar the program ; let export_set = availsToNameSet exports target = hscTarget dflags hpcInfo = emptyHpcInfo other_hpc_info want_ticks = gopt Opt_Hpc dflags || target == HscInterpreted || (gopt Opt_SccProfilingOn dflags && case profAuto dflags of NoProfAuto -> False _ -> True) ; (binds_cvr, ds_hpc_info, modBreaks) <- if want_ticks && not (isHsBootOrSig hsc_src) then addTicksToBinds dflags mod mod_loc export_set (typeEnvTyCons type_env) binds else return (binds, hpcInfo, emptyModBreaks) So it looks like `addTicksToBinds` is only called when profiling is on. But there is also DsExpr.lhs which does dsExpr (HsSCC cc expr@(L loc _)) = do mod_name <- getModule count <- goptM Opt_ProfCountEntries uniq <- newUnique Tick (ProfNote (mkUserCC cc mod_name loc uniq) count True) <$> dsLExpr expr I *think* that the dsExpr value is ignored if profiling is inactive, and I am hoping that all that needs changing is the parser to always emit HsSCC, instead of HsPar if Opt_SccProfilingOn is not set. Is this correct? Alan On Wed, Dec 3, 2014 at 1:52 PM, Alan & Kim Zimmerman <[email protected]<mailto:[email protected]>> wrote: Ok, that makes sense. Thanks Alan On Wed, Dec 3, 2014 at 1:30 PM, Simon Peyton Jones <[email protected]<mailto:[email protected]>> wrote: Please don’t do (1). That would horribly clutter HsPar. I suggest (2). Actually I suggest you don’t have the Bool at all. Instead, in the desugarer, if you come across a HsScc, discard it unless it is active. We only need the Bool to cache the “am I active” question if there are zillions of places where we need to know. But I bet there is only one, namely the desugarer. The spirit of the front end is: leave the source code entirely undisturbed until desugaring. Throwing away HsScc and turning them in HsPar is against this spirit SImon From: ghc-devs [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Alan & Kim Zimmerman Sent: 02 December 2014 20:19 To: [email protected]<mailto:[email protected]> Subject: API Annotations and HsSCC / HsTickPragma I am in the process of working the shiny new API annotations through into a practical example in ghc-exactprint [1], but I have hit a snag. A SCC annotation appears in the source as {-# SCC "name" #-} <expression> and if enabled via -prof results in the expression being wrapped in HsSCC FastString (LHsExpr id) BUT, if not enabled, it appears as HsPar (LHsExpr id) From the parser/annotation point of view, the appropriate annotations are generated, and can be used to distinguish the two cases. The problem is that the annotations only capture the SrcSpan of the thing being annotated, so in the HsPar case the contents of the FastString is lost. A similar situation exists for HsTickPragma, HsTickPragma -- A pragma introduced tick (FastString,(Int,Int),(Int,Int)) -- external span for this tick (LHsExpr id) which also degrades to HsPar I see a number of possible solutions 1. Add the missing information to HsPar in a Maybe HsPar (Maybe (FastString,(Int,Int),(Int,Int))) (LHsExpr id) 2. Modify HsSCC / HsTickPragma to have a Bool indicating whether they are active or not. 3. Introduce an additional annotation type to carry the missing information. I welcome advice on the best way forward. Alan [1] https://github.com/alanz/ghc-exactprint/tree/wip
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
