Add Prisms for template-haskell-2.23

[RyanGlScott]

No description provided.

[phadej]

The 9.12 job seems to pick aeson-0.9.0.1, that's interesting, as I didn't manage to figure out why; locally I get ~latest aeson. If you manage to find a reason (what choice order solver does to eventually settle with that old aeson), i'd be keen to know.

EDIT: found a reason, you need head.hackage to trigger that.

[RyanGlScott]

Self-reminder: this should be now say template-haskell-2.23 instead of 2.22.1 (the version number changed between the 9.12 alphas and release candidate 1).

[phadej]

head.hackage seems to contain stale text-short, th-abstraction patches (and maybe others which I fail to spot). And haskell-ci uses :override, so newer versions are not seen, so solver is likely to simply chose package versions with less dependencies.

We could argue about not using :override, but I found it more confusing when version in head.hackage were not picked, or when newer but incompatible version was picked instead of head.hackage patch. TL;DR override is probably less bad, as head.hackage is much more controlled repository. It should be kept up to date.

[RyanGlScott]

That makes sense, and I agree that the ideal solution would be to update head.hackage. I'll try to do this when I have a chance.

[RyanGlScott]

This doctest is failing on GHC 9.12:

lens/src/Control/Exception/Lens.hs

Line 679 in 0ef83b7

-- >>> handling _AssertionFailed (\ xs -> "caught" <$ guard ("<interactive>" `isInfixOf` xs) ) $ assert False (return "uncaught")

From the CI log:

[   0.72549] docspec.phase2: Control.Exception.Lens
[   0.92633] error: handling _AssertionFailed (\ xs -> "caught" <$ guard ("<interactive>" `isInfixOf` xs) ) $ assert False (return "uncaught")
[   0.92681] error: in comment at 677:3
-"caught"
+*** Exception: user error (mzero)
+
+While handling Assertion failed
+
[   0.92716] info: Actual result:
*** Exception: user error (mzero)

While handling Assertion failed

I think this is a knock-on effect of the exception backtrace proposal being implemented. For a simpler way to observe the difference, try running this in GHCi 9.10.1:

$ ghci-9.10.1
λ> import Control.Exception
λ> assert False (pure "hello") `catch` \(AssertionFailed xs) -> pure xs
"Assertion failed\nCallStack (from HasCallStack):\n  assert, called at <interactive>:2:1 in interactive:Ghci2"

Versus GHC 9.12.1:

$ ghci-9.12.1
λ> import Control.Exception
λ> assert False (pure "hello") `catch` \(AssertionFailed xs) -> pure xs
"Assertion failed"

I'll have to see if there is a way to restore the old behavior, or perhaps even changing the doctest to make it more robust across GHC versions.

[RyanGlScott]

Sadly, debugging why the behavior of AssertionFailed changes in GHC 9.12.1 is beyond my ability. I've filed GHC#25610 upstream to see if an expert can chime in on how best to fix this. Until then, I'll either CPP out this doctest or disable it temporarily.

[soulomoon]

Is it possible we use the ErrorCall which would contain the stack?

ghci> import Control.Exception
ghci> assert False (pure "hello") `catch` \(ErrorCall xs) -> pure xs
*** Exception: Assertion failed

HasCallStack backtrace:
  throwIO, called at libraries/ghc-internal/src/GHC/Internal/IO/Exception.hs:444:5 in ghc-internal:GHC.Internal.IO.Exception
  assert, called at <interactive>:3:1 in interactive:Ghci2

[RyanGlScott]

Unless I'm missing something, ErrorCall is meant for catching calls to error, not assert. (As evidence of this, the call to catch in your code example never actually catches an exception.)

[soulomoon]

Sorry for the mistake, maybe use SomeException 0 0, replied you at gitlab.