[ghc-steering-committee] Proposal #612: Change semantics of -fhpc to not accumulate data over multiple runs, rec: accept

[Arnaud Spiwack]

For the record, I'm fine either way.

On Mon, 29 Jan 2024 at 10:35, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> The change itself makes sense to me, non-accumulating semantics seem like
> a much better default.
>
>
> I strongly agree with this.  The current behaviour seems deeply strange,
> and the proposer offers evidence that it messes up users.
>
> As to deprecation, how about this:
>
>    - In the first release, GHC continues with the current behaviour, but
>    *if* it finds an old file (of any kind, even in the wrong format) it emits
>    a warning (before attempting to read it) saying
>
> *I am reading in the existing tix file, and will add hpc info from this
> run to the existing data in that file.  GHC 9.12 will cease looking for an
> existing tix file.  If you positively want to add hpc info to the current
> tix file, use `-fread-tix-file`*
>
>    - In the next release, it stops reading the file
>
> That is not onerous to implement, but it gives due warning.  Moreover, you
> can respond right away by saying `-fno-read-tix-file` or `-fread-tix-file`
> to avoid the warning.
>
> Simon says
>
> I don't think a deprecation warning resolves the concern
>>
>
> That's true of all deprecation warnings -- there will always be users who
> ignore them.  But we have done our duty by, well, warning them.
>
> Simon
>
> On Thu, 25 Jan 2024 at 06:06, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Dear Committee members,
>>
>> In Proposal #612
>> <https://github.com/ghc-proposals/ghc-proposals/pull/612>, David Binder
>> suggests changing the semantics from `-fhpc` to auto-ingest
>> existing .tix files for accumulation, towards _not_ auto-ingesting them
>> and instead overwriting
>> the .tix file with the coverage of the latest run.
>>
>> I agree with his assessment that the current behaviour easily leads to
>> unexpected surprises. He suggests adding a flag --read-tix-file= to control
>> this behaviour and defaulting that to _no_, with a grace and
>> deprecation period prior informing the user that the currently accumulating
>> feature will change in a future GHC release.
>>
>> Adding the flag to control this behaviour is fairly uncontroversial I
>> hope, however I'd like you to. Weight in on the default. Should we change
>> the default behaviour, or only add the flag?
>>
>> I'd recommend changing the default to --read-tix-file=no after a
>> deprecation period.
>>
>> Best,
>>  Moritz
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240129/090b9d8b/attachment-0001.html>