API Annotations and HsSCC / HsTickPragma

[Simon Peyton Jones]

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:alan.zimm at gmail.com]
Sent: 03 December 2014 13:03
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org
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 <alan.zimm at gmail.com<mailto:alan.zimm at gmail.com>> wrote:
Ok, that makes sense.
Thanks
  Alan

On Wed, Dec 3, 2014 at 1:30 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> 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:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Alan & Kim Zimmerman
Sent: 02 December 2014 20:19
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141203/046d4b93/attachment-0001.html>