Add HasCallStack

[Bodigrim]

This mimics recently approved https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6772/diffs

[sjakobi]

How does this affect performance? I imagine it wouldn't be too bad.

[Bodigrim]

As https://mail.haskell.org/pipermail/libraries/2021-May/031246.html explains, adding HasCallStack to non-recursive functions, which are likely to inline, should not impose additional performance costs. We also provide Data.ByteString.Unsafe, which should be used in performance-critical setting.

[Bodigrim]

I wonder whether addition of HasCallStack requires a major version bump. It cannot break anything, however there could be clients who catch error in IO and analyse error message.

[sjakobi]

I wonder whether addition of HasCallStack requires a major version bump. It cannot break anything, however there could be clients who catch error in IO and analyse error message.

🤷

@phadej, what do you think?

[Bodigrim]

On the other hand, it's equivalent to changing error messages, which I would not qualify as a breakage...

[sjakobi]

I wonder whether addition of HasCallStack requires a major version bump. It cannot break anything, however there could be clients who catch error in IO and analyse error message.

Are you sure that it won't break anything? It reminds me of haskell/cabal#6545, where some code involving HasCallStack required changes due to simplified subsumption. I'm wondering whether adding HasCallStack constraints might also require changes on the user side.

[Bodigrim]

Cf. https://discourse.haskell.org/t/is-adding-hascallstack-a-breaking-change/3696/11

I was leaning to "non-breaking", but haskell/cabal#6545 looks pretty bad :(

[phadej]

#6545 is not due HasCallStack itself but due

type IO a = HasCallStack => Base.IO a

which is rank2 type-alias. And that's what was affected by simplified subsumption.

[sjakobi]

I'm fine with treating this as a non-breaking change, i.e. releasing this in 0.11.x.