[Git][ghc/ghc][wip/romes/exceptions-layout] 3 commits: base: Propagate `error` CallStack to thrown exception

[Rodrigo Mesquita (@alt-romes)]

Rodrigo Mesquita pushed to branch wip/romes/exceptions-layout at Glasgow Haskell Compiler / GHC


Commits:
5e81a005 by Ben Gamari at 2024-09-24T10:47:06+01:00
base: Propagate `error` CallStack to thrown exception

Previously `errorCallWithCallStackException` failed to propagate its
`CallStack` argument, which represents the call-chain of the preceding
`error` call, to the exception that it returned. Consequently, the
call-stack of `error` calls were quite useless.

Unfortunately, this is the second time that I have fixed this but it
seems the first must have been lost in rebasing.

Fixes a bug in the implementation of CLC proposal 164
<https://github.com/haskell/core-libraries-committee/issues/164>

Fixes #24807.

- - - - -
e61bb185 by Rodrigo Mesquita at 2024-09-24T11:29:54+01:00
exceptions: Improve the message layout as per #285

This commit fixes the layout of the additional information included when
displaying an exception, namely the type of the exception.

It also fixes the default handler's heading message to work well
together with the improved display message of SomeException.

- - - - -
233d9931 by Rodrigo Mesquita at 2024-09-24T11:29:54+01:00
Display type and callstack of exception on handler

This commit changes the Exception instance of SomeException to *simply*
display the underlying exception in `displayException`. The augmented
exception message that included the type and backtrace of the exception
are now only printed on a call to `displayExceptionWithInfo`.

At a surface level, existing programs should behave the same since the
`uncaughtExceptionHandler`, which is responsible for printing out uncaught
exceptions to the user, will use `displayExceptionWithInfo` by default.

However, unlike the instance's `displayException` method, the
`uncaughtExceptionHandler` can be overriden with
`setUncaughtExceptionHandler`. This makes the extra information opt-in
without fixing it the instance, which can be valuable if your program
wants to display uncaught exceptions to users in a user-facing way
(ie without backtraces).

This is what was originally agreed for CLC#231 or CLC#261 with regard to
the type of the exception information.

The call stack also becoming part of the default handler rather than the
Exception instance is an ammendment to CLC#164.

Discussion of the ammendment is part of CLC#285.

- - - - -


30 changed files:

- docs/users_guide/9.12.1-notes.rst
- libraries/base/changelog.md
- libraries/base/tests/IO/T4808.stderr
- libraries/base/tests/IO/mkdirExists.stderr
- libraries/base/tests/IO/openFile002.stderr
- libraries/base/tests/IO/withBinaryFile001.stderr
- libraries/base/tests/IO/withBinaryFile002.stderr
- libraries/base/tests/IO/withFile001.stderr
- libraries/base/tests/IO/withFile002.stderr
- libraries/base/tests/IO/withFileBlocking001.stderr
- libraries/base/tests/IO/withFileBlocking002.stderr
- libraries/base/tests/T15349.stderr
- libraries/base/tests/T16111.stderr
- libraries/base/tests/T19288.stderr
- + libraries/base/tests/T24807.hs
- + libraries/base/tests/T24807.stderr
- libraries/base/tests/all.T
- libraries/base/tests/assert.stderr
- libraries/base/tests/readFloat.stderr
- libraries/base/tests/topHandler04.stderr
- libraries/ghc-compact/tests/compact_function.stderr
- libraries/ghc-compact/tests/compact_mutable.stderr
- libraries/ghc-compact/tests/compact_pinned.stderr
- libraries/ghc-internal/src/GHC/Internal/Conc/Sync.hs
- libraries/ghc-internal/src/GHC/Internal/Exception.hs
- libraries/ghc-internal/src/GHC/Internal/Exception/Type.hs
- testsuite/tests/arityanal/should_run/T21694a.stderr
- testsuite/tests/arityanal/should_run/T24296.stderr
- testsuite/tests/array/should_run/arr003.stderr
- testsuite/tests/array/should_run/arr004.stderr


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a971620c7f026a0f97d883eafe9feae7be7246d6...233d99319958dee0da9c924f69d996b83182eb6b

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a971620c7f026a0f97d883eafe9feae7be7246d6...233d99319958dee0da9c924f69d996b83182eb6b
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240924/9d058184/attachment.html>