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

[Arnaud Spiwack]

On Thu, 25 Jan 2024 at 11:49, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> To address your two points in detail:
> > Is a deprecation period necessary? Or even useful (how do we signal the
> upcoming change in default, and how do we expect people would act on it)?
> - As the flag currently does not exist, call GHC with hpc without the new
> flag will issue a warning. (e.g. current users will be informed).
> - The warning message will let the user know what to pass to ghc to retain
> the old (current) behaviour, or opt in to the new (future current)
> behaviour, depending on their needs.
>
> If we did neither, the user would at some point just notice an existing
> workflow magically stopped or in this case even worse, the silent
> aggregation of .tix data would stop, and they
> might _assume_ the data was the aggregate but it wasn't. A silent change
> in default behaviour would be rather painful to notice, debug, and rectify
> for users. At least that's my expectation.
> (And I know I personally would be furious if a compiler pulled that on me).
>

My guess as to what will happen: people run hpc in CI, at a place where the
warning isn't an error, the warning won't be seen, and the breakage will
happen all the same. Just a few versions later.

To be clear, I don't really care either way. But I'm suspicious of creating
extra work for maintainers if we don't believe it's going to actually be
useful. There's not enough maintainer time as it is. So I guess my real
question is: why do you think my scenario above is incorrect?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240126/05607a15/attachment-0001.html>