Towards https://github.com/ekmett/lens/issues/1090

ncaq authored 1 year ago and Ryan Scott committed 1 year ago

The test with the following command did not pass because the decision to import the mtl module was made by referring to the transformers version.

~~~console
cabal test -w ghc-9.4 --constraint="mtl == 2.3.1"
~~~

There were two avenues to resolve this.
One is by making it refer to the mtl version,
The other is to change the transformers module to import.

It seems more natural to reference the mtl version, but since `mtl-2.3.1` still supports `transformers-0.5.6.2` which still provides `ErrorT` and so on, we can use `cabal test -w ghc-9.6 --constraint=" transformers=0.5.6.2" --constraint="mtl==2.3.1"`, the API will change when assuming `mtl-2.3.1`.
Therefore, we decided to change to import the transformers module.

For GHC 9.8.

Allow building with `template-haskell-2.20.*`

See ghc/ghc#22767.

This avoids downstream users from having to enable various language extensions
when deriving the classes from `exceptions` using `GeneralizedNewtypeDeriving`
on pre-8.0 GHCs. I have left some documentation describing why we have made
this choice, as the reasoning is somewhat non-obvious.

Fixes #91.

* Add `HasCallStack` to classes and functions

This PR adds `HasCallStack` constraints to the class methods on this library. This allows for callsites to be populated with interesting information. 

The primary use case I can imagine here is supporting [`annotated-exception`](https://hackage.haskell.org/package/annotated-exception-0.2.0.4/docs/Control-Exception-Annotated.html), and allowing you to define an instance of `MonadThrow` that always annotates with callstack:

```haskell
instance MonadThrow AppM where
    throwM = throwWithCallStack
```

With this, anything that uses `throwM` at the `AppM` type gets a call stack on the attached exception.

While this only benefits users of `annotated-exception` currently, when the GHC proposal to [decorate all exceptions with backtrace information](https://github.com/ghc-proposals/ghc-proposals/pull/330

) is implemented, then everyone benefits from this.

Without this constraint, the `CallStack` used by the above instance points to the instance definition site - not terribly useful.

* Use call-stack for backwards compatibility

* Only depend on call-stack if using an old GHC version

`exceptions` is a GHC boot package, so we want to make sure that it does not
incur any external depedencies when using a recent GHC version.

* Enable FlexibleContexts for the benefit of older GHCs

Older versions of GHC require `FlexibleContexts` to use `call-stack`'s
`type HasCallStack = (?callStack :: CallStack)` compatibility shim.

* Drop support for GHC 7.0 and 7.2

`call-stack`'s `HasCallStack` compatibility shim only supports back to GHC 7.4.
As a result, we can't reasonably support GHC 7.0 and 7.2 in `exceptions`
without a fair bit of grimy CPP. That being said, GHC 7.0 and 7.2 are quite
ancient by this point, so I'm comfortable with simply dropping support for
them. This patch makes the necessary `.cabal` and CI changes to accomplish that.

* Enable ConstraintKinds for the benefit of older GHCs

Older versions of GHC require `ConstraintKinds` to use `call-stack`'s
`type HasCallStack = (?callStack :: CallStack)` compatibility shim.

* Add withFrozenCallStack where possible

* withFrozenCallStack fix for old GHC

* freeze masks

Co-authored-by: Ryan Scott <ryan.gl.scott@gmail.com>

Ben Gamari authored 2 years ago and Ryan Scott committed 2 years ago

To accommodate GHC 9.4.

Ryan Scott authored 3 years ago and Ryan Scott committed 2 years ago

Fixes #82.

GHC Proposal #371 requires TypeOperators to use type equality a~b.
The following lines are affected:

	src/Control/Monad/Catch.hs
	354:instance e ~ SomeException => MonadThrow (Either e) where
	357:instance e ~ SomeException => MonadCatch (Either e) where
	364:instance e ~ SomeException => MonadMask (Either e) where

The fix is to simply enable the extension.

This commit was performed automatically by a script.
https://github.com/RyanGlScott/ci-maintenance

See ghc/ghc#19083.

Travis CI recently announced
[changes to its pricing model](https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing)
that will affect OSS projects. Whereas Travis previously allowed unrestricted
hours for OSS projects to run on their build machines, the new pricing model
will require the use of credits, of which free plans only have a limited
quantity. Moreover, Travis now takes an extraordinarily long time to actually
serve CI requests, which is infeasible in the long term.

As a result, I have decided
(with encouragement from other Haskell maintainers, see
[here](https://old.reddit.com/r/haskell/comments/jvbs49/psa_maintainers_should_think_about_migrating_off/))
to migrate to GitHub Actions. This
relies on a very recent version of `haskell-ci` that features a GitHub Actions
backend.

This is generated by GHC when building `exceptions` now that it has
been made a stage-0 boot library (as of commit
ghc/ghc@30272412).

This commit was performed automatically by a script.
https://github.com/RyanGlScott/travis-maintenance