GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-09-09T14:49:56Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/22103Able to add bogus HasCallStack constraint to instance methods with InstanceSigs2022-09-09T14:49:56ZLas SafinAble to add bogus HasCallStack constraint to instance methods with InstanceSigs## Summary
You can use incorrectly add HasCallStack constraints to signatures in instances.
Thanks to MangoIV for finding this issue.
## Steps to reproduce
```haskell
import Data.Kind (Type)
import GHC.Stack (HasCallStack, prettyCall...## Summary
You can use incorrectly add HasCallStack constraints to signatures in instances.
Thanks to MangoIV for finding this issue.
## Steps to reproduce
```haskell
import Data.Kind (Type)
import GHC.Stack (HasCallStack, prettyCallStack, callStack)
class C (a :: Type) where
cj :: a -> String
instance C () where
cj :: HasCallStack => () -> String
cj _ = prettyCallStack callStack
f :: String
f = cj () -- equal to ""
```
## Expected behavior
This should err.
## Environment
* GHC version used: 9.2.4sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/22087HasCallStack SrcLoc doesn't include function name.2022-08-23T16:14:31ZLas SafinHasCallStack SrcLoc doesn't include function name.## Motivation
[`SrcLoc`](https://hackage.haskell.org/package/base-4.16.0.0/docs/GHC-Stack.html#t:SrcLoc) tells you where in a file
you were called, but not _what_ was calling you. This is quite useful information, since very often, the ...## Motivation
[`SrcLoc`](https://hackage.haskell.org/package/base-4.16.0.0/docs/GHC-Stack.html#t:SrcLoc) tells you where in a file
you were called, but not _what_ was calling you. This is quite useful information, since very often, the `CallStack` is only one level deep.
You can after all get the function name for the first n-1 levels if you have n levels of stack information.
## Proposal
Add `srcLocDefName` field or similar.
An alternative solution is to add another level of callstack information with the name
of the calling function. the `SrcLoc` would however be bogus.https://gitlab.haskell.org/ghc/ghc/-/issues/22086HasCallStack doesn't work with QualifiedDo or RebindableSyntax2024-02-13T01:53:26ZLas SafinHasCallStack doesn't work with QualifiedDo or RebindableSyntax## Summary
`>>` and such called by `QualifiedDo` aren't given callstacks.
## Steps to reproduce
```haskell
module Do ((Do.>>)) where
import GHC.Stack (HasCallStack, callStack, prettyCallStack)
(>>) :: HasCallStack => String -> S...## Summary
`>>` and such called by `QualifiedDo` aren't given callstacks.
## Steps to reproduce
```haskell
module Do ((Do.>>)) where
import GHC.Stack (HasCallStack, callStack, prettyCallStack)
(>>) :: HasCallStack => String -> String -> String
_ >> _ = prettyCallStack callStack
module Main where
import qualified Do
x :: String
x = Do.do
"ddd"
"fff"
y :: String
y = "ddd" Do.>> "fff"
```
`y` and `x` are **not** equal, which is a bug.
The same also happens without `QualifiedDo` and with `RebindableSyntax` instead.
## Expected behavior
`x` and `y` should be equal, modulo the src loc in the callstack.
## Environment
* GHC version used: 9.2.4https://gitlab.haskell.org/ghc/ghc/-/issues/20971Attach arbitrary data to CallStack2022-02-28T14:37:09ZJoachim Breitnermail@joachim-breitner.deAttach arbitrary data to CallStackSometimes I would love to have a function
```
pushCallStackAnnotation :: String -> CallStack -> CallStack
```
that pushes arbitrary extra information to the `CallStack` (e.g. the value of some parameter).
The impact would be some brea...Sometimes I would love to have a function
```
pushCallStackAnnotation :: String -> CallStack -> CallStack
```
that pushes arbitrary extra information to the `CallStack` (e.g. the value of some parameter).
The impact would be some breaking changes around `CallStack` (because it wouldn’t be a `[(String, SrcLoc)]` anymore), and in a way it’s a dangerous feature, because if overused it might cause programs to keep more data alive than expected. But in some cases it could really help with debugging, I expect.https://gitlab.haskell.org/ghc/ghc/-/issues/20834Binary sizes have gone up2021-12-23T20:09:12ZSimon Peyton JonesBinary sizes have gone upSome time between 10 Dec and 16 Dec, binary sizes have increased. Here is a nofib comparison between the two.
Some binary sizes go up by 5%!
* I looked at one module: `real/fem/Assemble_stiffness`. That module's binary goes up by 20...Some time between 10 Dec and 16 Dec, binary sizes have increased. Here is a nofib comparison between the two.
Some binary sizes go up by 5%!
* I looked at one module: `real/fem/Assemble_stiffness`. That module's binary goes up by 20%. It turned out to be entirely due to calls to `(!!)` which now take a `CallStack` argument.
* Ditto `real/hidden/Hide.hs` whose compiled code gets 20% bigger. Here the culprit is the `CallStack` argument to `minimum`.
The culprit is probably
```
commit 31bf380f3925d72a3369978d28d02aaae31f75ef
Author: Oleg Grenrus <oleg.grenrus@iki.fi>
Date: Wed May 26 05:03:52 2021 +0300
Use HasCallStack and error in GHC.List and .NonEmpty
In addition to providing stack traces, the scary HasCallStack will
hopefully make people think whether they want to use these functions,
i.e. act as a documentation hint that something weird might happen.
A single metric increased, which doesn't visibly
use any method with `HasCallStack`.
```
What is surprising is that **every binary goes up by 0.5%**. Why is that? Maybe the standard libraries somehow get bigger?
Half a percent may not seem much, but it's a tax we are paying for every single binary, forever. Yet this patch is only supposed to penalise code that uses these naughty functions.
```
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
CS +0.7% -0.0% 0.120 0.120 0.0%
CSD +0.7% -0.0% -4.6% -4.6% 0.0%
FS +0.7% -0.0% -5.1% -5.1% 0.0%
S +0.7% -0.0% -4.7% -4.7% 0.0%
VS +0.7% -0.0% -2.0% -2.1% 0.0%
VSD +0.7% -0.3% 0.010 0.010 0.0%
VSM +0.7% -0.0% 0.145 0.145 0.0%
anna +0.8% +0.0% -6.2% -6.2% 0.0%
ansi +0.7% -0.0% +0.4% +0.4% 0.0%
atom +0.6% 0.0% -0.1% -0.1% 0.0%
awards +0.6% -0.0% +1.6% +1.6% 0.0%
banner +5.6% -0.1% +5.3% +5.4% 0.0%
ben-raytrace ----- ----- ----- ----- -----
bernouilli +0.7% -0.0% -20.8% -20.8% 0.0%
binary-trees +0.6% -0.0% -4.0% -4.0% 0.0%
boyer +0.6% -0.0% -1.7% -1.7% 0.0%
boyer2 +0.6% -0.0% +2.2% +2.1% 0.0%
bspt +0.6% -0.0% -6.2% -6.1% 0.0%
cacheprof +5.4% 0.0% -6.7% -6.7% 0.0%
calendar +5.5% +0.6% +3.9% +3.9% 0.0%
cichelli +0.7% -0.0% -1.2% -1.2% 0.0%
circsim +0.7% -0.0% +0.5% +0.5% 0.0%
clausify +0.6% -0.0% -0.1% -0.1% 0.0%
comp_lab_zift +0.7% -0.0% -10.1% -10.1% 0.0%
compress +0.7% -0.0% -6.4% -6.5% 0.0%
compress2 +0.6% -0.0% -7.2% -7.2% 0.0%
constraints +0.7% -0.0% +0.8% +0.7% 0.0%
cryptarithm1 +0.6% 0.0% +0.7% +0.7% 0.0%
cryptarithm2 +0.6% -0.0% +1.0% +1.1% 0.0%
cse +5.5% 0.0% -2.8% -2.8% 0.0%
digits-of-e1 +0.6% -0.0% -10.0% -10.0% 0.0%
digits-of-e2 +0.7% -0.0% -7.7% -7.8% 0.0%
dom-lt +0.5% -0.0% -0.4% -0.4% 0.0%
eliza +0.7% -0.0% -4.5% -4.5% 0.0%
event +0.7% -12.0% -4.9% -4.9% 0.0%
exact-reals +0.7% -0.0% +2.1% +2.1% 0.0%
exp3_8 +0.6% -0.0% -11.2% -11.2% 0.0%
expert +5.6% -0.0% -0.2% -0.2% 0.0%
fannkuch-redux +0.7% -0.2% -2.7% -2.7% 0.0%
fasta +0.6% 0.0% -6.0% -5.7% 0.0%
fem +0.7% -2.8% -9.6% -9.7% 0.0%
fft +0.7% -0.0% -6.7% -6.7% 0.0%
fft2 +0.7% -0.2% +1.3% +1.3% 0.0%
fibheaps +0.6% 0.0% -3.2% -3.1% 0.0%
fish +0.6% 0.0% -11.8% -11.8% 0.0%
fluid +5.4% -0.0% -11.8% -11.8% 0.0%
fulsom +0.6% -0.0% -10.9% -10.9% 0.0%
gamteb +0.6% -0.0% -8.5% -8.5% 0.0%
gcd +0.7% -0.0% -7.6% -7.6% 0.0%
gen_regexps +0.7% -0.0% -4.7% -4.7% 0.0%
genfft +0.6% -0.0% -0.4% -0.4% 0.0%
gg +0.7% -0.0% -7.1% -7.1% 0.0%
grep +0.7% -0.0% -6.3% -6.3% 0.0%
hidden +5.6% 0.0% -10.9% -10.8% 0.0%
hpg +5.4% -0.1% -4.9% -4.9% 0.0%
ida +0.7% -0.0% -0.9% -0.9% 0.0%
infer +0.6% -0.0% -9.0% -9.0% 0.0%
integer +0.6% 0.0% -3.4% -3.4% 0.0%
integrate +0.7% (stdout) (stdout) (stdout) (stdout)
k-nucleotide +0.6% -0.0% +7.0% +7.0% 0.0%
kahan +0.7% 0.0% -0.3% -0.3% 0.0%
knights +0.7% -0.0% -5.0% -5.0% 0.0%
lambda +0.7% -0.0% -6.5% -6.4% 0.0%
last-piece +0.7% -0.0% -6.3% -6.3% 0.0%
lcss +0.6% -0.0% -7.9% -7.8% 0.0%
life +0.7% -0.0% -5.2% -5.2% 0.0%
lift +0.7% -0.0% -5.9% -5.9% 0.0%
linear +5.6% -0.1% -1.7% -1.7% 0.0%
listcompr +0.7% -0.0% -5.4% -5.4% 0.0%
listcopy +0.7% -0.0% -8.2% -8.2% 0.0%
maillist +0.7% -0.2% -6.3% -6.0% 0.0%
mandel +0.7% 0.0% -3.8% -3.8% 0.0%
mandel2 +0.6% 0.0% -2.6% -2.6% 0.0%
mate +0.7% -0.0% -8.7% -8.7% 0.0%
minimax +0.7% 0.0% -6.1% -6.1% 0.0%
mkhprog +0.7% 0.0% +5.2% +5.1% 0.0%
multiplier +0.7% -0.0% -7.2% -7.2% 0.0%
n-body +0.7% -0.1% -2.4% -2.4% 0.0%
nucleic2 +5.5% 0.0% -8.0% -8.0% 0.0%
para +0.7% 0.0% -2.7% -2.6% 0.0%
paraffins +0.6% -0.0% -8.6% -8.6% 0.0%
parser +0.7% -0.0% -4.4% -4.3% 0.0%
parstof +0.6% -0.0% -6.5% -6.3% 0.0%
pic +0.6% 0.0% -5.4% -5.4% 0.0%
pidigits +0.7% 0.0% -4.1% -4.0% 0.0%
power +0.6% 0.0% -10.6% -10.6% 0.0%
pretty +0.7% -0.2% 0.000 0.000 0.0%
primes +0.7% -0.0% -24.2% -24.2% 0.0%
primetest +0.6% -0.0% -6.2% -6.2% 0.0%
prolog +5.5% -0.0% -5.6% -5.6% 0.0%
puzzle +0.6% 0.0% -6.3% -6.3% 0.0%
queens +0.6% -0.0% +0.5% +0.5% 0.0%
reptile +0.6% -0.0% -6.0% -6.0% 0.0%
reverse-complem +0.6% 0.0% -4.7% -4.4% 0.0%
rewrite +0.7% -0.0% -9.7% -9.7% 0.0%
rfib +0.7% -0.1% -0.1% -0.1% 0.0%
rsa +0.7% -0.0% -4.9% -4.9% 0.0%
scc +0.7% -0.2% 0.000 0.000 0.0%
sched +0.6% -0.0% -8.9% -8.9% 0.0%
scs +5.4% +0.0% -5.8% -5.8% 0.0%
simple +0.6% 0.0% -7.3% -7.3% 0.0%
smallpt ----- ----- ----- ----- -----
solid +0.7% -0.0% -6.3% -6.3% 0.0%
sorting +0.6% -0.0% -6.1% -6.1% 0.0%
spectral-norm +0.7% -0.0% -4.8% -4.8% 0.0%
sphere +0.7% -0.0% -3.6% -3.6% 0.0%
symalg +0.6% -0.0% -4.4% -4.3% 0.0%
tak +0.7% -0.1% +1.4% +1.4% 0.0%
transform +0.7% 0.0% -7.3% -7.3% 0.0%
treejoin +0.6% -0.0% -9.6% -9.6% 0.0%
typecheck +0.7% 0.0% -2.6% -2.6% 0.0%
veritas +5.2% -0.0% -7.8% -7.8% 0.0%
wang +0.7% -0.0% -8.6% -8.6% 0.0%
wave4main +0.6% -0.0% -4.4% -4.3% 0.0%
wheel-sieve1 +0.7% -0.0% -6.9% -6.9% 0.0%
wheel-sieve2 +0.7% -0.0% +2.4% +2.6% 0.0%
x2n1 +0.7% -0.3% +5.4% +5.4% 0.0%
--------------------------------------------------------------------------------
Min +0.5% -12.0% -24.2% -24.2% 0.0%
Max +5.6% +0.6% +7.0% +7.0% 0.0%
Geometric Mean +1.2% -0.2% -4.8% -4.8% -0.0%
```https://gitlab.haskell.org/ghc/ghc/-/issues/20103Eta expansion and HasCallStack2021-07-27T16:24:17ZSimon Peyton JonesEta expansion and HasCallStackLook at these two programs, discovered in #20097:
One using `HasCallStack`
```haskell
module Main where
import GHC.Stack
foo :: HasCallStack => Int -> Int
foo 0 = length . fst . head $ getCallStack callStack
foo n = foo (n-1)
main :...Look at these two programs, discovered in #20097:
One using `HasCallStack`
```haskell
module Main where
import GHC.Stack
foo :: HasCallStack => Int -> Int
foo 0 = length . fst . head $ getCallStack callStack
foo n = foo (n-1)
main :: IO ()
main = print (foo 500000)
```
One using implicit parameters
```haskell
{-# LANGUAGE ImplicitParams #-}
module Main where
type Stack = [(String, Bool)]
foo :: (?stk::Stack) => Int -> Int
foo 0 = length . fst . head $ ?stk
foo n =
let ?stk = ("foo", True) : ?stk
in foo (n-1)
main :: IO ()
main = let ?stk = [] in print (foo 500000)
```
The implicit parameter version generates an arity-2 `foo`. But the former generates an arity-1 `foo` which is much less efficent.
<details>
<summary>Specifics here:</summary>
```
Rec {
-- RHS size: {terms: 68, types: 49, coercions: 14, joins: 0/2}
foo [Occ=LoopBreaker] :: HasCallStack => Int -> Int
[GblId, Arity=1, Unf=OtherCon []]
foo
= \ ($dIP_a15z :: HasCallStack) ->
let {
$dIP1_s1ft :: CallStack
[LclId]
$dIP1_s1ft
= pushCallStack
(GHC.CString.unpackCString# "foo"#,
GHC.Stack.Types.SrcLoc
(GHC.CString.unpackCString# "main"#)
(GHC.CString.unpackCString# "Main"#)
(GHC.CString.unpackCString# "T20097.hs"#)
(GHC.Types.I# 7#)
(GHC.Types.I# 9#)
(GHC.Types.I# 7#)
(GHC.Types.I# 12#))
($dIP_a15z
`cast` (GHC.Classes.N:IP[0] <"callStack">_N <CallStack>_N
:: (?callStack::CallStack) ~R# CallStack)) } in
let {
$dIP2_s1fu :: CallStack
[LclId]
$dIP2_s1fu
= pushCallStack
(GHC.CString.unpackCString# "callStack"#,
GHC.Stack.Types.SrcLoc
(GHC.CString.unpackCString# "main"#)
(GHC.CString.unpackCString# "Main"#)
(GHC.CString.unpackCString# "T20097.hs"#)
(GHC.Types.I# 6#)
(GHC.Types.I# 44#)
(GHC.Types.I# 6#)
(GHC.Types.I# 53#))
($dIP_a15z
`cast` (GHC.Classes.N:IP[0] <"callStack">_N <CallStack>_N
:: (?callStack::CallStack) ~R# CallStack)) } in
\ (ds_d1fl :: Int) ->
case ds_d1fl of wild_X1E { GHC.Types.I# ds1_d1fo ->
case ds1_d1fo of {
__DEFAULT ->
foo
($dIP1_s1ft
`cast` (Sym (GHC.Classes.N:IP[0] <"callStack">_N <CallStack>_N)
:: CallStack ~R# (?callStack::CallStack)))
(- @Int GHC.Num.$fNumInt wild_X1E (GHC.Types.I# 1#));
0# ->
$ @GHC.Types.LiftedRep
@[([Char], SrcLoc)]
@Int
(. @[Char]
@Int
@[([Char], SrcLoc)]
(length @[] Data.Foldable.$fFoldable[] @Char)
(. @([Char], SrcLoc)
@[Char]
@[([Char], SrcLoc)]
(fst @[Char] @SrcLoc)
(head @([Char], SrcLoc))))
(getCallStack
(callStack
($dIP2_s1fu
`cast` (Sym (GHC.Classes.N:IP[0] <"callStack">_N <CallStack>_N)
:: CallStack ~R# (?callStack::CallStack)))))
}
}
end Rec }
```
</details>
The two lambdas are separated. They really should not be, because this imposes a
performance cost from the `HaskCallStack` constraint that is, I think, unnecessary.
Somehow, we should generate an arity-2 `foo`, even with the `HasCallStack` constraint.https://gitlab.haskell.org/ghc/ghc/-/issues/20097HasCallStack consumes stack space unnecessarily2021-07-16T08:03:44ZZiyang Liuunsafefixio@gmail.comHasCallStack consumes stack space unnecessarily## Summary
The first code snippet below crashes with stack overflow when running with `+RTS -K1M -RTS`. This doesn't seem right since nothing here should consume any stack space. Indeed, if I replace the call stack with a list (second c...## Summary
The first code snippet below crashes with stack overflow when running with `+RTS -K1M -RTS`. This doesn't seem right since nothing here should consume any stack space. Indeed, if I replace the call stack with a list (second code snippet), then it doesn't crash.
## Steps to reproduce
Overflows the stack:
```haskell
module Main where
import GHC.Stack
foo :: HasCallStack => Int -> Int
foo 0 = length . fst . head $ getCallStack callStack
foo n = foo (n-1)
main :: IO ()
main = print (foo 500000)
```
Does not overflow the stack:
```haskell
{-# LANGUAGE ImplicitParams #-}
module Main where
type Stack = [(String, Bool)]
foo :: (?stk::Stack) => Int -> Int
foo 0 = length . fst . head $ ?stk
foo n =
let ?stk = ("foo", True) : ?stk
in foo (n-1)
main :: IO ()
main = let ?stk = [] in print (foo 500000)
```
## Environment
* GHC version used: 8.10.4, 9.0.1
Optional:
* Operating System: Ubuntu 21.04
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/19236callStack produces call-stacks with duplicated backslashes on Windows when us...2022-05-10T09:39:38ZSimon Hengelsol@typeful.netcallStack produces call-stacks with duplicated backslashes on Windows when used with -XCPP## Summary
`callStack` produces call-stacks with duplicated backslashes on Windows when used with `-XCPP`.
## Steps to reproduce
Given a source file `src/Main.hs`
```haskell
module Main where
import GHC.Stack
main :: IO ()
main = p...## Summary
`callStack` produces call-stacks with duplicated backslashes on Windows when used with `-XCPP`.
## Steps to reproduce
Given a source file `src/Main.hs`
```haskell
module Main where
import GHC.Stack
main :: IO ()
main = putStrLn $ prettyCallStack foo
foo :: HasCallStack => CallStack
foo = callStack
```
run
```bash
$ runhaskell src/Main.hs
CallStack (from HasCallStack):
foo, called at src\Main.hs:6:35 in main:Main
$ runhaskell -XCPP src/Main.hs
CallStack (from HasCallStack):
foo, called at src\\Main.hs:6:35 in main:Main
```
(GitHub Action that reproduces the bug: https://github.com/sol/ghc-windows-call-stack-bug/runs/1728925783?check_suite_focus=true#step:3:10)
## Expected behavior
The output of `runhaskell -XCPP src/Main.hs` should include `src\Main.hs` instead of `src\\Main.hs`.
## Environment
* GHC version used: 7.10.3
* Operating System: Windows
* System Architecture: x64https://gitlab.haskell.org/ghc/ghc/-/issues/17040Proposal: add HasCallStack for all partial functions2021-12-09T14:57:56ZLuo ChenProposal: add HasCallStack for all partial functionsMotivation
----------
Partial functions in base (especially Prelude) often cause runtime errors and is hard to locate.
For example, consider the following piece of code:
```
import GHC.Stack
foo :: HasCallStack => [Int] -> Int
foo xs...Motivation
----------
Partial functions in base (especially Prelude) often cause runtime errors and is hard to locate.
For example, consider the following piece of code:
```
import GHC.Stack
foo :: HasCallStack => [Int] -> Int
foo xs = last xs + 1
xs :: [Int]
xs = []
main :: IO ()
main = do
print $ foo xs
```
In this case, the error message will tell nothing about `foo`, and the `HasCallStack` constraint is totally helpless, because the call stack is cut off by the call to `last` which without `HasCallStack` constraint.
My current workaround is define my own wrapper functions with `HasCallStack` constraint for some mostly used partial functions to make them traceable, and use the wrapper (the traceable version) whenever I need them.
e.g.
```
last' :: HasCallStack => [a] -> a
last' xs = case xs of [] -> error "abuse last"; _ -> last xs
```
So, IMHO, if our goal is to make errors in haskell traceable, then **only providing `HasCallStack` mechanism is not enough, we have to provide traceable base package at the same time**.
Further more, all untraceable partial functions are considered to be harmful, and should not be exported by any package. Because an improper call to an untraceable partial function will cut off the call stack ([here is a demonstration about that](https://gist.github.com/luochen1990/94179a2492ff7d1ca45153645f1bb449)).
On the other hand, it is never necessary for us to add `HasCallStack` for a total function, so I suggest that we add `HasCallStack` constraint for (and only for) partial functions, and IMHO this could be a good balance for better debugging experience and less runtime overhead.
Proposal
--------
1. add `HasCallStack` constraint for all partial functions in base package
2. suggest all package maintainers to add `HasCallStack` constraint for their exported partial functions
3. provide a compiler option like `-fignore-hascallstack` to toggle off the effect of `HasCallStack` constraint in case somebody need best performance
Other Considerations
--------------------
### Why not just use `-xc` to get a stacktrace?
There is indeed some differences between the two stack tracing solutions:
1. The stack trace generated by `-xc` contains no line number and column number of the call site.
2. When we run a long running program, such as a web service, it is not easy to reproduce the issue, most of the time, you have no chance to recompile or restart your program to debug, all you can rely on is the printed logs, this makes `-xc` not as useful as `HasCallStack`.
3. The `HasCallStack` solution is much more friendly for learners, you don't need to know any tricks to get a stack trace printed, this reason seems ridiculous but IMHO it indeed affects the learning curve of Haskell.
### Is it a consistent design?
Some people may feel it weird if we just add `HasCallStack` for some functions but not the others, but I think it is consistent since we have a concrete rule to decide whether we need to add `HasCallStack` for a function -- by it's totality.
### What about the performance issue?
I think we need a benchmark test before we weigh up the advantages and the disadvantages. It would be good news if there are some available testsuites for this purpose.
Related Works
-------------
- [The callstack is already added for Data.Maybe.fromJust before this proposal](https://gitlab.haskell.org/ghc/ghc/commit/614028e3b02a5b71a9fbf9c7028f270760ccdab2)
- [An immature post about the same topic](https://gitlab.haskell.org/ghc/ghc/issues/16760)
- [A post on the mail list about the same topic](https://mail.haskell.org/pipermail/libraries/2019-June/thread.html#29652)