GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-26T15:25:02Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24590Out-of-range literal warnings interact poorly with rebindable syntax2024-03-26T15:25:02ZDavid FeuerOut-of-range literal warnings interact poorly with rebindable syntax## Summary
The fancy logic in `-Woverflowed-literals` can be triggered improperly under `RebindableSyntax`.
## Steps to reproduce
```haskell
{-# LANGUAGE RebindableSyntax #-}
module Silly where
import Prelude hiding (negate)
negate :...## Summary
The fancy logic in `-Woverflowed-literals` can be triggered improperly under `RebindableSyntax`.
## Steps to reproduce
```haskell
{-# LANGUAGE RebindableSyntax #-}
module Silly where
import Prelude hiding (negate)
negate :: Word -> Word
negate x = x + 1
foo :: Word
foo = -40
```
```plaintext
dfeuer@squirrel:~/src> ghc -fforce-recomp -Wall Silly
[1 of 1] Compiling Silly ( Silly.hs, Silly.o )Silly.hs:9:8: warning: [GHC-97441] [-Woverflowed-literals]
Literal -40 is out of the Word range 0..18446744073709551615
|
9 | foo = -40
| ^^
```
## Expected behavior
I expect the module to compile with no warnings.
## Discussion
As I understand it, there are three functions potentially involved in literal out of range warnings: `fromInteger`, `fromRational`, and `negate`. I believe that in a module using `RebindableSyntax` we want to modify the warning mechanism under the following circumstances.
1. If the literal is non-negative, or if `NegativeLiterals` is enabled, then we should not get a warning for an integer literal if `fromInteger` is rebound, and we should not get a warning for a rational literal if `fromRational` is rebound.
2. If the literal is negative, `NegativeLiterals` is disabled, and `negate` is rebound, then we should act exactly as though the user had written `negate lit`. That is, the range check should be performed on `lit` (unless the relevant `fromInteger` or `fromRational` is rebound), rather than on `-lit`. That can potentially produce warnings we do not currently produce. For example, if `negate` is rebound but `fromInteger` is not, `-128 :: Int8` should produce a warning, because `128` is out of range for `Int8`.
## Environment
* GHC version used: 9.8.2
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/24576Add a :version command to GHCi2024-03-26T15:22:43ZMinh Thu VoAdd a :version command to GHCi## Summary
Add a `:version` command to GHCi. This would show either the same as `ghc --version`, or the (beginning of the) first output line of GHCi, which is e.g. "GHCi, version 9.11.20240322: https://www.haskell.org/ghc/ :? for help"...## Summary
Add a `:version` command to GHCi. This would show either the same as `ghc --version`, or the (beginning of the) first output line of GHCi, which is e.g. "GHCi, version 9.11.20240322: https://www.haskell.org/ghc/ :? for help".
This command would especially make sense when used while GHCi is started in a quiet mode (e.g. with `-v0`), where such information would not be displayed at startup.
(I guess it would also make sense in the case of a Machine accessible interface to GHCi https://gitlab.haskell.org/ghc/ghc/-/issues/15461, so a controlling client could query such information.)Minh Thu VoMinh Thu Vohttps://gitlab.haskell.org/ghc/ghc/-/issues/24491Add a --test-ways flag to hadrian2024-03-05T14:36:55ZTeo CamarasuAdd a --test-ways flag to hadrianThis is a small idea to improve hadrian. Have a `--test-ways=<way>(,<way>)*` flag that allows specifying multiple ways at the same time rather than having to use several `--test-way=way1 --test-way=way2` options.This is a small idea to improve hadrian. Have a `--test-ways=<way>(,<way>)*` flag that allows specifying multiple ways at the same time rather than having to use several `--test-way=way1 --test-way=way2` options.https://gitlab.haskell.org/ghc/ghc/-/issues/24434Add default QuasiQuoter(s)2024-02-14T19:23:59ZDavid FeuerAdd default QuasiQuoter(s)## Motivation
`Language.Haskell.TH.Quote` gives us
```haskell
data QuasiQuoter = QuasiQuoter {
-- | Quasi-quoter for expressions, invoked by quotes like @lhs = $[q|...]@
quoteExp :: String -> Q Exp,
-- | Quasi-quoter for p...## Motivation
`Language.Haskell.TH.Quote` gives us
```haskell
data QuasiQuoter = QuasiQuoter {
-- | Quasi-quoter for expressions, invoked by quotes like @lhs = $[q|...]@
quoteExp :: String -> Q Exp,
-- | Quasi-quoter for patterns, invoked by quotes like @f $[q|...] = rhs@
quotePat :: String -> Q Pat,
-- | Quasi-quoter for types, invoked by quotes like @f :: $[q|...]@
quoteType :: String -> Q Type,
-- | Quasi-quoter for declarations, invoked by top-level quotes
quoteDec :: String -> Q [Dec]
}
```
The documentation suggests that
> if you are only interested
> in defining a quasiquoter to be used for expressions, you would
> define a 'QuasiQuoter' with only 'quoteExp', and leave the other
> fields stubbed out with errors.
This is not ideal. There are a few problems:
The easiest path, which some packages take, is to write something like
```haskell
myqq = QuasiQuoter
{ quoteExp = ... }
```
The error message produced when `myqq` is used in the wrong context will not explain the problem at all; it'll just point out that there was an exception in Template Haskell code. The second problem is that using `error`, even more informatively, will produce an overly verbose, poorly formatted message because GHC assumes that it represents a bug in the quasiquoter. The correct thing is instead to use `fail` as usual.
## Proposal
I suggest offering one or perhaps a couple of suitable "default" `QuasiQuoter` definitions. These could look like so:
```haskell
defaultQuasiQuoter :: QuasiQuoter
defaultQuasiQuoter = QuasiQuoter
{ quoteExp = \_ -> fail "This quasiquoter is not for use in expressions"
, quoteType = \_ -> fail "This quasiquoter is not for use in types"
, quotePat = \_ -> fail "This quasiquoter is not for use in patterns"
, quoteDec = \_ -> fail "This quasiquoter is not for producing declarations"
}
namedDefaultQuasiQuoter :: String -> QuasiQuoter
namedDefaultQuasiQuoter n = QuasiQuoter
{ quoteExp = \_ -> fail $ "The " ++ n ++ " quasiquoter is not for use in expressions"
, quoteType = \_ -> fail $ "The " ++ n ++ " quasiquoter is not for use in types"
, quotePat = \_ -> fail $ "The " ++ n ++ " quasiquoter is not for use in patterns"
, quoteDec = \_ -> fail $ "The " ++ n ++ " quasiquoter is not for producing declarations"
}
```
Now users can write things like
```haskell
myqq = (namedDefaultQuasiQuoter "myqq")
{ quoteExp = ... }
```
The documentation should also indicate that the unused fields should `fail` rather than `error`.David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24377Wrong type signature for JavaScript asyncCallback in document2024-01-30T15:01:03ZohhoWrong type signature for JavaScript asyncCallback in document## Summary
Location of documentation issue: the GHC user's guide
This line here [1]:
```
* asyncCallback :: (JSVal -> IO ()) -> IO (Callback (JSVal -> IO ()))
```
...should either be:
```
* asyncCallback1 :: (JSVal -> IO ()) -> IO (Cal...## Summary
Location of documentation issue: the GHC user's guide
This line here [1]:
```
* asyncCallback :: (JSVal -> IO ()) -> IO (Callback (JSVal -> IO ()))
```
...should either be:
```
* asyncCallback1 :: (JSVal -> IO ()) -> IO (Callback (JSVal -> IO ()))
```
or:
```
* asyncCallback :: IO () -> IO (Callback (IO ()))
```
...according to [2].
- [[1]](https://gitlab.haskell.org/ghc/ghc/-/blame/master/docs/users_guide/javascript.rst?ref_type=heads#L140) - docs/users_guide/javascript.rst#L140
- [[2]](https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/src/GHC/JS/Foreign/Callback.hs#L116) - libraries/base/src/GHC/JS/Foreign/Callback.hs#L116
## Proposed improvements or changes
Update to the corresponding type signature.
## Environment
* GHC version used (if appropriate): 9.8.1Sylvain HenryLuite StegemanJosh Meredithdoyougnujmy6342@gmail.comSylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/24290cAPI FFI linking issue: Multiple definitions message does not guide towards r...2024-01-10T16:13:18ZHécate MoonlightcAPI FFI linking issue: Multiple definitions message does not guide towards resolutionWhile using CApi I encountered this bug (original report [here](https://github.com/tree-sitter/haskell-tree-sitter/issues/307))
Error message:
```plaintext
Building executable 'capi-linker-error' for capi-linker-error-0.1.0.0...
[2 of ...While using CApi I encountered this bug (original report [here](https://github.com/tree-sitter/haskell-tree-sitter/issues/307))
Error message:
```plaintext
Building executable 'capi-linker-error' for capi-linker-error-0.1.0.0...
[2 of 2] Linking /tmp/capi-linker-error/dist-newstyle/build/x86_64-linux/ghc-9.9.20231111/capi-linker-error-0.1.0.0/x/capi-linker-error/build/capi-linker-error/capi-linker-error
/usr/bin/ld.gold: error: /tmp/capi-linker-error/dist-newstyle/build/x86_64-linux/ghc-9.9.20231111/capi-linker-error-0.1.0.0/x/capi-linker-error/build/capi-linker-error/capi-linker-error-tmp/app/foo.o: multiple definition of 'foo'
/usr/bin/ld.gold: /tmp/capi-linker-error/dist-newstyle/build/x86_64-linux/ghc-9.9.20231111/capi-linker-error-0.1.0.0/x/capi-linker-error/build/capi-linker-error/capi-linker-error-tmp/Main.o: previous definition here
collect2: error: ld returned 1 exit status
ghc-9.9.20231111: `gcc' failed in phase `Linker'. (Exit code: 1)
Error: [Cabal-7125]
Failed to build exe:capi-linker-error from capi-linker-error-0.1.0.0.
```
Minimal reproducer: https://github.com/brcha/capi-linker-error/
Using `foo.h` instead of `foo.c` is the fix, but the error message doesn't reflect this.https://gitlab.haskell.org/ghc/ghc/-/issues/24220hSeek and hTell do unnecessary stat2023-12-16T03:10:01ZNiklas Hambüchenmail@nh2.mehSeek and hTell do unnecessary statIn `base`, [`hTell`](https://hackage.haskell.org/package/base-4.19.0.0/docs/GHC-IO-Handle.html#v:hTell) and [`hSeek`](https://hackage.haskell.org/package/base-4.19.0.0/docs/GHC-IO-Handle.html#v:hSeek) are unnecessarily inefficient.
On L...In `base`, [`hTell`](https://hackage.haskell.org/package/base-4.19.0.0/docs/GHC-IO-Handle.html#v:hTell) and [`hSeek`](https://hackage.haskell.org/package/base-4.19.0.0/docs/GHC-IO-Handle.html#v:hSeek) are unnecessarily inefficient.
On Linux, they _should_ translate to just 1 `lseek()` syscall, but `base` inserts additional `newfstatat()` (type of `stat()`) syscalls in front of each.
This can be observed in `strace` e.g. against `ghci`.
## Repro
```haskell
import System.IO
writeFile "myfile" "" -- just to create the file
f <- openFile "myfile" ReadMode
hTell f
```
Example `strace` output (e.g. `strace -fyp "$(pidof ghc)" -P "myfile"`) for the `hTell` call:
```
newfstatat(12</home/niklas/myfile>, "", {st_mode=S_IFREG|0644, st_size=919, ...}, AT_EMPTY_PATH) = 0
lseek(12</home/niklas/myfile>, 0, SEEK_CUR) = 0
```
(Note in the above that `lseek(..., SEEK_CUR)` is the returns the current seek position instead of setting it, thus implementing `hTell`.)
## Problems
These additionl stat syscalls have various problems:
* Syscall spam: Costs context switches and makes debugging harder in strace.
* Greatly increased latency on networked file systems.
Thus they make IO-based code much slower than in e.g. C or Python.
## Cause
The reason for the additional stats seems to be the "Handle must be seekable" requirement.
Instead of obtaining the information whether a Handle is seekable once, and storing it, `hSeek` and `hTell` obtain this information repeatedly on each call, even though it cannot change in between:
* [`hSeek`](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.IO.Handle.html#hSeek)/[`hTell`](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.IO.Handle.html#hTell) call
* [`wantSeekableHandle`](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.IO.Handle.Internals.html#wantSeekableHandle) which on `FileHandle`s calls
* [`checkSeekableHandle`](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.IO.Handle.Internals.html#checkSeekableHandle) which on non-closed files calls
* `IODevice.isSeekable dev` which for the `instance IODevice FD` [calls](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.IO.FD.html#line-121)
* [`GHC.IO.FD.isSeekable`](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.IO.FD.html#isSeekable) which calls
* [`devType`](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.IO.FD.html#devType) which calls
* [`fdStat`](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/System.Posix.Internals.html#fdStat)
## Solutions
I believe that `devType`, and seekableness, cannot change during the lifetime of an open `FD` or `Handle`.
So the easiest solution would be to store an `isSeekable :: Bool` field in either [`data FD`](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.IO.FD.html#fdFD) next to similar fields
```haskell
data FD = FD {
fdFD :: {-# UNPACK #-} !CInt,
fdIsSocket_ :: {-# UNPACK #-} !Int
fdIsNonBlocking :: {-# UNPACK #-} !Int
}
```
or in [`data Handle__`](https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.IO.Handle.Types.html#Handle__).https://gitlab.haskell.org/ghc/ghc/-/issues/24156Better hadrian error when configure was not run2023-11-14T14:57:10ZKrzysztof GogolewskiBetter hadrian error when configure was not runIf you clone a new repository and run `./hadrian/build`, it says
```
$ ./hadrian/build
Up to date
Error, file does not exist and no rule available:
hadrian/cfg/system.config
Build failed.
```
This message is subpar, it'd be better t...If you clone a new repository and run `./hadrian/build`, it says
```
$ ./hadrian/build
Up to date
Error, file does not exist and no rule available:
hadrian/cfg/system.config
Build failed.
```
This message is subpar, it'd be better to suggest boot + configure.https://gitlab.haskell.org/ghc/ghc/-/issues/24132Add -dno-dump-* flags2024-01-15T01:23:48ZOleg GrenrusAdd -dno-dump-* flagsI often do `-ddump-simpl` and `-ddump-deriv` in GHCi, but apparently there is no way to turn them off?I often do `-ddump-simpl` and `-ddump-deriv` in GHCi, but apparently there is no way to turn them off?https://gitlab.haskell.org/ghc/ghc/-/issues/24081Add cost center pragmas to Template Haskell2024-02-05T17:53:12ZIavor S. DiatchkiAdd cost center pragmas to Template Haskell## Summary
SCC pragmas are not supported by Template Haskell. This make it impossible to properly profile a program, where part of the code is generate
with TH.
## Steps to reproduce
Type `[d| {-# SCC x #-}; x = () |]` in `ghci`
## ...## Summary
SCC pragmas are not supported by Template Haskell. This make it impossible to properly profile a program, where part of the code is generate
with TH.
## Steps to reproduce
Type `[d| {-# SCC x #-}; x = () |]` in `ghci`
## Expected behavior
Generate a splice annotated with an SCC pragma.
## Environment
* GHC version used: 9.6.2
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/24075And support for CLMUL instructions2023-10-10T14:04:58ZOleg GrenrusAnd support for CLMUL instructionshttps://en.wikipedia.org/wiki/CLMUL_instruction_sethttps://en.wikipedia.org/wiki/CLMUL_instruction_sethttps://gitlab.haskell.org/ghc/ghc/-/issues/24051Document Haskell encodings and tricks2023-11-23T17:07:43ZIcelandjackDocument Haskell encodings and tricksThere are a few Haskell tricks that people have defined; that is, using Haskell features in an unusual way to encode functionality.
I am not talking about grand design patterns, but small tricks like:
* Constraint Trick for instances (h...There are a few Haskell tricks that people have defined; that is, using Haskell features in an unusual way to encode functionality.
I am not talking about grand design patterns, but small tricks like:
* Constraint Trick for instances (https://chrisdone.com/posts/haskell-constraint-trick/)
* Quantified Constraint Trick (https://blog.poisson.chat/posts/2022-09-21-quantified-constraint-trick.html)
* Defining a class synonym: `class Old a => New a; instance Old a => New a`.
I wanted to raise the idea of documenting them in the User Guide which can become a central collection to be referenced in conversation or code.https://gitlab.haskell.org/ghc/ghc/-/issues/24040Allow setting timeout in GHCi2024-02-08T10:43:39ZOleg GrenrusAllow setting timeout in GHCiE.g. (timeout in seconds)
```
ghci> :timeout 60
ghci> let x = x in x
GhciTimedOut.
```
this would allow using `ghci` more reliably with scripts, `doctest` etc.E.g. (timeout in seconds)
```
ghci> :timeout 60
ghci> let x = x in x
GhciTimedOut.
```
this would allow using `ghci` more reliably with scripts, `doctest` etc.https://gitlab.haskell.org/ghc/ghc/-/issues/24039Make :doc ModuleName print module docs.2023-12-27T12:44:22ZOleg GrenrusMake :doc ModuleName print module docs.E.g.
```
ghci> :doc Prelude
-- |
-- Module : Prelude
-- Copyright : (c) The University of Glasgow 2001
-- License : BSD-style (see the file libraries/base/LICENSE)
--
-- Maintainer : libraries@haskell.org
-- Stability ...E.g.
```
ghci> :doc Prelude
-- |
-- Module : Prelude
-- Copyright : (c) The University of Glasgow 2001
-- License : BSD-style (see the file libraries/base/LICENSE)
--
-- Maintainer : libraries@haskell.org
-- Stability : stable
-- Portability : portable
--
-- The Prelude: a standard module. The Prelude is imported by default
-- into all Haskell modules unless either there is an explicit import
-- statement for it, or the NoImplicitPrelude extension is enabled.
--
```
as `:doc` prints docstrings as is (which is fine).https://gitlab.haskell.org/ghc/ghc/-/issues/24026Core Lint error with -fdefer-type-errors and bad RULE2023-10-03T14:12:23ZKrzysztof GogolewskiCore Lint error with -fdefer-type-errors and bad RULETo reproduce:
```hs
module T24026 where
{-# RULES "f" forall (x :: Bool). f x = 0 #-}
f :: Int -> Int
f x = 0
```
```
$ ghc -dlint -fdefer-type-errors T24026
[1 of 1] Compiling T24026 ( T24026.hs, T24026.o )
*** Core Lint e...To reproduce:
```hs
module T24026 where
{-# RULES "f" forall (x :: Bool). f x = 0 #-}
f :: Int -> Int
f x = 0
```
```
$ ghc -dlint -fdefer-type-errors T24026
[1 of 1] Compiling T24026 ( T24026.hs, T24026.o )
*** Core Lint errors : in result of Desugar (before optimization) ***
T24026.hs:6:1: warning:
The coercion variable co_awP :: Bool ~# Int
[LclId[CoVarId]]
is out of scope
In the RHS of f :: Int -> Int
In a rule attached to f :: Int -> Int
Substitution: <InScope = {}
IdSubst = []
TvSubst = []
CvSubst = []>
*** Offending Program ***
Rec {
$trModule :: Module
[LclIdX]
$trModule = Module (TrNameS "main"#) (TrNameS "T24026"#)
f :: Int -> Int
[LclIdX,
RULES: "f" forall (x_awv :: Bool).
f (x_awv `cast` (Sub co_awP :: Bool ~R# Int))
= I# 0#]
f = \ (x_awu :: Int) -> I# 0#
end Rec }
````
The RULE has a type error, the coercion `Int ~ Bool` from `-fdefer-type-errors` is not bound.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24013Eliminate stg_decodeStackzh2024-02-11T13:51:21ZBen GamariEliminate stg_decodeStackzh`GHC.Stack.CloneStack.decode` is currently implemented in terms of `stg_decodeStackzh` (defined in `rts/CloneStack.c`). However, this implementation is rather inefficient (allocating an array of boxed `Ptr`s to return to the caller) and ...`GHC.Stack.CloneStack.decode` is currently implemented in terms of `stg_decodeStackzh` (defined in `rts/CloneStack.c`). However, this implementation is rather inefficient (allocating an array of boxed `Ptr`s to return to the caller) and overlaps heavily with the iterator-based stack decoding implementation now provided by `ghc-heap` (see !9514). We should move the stack decoding implementation from `ghc-heap` into `ghc-internal` and reimplement `GHC.Stack.CloneStack.decode` in terms of it.https://gitlab.haskell.org/ghc/ghc/-/issues/23989Encoding intermediate representations as S expressions2023-10-05T16:54:25ZBen GamariEncoding intermediate representations as S expressionsOver dinner @rae and I discussed various things that GHC and OCaml respectively do well. One of the items he reported in the latter category is OCaml's use of S expressions to represent the compiler's intermediate representations, e.g., ...Over dinner @rae and I discussed various things that GHC and OCaml respectively do well. One of the items he reported in the latter category is OCaml's use of S expressions to represent the compiler's intermediate representations, e.g., for use in testing.
As I understand it, using a generic grammar like S expressions to represent syntax trees carries a number of advantages:
* Much of complexity of writing/maintaing a textual parser can be pushed into a generic, reusable S expression parser; one merely needs to write an isomorphism between the S expression syntax and the various intermediate representations
* crude automated formatting is fairly easy, meaning that the syntax can be strongly normalizing (which is important for test output)
* automated refactoring of S expressions is quite straightforward, meaning that it becomes much less painful to adapt tests when the underlying IR inevitably changes
* it is easy to write traversals of S expressions; one can imagine having a small DSL for inspecting and asserting properties about an sexpr which could be used by tests instead of the current `awk`/`sed`/`grep` usage
One could imagine applying this idea in Core, STG, and Cmm, opening new avenues to targetted testing of GHC's various pipeline stages.Alexandre Garcia de OliveiraAlexandre Garcia de Oliveirahttps://gitlab.haskell.org/ghc/ghc/-/issues/23946When printing type signatures of types, GHC always prints ASCII double semico...2024-02-28T13:28:34ZkindaroWhen printing type signatures of types, GHC always prints ASCII double semicolon and never prints Unicode proportion symbol.## Summary
I have the setting `-fprint-unicode-syntax` switched on. However, GHC still prints type signatures of types with the ASCII double semicolon. It would print Unicode stars `★` and Unicode arrows `→` on the same very line, so th...## Summary
I have the setting `-fprint-unicode-syntax` switched on. However, GHC still prints type signatures of types with the ASCII double semicolon. It would print Unicode stars `★` and Unicode arrows `→` on the same very line, so this is specific to the double semicolon.
## Steps to reproduce
Start `ghci` and type `:set -fprint-unicode-syntax` then `:info IO`. You shall see:
```
λ :info IO
type IO :: ★ → ★
…
```
_(ellipsis mine)_
This is wrong!
## Expected behavior
```
λ :info IO
type IO ∷ ★ → ★
…
```
_(ellipsis mine)_
## Environment
* GHC version used: 9.2.8, 9.6.2.
Optional:
* Operating System: Linux
* System Architecture: `x86_64`https://gitlab.haskell.org/ghc/ghc/-/issues/23846Print diagnostic code in tc-trace "adding diagnostic"2023-08-22T15:03:36Zsheafsam.derbyshire@gmail.comPrint diagnostic code in tc-trace "adding diagnostic"Currently, the `tc-trace` dump includes a message when adding a diagnostic, e.g.
```
Adding diagnostic:
Foo.hs:9:1: warning: Orphan instance: instance C A
```
It would be helpful to include the diagnostic code in this logging message...Currently, the `tc-trace` dump includes a message when adding a diagnostic, e.g.
```
Adding diagnostic:
Foo.hs:9:1: warning: Orphan instance: instance C A
```
It would be helpful to include the diagnostic code in this logging message, which would facilitate looking up the error constructor when working on the compiler.https://gitlab.haskell.org/ghc/ghc/-/issues/23817Improve the reporting of an ambiguous ErrorMessage2023-08-15T13:33:00Zsheafsam.derbyshire@gmail.comImprove the reporting of an ambiguous ErrorMessageWhen there is an ambiguous error message, e.g.
```haskell
-- Example using TypeError
type family F msg where { F msg = TypeError msg }
foo :: F msg => ()
foo = ()
bar = foo
--------------------
-- Example using Unsatisfiable
baz :: ()
...When there is an ambiguous error message, e.g.
```haskell
-- Example using TypeError
type family F msg where { F msg = TypeError msg }
foo :: F msg => ()
foo = ()
bar = foo
--------------------
-- Example using Unsatisfiable
baz :: ()
baz = unsatisfiable
```
We get an error message that looks like
```
error: [GHC-22250]
- msg0
```
with the ambiguous metavariable `msg0` appearing in the message.
We might instead want to default this metavariable to get a more sensible error message. cc @adamgundry who observed this.
This wouldn't handle all situations, e.g.
```haskell
type family F ty where { F ty = TypeError ( Text "Message header" :$$: ShowType ty ) }
foo' :: F ty => ()
foo' = ()
bar' = foo'
```
```
error:
* Message header
ty0
```
and now `ty0 :: Type` which we don't really have a good way of defaulting. But perhaps that's OK.
Another alternative would be to avoid reporting it using the usual mechanism entirely, as @monoidal suggests in https://gitlab.haskell.org/ghc/ghc/-/issues/23817#note_520095.