API Annotations and HsSCC / HsTickPragma

Alan & Kim Zimmerman alan.zimm at gmail.com
Wed Dec 3 13:03:21 UTC 2014


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>
wrote:

> Ok, that makes sense.
>
> Thanks
>   Alan
>
> On Wed, Dec 3, 2014 at 1:30 PM, Simon Peyton Jones <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] *On Behalf Of *Alan
>> & Kim Zimmerman
>> *Sent:* 02 December 2014 20:19
>> *To:* 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/173629e0/attachment.html>


More information about the ghc-devs mailing list