How do I use CallStack?

Richard Eisenberg

6 Dec 2015 6 Dec '15

11:43 p.m.

Hi devs, I wish to use the new CallStack feature to track call sites of a function. I want my function to print out where it was called from. I do not want to call `error`. How do I do this? I looked in the release notes. They describe the CallStack feature at an overview, and the docs suggest that it has a Show instance. But the notes don't say where to import CallStack from. I found it in GHC.Stack, but I'm unsure this is the right place to take it from. The GHC release notes also refer me to the ghc-prim release notes. These (which I assume are ghc-prim/changelog.md) don't discuss CallStack. In any case, when I try to `show ?callstack`, I learn that CallStack is not an instance of Show, or I somehow haven't imported the instance. Help? Thanks! Richard

Show replies by date

Levent Erkok

6 Dec 6 Dec

11:48 p.m.

There's a function for that: https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html#v:showC... On Sun, Dec 6, 2015 at 8:43 PM, Richard Eisenberg wrote:

...

Hi devs,

I wish to use the new CallStack feature to track call sites of a function. I want my function to print out where it was called from. I do not want to call `error`. How do I do this?

I looked in the release notes. They describe the CallStack feature at an overview, and the docs suggest that it has a Show instance. But the notes don't say where to import CallStack from. I found it in GHC.Stack, but I'm unsure this is the right place to take it from. The GHC release notes also refer me to the ghc-prim release notes. These (which I assume are ghc-prim/ changelog.md) don't discuss CallStack. In any case, when I try to `show ?callstack`, I learn that CallStack is not an instance of Show, or I somehow haven't imported the instance.

Help?

Thanks! Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Richard Eisenberg

11:56 p.m.

That looks like exactly what I want. Thanks. There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9. - That function seems missing in HEAD. Or maybe it moved. A little searching says it *did* move, to GHC.Exception. Well, my problem is solved. But I think the documentation needs a pass here. And is there a reason not to have a Show instance? Thanks! Richard On Dec 6, 2015, at 11:48 PM, Levent Erkok wrote:

...

There's a function for that: https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html#v:showC...

On Sun, Dec 6, 2015 at 8:43 PM, Richard Eisenberg wrote: Hi devs,

I wish to use the new CallStack feature to track call sites of a function. I want my function to print out where it was called from. I do not want to call `error`. How do I do this?

I looked in the release notes. They describe the CallStack feature at an overview, and the docs suggest that it has a Show instance. But the notes don't say where to import CallStack from. I found it in GHC.Stack, but I'm unsure this is the right place to take it from. The GHC release notes also refer me to the ghc-prim release notes. These (which I assume are ghc-prim/changelog.md) don't discuss CallStack. In any case, when I try to `show ?callstack`, I learn that CallStack is not an instance of Show, or I somehow haven't imported the instance.

Help?

Thanks! Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Evan Laforge

7 Dec 7 Dec

12:15 a.m.

Also, a call stack frame is just a (name, srcloc) pair, so you can format it yourself. I use: show_stack :: CallStack -> String show_stack = maybe "<empty-stack>" show_frame . Seq.last . Stack.getCallStack where show_frame (name, srcloc) = SrcLoc.srcLocFile srcloc ++ ":" ++ show (SrcLoc.srcLocStartLine srcloc) ++ " [" ++ name ++ "]" On Sun, Dec 6, 2015 at 8:56 PM, Richard Eisenberg wrote:

...

That looks like exactly what I want. Thanks.

There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9.

I've been using it since 7.10, with base 4.8. There's also a back port to 7.8, but it's not in the official distribution.

Reid Barton

12:51 a.m.

On Sun, Dec 6, 2015 at 11:56 PM, Richard Eisenberg wrote:

...

That looks like exactly what I want. Thanks.

There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9.

Somehow some CallStack-related things snuck in between 7.10.1 and 7.10.2. Compare https://hackage.haskell.org/package/base-4.8.0.0/docs/GHC-Stack.html and https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html. Regards, Reid Barton

Eric Seidel

1:39 a.m.

Hi Richard, Sorry for all of the confusion, it seems the docs do indeed need some love! On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:

...

That looks like exactly what I want. Thanks.

There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9.

They were originally merged into 7.11, but were backported to the official 7.10.2 release due to popular demand. It appears the @since annotation wasn't updated correspondingly.

...

- That function seems missing in HEAD. Or maybe it moved. A little searching says it *did* move, to GHC.Exception.

In HEAD we are now using CallStacks for error and undefined, which was not the case for the 7.10.2 release. This means the type needs to be defined much earlier in base, before we even have enough functionality to write a sensible formatter. showCallStack currently lives in GHC.Exception because that's where it's used, but that's not a good reason... I'll take another look at moving it back to GHC.Stack.

...

Well, my problem is solved. But I think the documentation needs a pass here. And is there a reason not to have a Show instance?

I usually only use compiler-derived Show instances so that Read automatically works, as well as some nice formatting libraries like http://hackage.haskell.org/package/pretty-show for debugging. For pretty-printing like showCallStack I prefer a standalone function or a separate type-class. If the name "showCallStack" suggests the compiler-derived output, we could change it to something like "prettyCallStack" or "formatCallStack", I don't have a strong opinion there. Thanks for the comments! Eric

Bartosz Nitka

5:45 a.m.

If you're debugging GHC, I've recently added pprSTrace :: (?location :: CallStack) => SDoc -> a -> a in Outputable. It's been a great help for me in understanding where the calls were coming from. You can just use it without importing anything extra, and when you want more context you just add (?location :: CallStack) => to the function you're debugging, plus necessary imports (GHC.Stack) and extensions (ImplicitParams). I think it improved my workflow by an order of magnitude. 2015-12-07 6:39 GMT+00:00 Eric Seidel :

...

Hi Richard,

Sorry for all of the confusion, it seems the docs do indeed need some love!

On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:

...
That looks like exactly what I want. Thanks.

There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9.

They were originally merged into 7.11, but were backported to the official 7.10.2 release due to popular demand. It appears the @since annotation wasn't updated correspondingly.

...
- That function seems missing in HEAD. Or maybe it moved. A little searching says it *did* move, to GHC.Exception.

In HEAD we are now using CallStacks for error and undefined, which was not the case for the 7.10.2 release. This means the type needs to be defined much earlier in base, before we even have enough functionality to write a sensible formatter. showCallStack currently lives in GHC.Exception because that's where it's used, but that's not a good reason... I'll take another look at moving it back to GHC.Stack.

...
Well, my problem is solved. But I think the documentation needs a pass here. And is there a reason not to have a Show instance?

I usually only use compiler-derived Show instances so that Read automatically works, as well as some nice formatting libraries like http://hackage.haskell.org/package/pretty-show for debugging. For pretty-printing like showCallStack I prefer a standalone function or a separate type-class.

If the name "showCallStack" suggests the compiler-derived output, we could change it to something like "prettyCallStack" or "formatCallStack", I don't have a strong opinion there.

Thanks for the comments! Eric _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ben Gamari

5:59 a.m.

Eric Seidel writes:

...

Hi Richard,

Sorry for all of the confusion, it seems the docs do indeed need some love!

On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:

...
That looks like exactly what I want. Thanks.

There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9.

They were originally merged into 7.11, but were backported to the official 7.10.2 release due to popular demand. It appears the @since annotation wasn't updated correspondingly.

...
- That function seems missing in HEAD. Or maybe it moved. A little searching says it *did* move, to GHC.Exception.

In HEAD we are now using CallStacks for error and undefined, which was not the case for the 7.10.2 release. This means the type needs to be defined much earlier in base, before we even have enough functionality to write a sensible formatter. showCallStack currently lives in GHC.Exception because that's where it's used, but that's not a good reason... I'll take another look at moving it back to GHC.Stack.

Indeed, this is probably a more logical place for them to live. Recent experience tells me that there is a great potential for import cycles in this area, however. I wish you luck ;)

...

...
Well, my problem is solved. But I think the documentation needs a pass here. And is there a reason not to have a Show instance?

I usually only use compiler-derived Show instances so that Read automatically works, as well as some nice formatting libraries like http://hackage.haskell.org/package/pretty-show for debugging. For pretty-printing like showCallStack I prefer a standalone function or a separate type-class.

Sure, I don't see any harm in deriving a Show instances, however. You may want to derive it with standalone deriving so you can then attach a Haddock pointing to the pretty version. e.g., data CallStack = ... -- | See also 'prettyCallStack'. deriving instance Show CallStack

...

If the name "showCallStack" suggests the compiler-derived output, we could change it to something like "prettyCallStack" or "formatCallStack", I don't have a strong opinion there.

I have also struggled with these sorts of naming decisions. The overloading of the word "show" is a bit problematic. (+1) for "pretty". Cheers, - Ben

Niklas Hambüchen

7:25 a.m.

On 07/12/15 11:59, Ben Gamari wrote:

...

...
If the name "showCallStack" suggests the compiler-derived output, we could change it to something like "prettyCallStack" or "formatCallStack", I don't have a strong opinion there.

I have also struggled with these sorts of naming decisions. The overloading of the word "show" is a bit problematic. (+1) for "pretty".

As a total proponent of Show-is-derived, +1 for a better name.

Richard Eisenberg

9:15 a.m.

And sorry if my tone on those emails was a bit snarky. It was late... though snarkiness at any hour is unwelcome. :) I understand the concerns about the Show instance, though I have no opinion about the name of the pretty-printer. My only request is that the pretty-print function is easily discoverable. In my case, I never would have looked in GHC.Exception, because I wasn't throwing (or dealing with) any exceptions. Perhaps a new module GHC.CallStack that bundles everything together and is the official export point? Bartosz, thanks for alerting me about pprSTrace. But I now realize that there is an annoying free variable in all of this: the name of the CallStack. Consider this:

...

foo :: (?location :: CallStack) => ... foo = pprSTrace ... -- pprSTrace uses ?location bar :: (?callstack :: CallStack) => ... bar = foo

If I understand correctly, I'll get a redundant constraint warning on bar, and I won't see bar's location in the output from pprSTrace. In other words, the choice for the CallStack name is infectious. I have no problem with ?location, but it's different from `error`'s choice (?callStack) and this choice seems to matter. Should we choose a common name? Advertise this widely with the docs for CallStack? (I imagine it's best for the ecosystem if everyone, everywhere uses the same name.) Or do I understand the feature wrongly? As quite a separate point from above, I may have found a bug: I put a (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained about a redundant constraint on rewriteEqEvidence, and indeed its call information wasn't propagated. rewriteEqEvidence uses pattern guards and do-notation, but that shouldn't muck with CallStack, should it? I've not tried to reproduce this in a smaller test case. Many thanks, Richard On Dec 7, 2015, at 1:39 AM, Eric Seidel wrote:

...

Hi Richard,

Sorry for all of the confusion, it seems the docs do indeed need some love!

On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:

...
That looks like exactly what I want. Thanks.

There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9.

They were originally merged into 7.11, but were backported to the official 7.10.2 release due to popular demand. It appears the @since annotation wasn't updated correspondingly.

...
- That function seems missing in HEAD. Or maybe it moved. A little searching says it *did* move, to GHC.Exception.

In HEAD we are now using CallStacks for error and undefined, which was not the case for the 7.10.2 release. This means the type needs to be defined much earlier in base, before we even have enough functionality to write a sensible formatter. showCallStack currently lives in GHC.Exception because that's where it's used, but that's not a good reason... I'll take another look at moving it back to GHC.Stack.

...
Well, my problem is solved. But I think the documentation needs a pass here. And is there a reason not to have a Show instance?

I usually only use compiler-derived Show instances so that Read automatically works, as well as some nice formatting libraries like http://hackage.haskell.org/package/pretty-show for debugging. For pretty-printing like showCallStack I prefer a standalone function or a separate type-class.

If the name "showCallStack" suggests the compiler-derived output, we could change it to something like "prettyCallStack" or "formatCallStack", I don't have a strong opinion there.

Thanks for the comments! Eric _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Eric Seidel

10:35 a.m.

On Mon, Dec 7, 2015, at 06:15, Richard Eisenberg wrote:

...

And sorry if my tone on those emails was a bit snarky. It was late... though snarkiness at any hour is unwelcome. :)

I understand the concerns about the Show instance, though I have no opinion about the name of the pretty-printer. My only request is that the pretty-print function is easily discoverable. In my case, I never would have looked in GHC.Exception, because I wasn't throwing (or dealing with) any exceptions. Perhaps a new module GHC.CallStack that bundles everything together and is the official export point?

I think the existing GHC.Stack makes sense, it already exports the -prof stacks and could re-export the dwarf stacks. Then we'd have a single access point for all stack trace functionality.

...

Bartosz, thanks for alerting me about pprSTrace. But I now realize that there is an annoying free variable in all of this: the name of the CallStack. Consider this:

...
foo :: (?location :: CallStack) => ... foo = pprSTrace ... -- pprSTrace uses ?location bar :: (?callstack :: CallStack) => ... bar = foo

If I understand correctly, I'll get a redundant constraint warning on bar, and I won't see bar's location in the output from pprSTrace. In other words, the choice for the CallStack name is infectious. I have no problem with ?location, but it's different from `error`'s choice (?callStack) and this choice seems to matter. Should we choose a common name? Advertise this widely with the docs for CallStack? (I imagine it's best for the ecosystem if everyone, everywhere uses the same name.) Or do I understand the feature wrongly?

That is correct. I'll advertise the ?callStack convention in the docs.

...

As quite a separate point from above, I may have found a bug: I put a (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained about a redundant constraint on rewriteEqEvidence, and indeed its call information wasn't propagated. rewriteEqEvidence uses pattern guards and do-notation, but that shouldn't muck with CallStack, should it? I've not tried to reproduce this in a smaller test case.

I have a patch waiting to land that reworks the CallStack solver due to a similar bug with let binders. I suspect it will fix this bug too, I'll check it out in my branch.

...

Many thanks, Richard

On Dec 7, 2015, at 1:39 AM, Eric Seidel wrote:

...
Hi Richard,

Sorry for all of the confusion, it seems the docs do indeed need some love!

On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:

...
That looks like exactly what I want. Thanks.

There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9.

They were originally merged into 7.11, but were backported to the official 7.10.2 release due to popular demand. It appears the @since annotation wasn't updated correspondingly.

...
- That function seems missing in HEAD. Or maybe it moved. A little searching says it *did* move, to GHC.Exception.

In HEAD we are now using CallStacks for error and undefined, which was not the case for the 7.10.2 release. This means the type needs to be defined much earlier in base, before we even have enough functionality to write a sensible formatter. showCallStack currently lives in GHC.Exception because that's where it's used, but that's not a good reason... I'll take another look at moving it back to GHC.Stack.

...
Well, my problem is solved. But I think the documentation needs a pass here. And is there a reason not to have a Show instance?

I usually only use compiler-derived Show instances so that Read automatically works, as well as some nice formatting libraries like http://hackage.haskell.org/package/pretty-show for debugging. For pretty-printing like showCallStack I prefer a standalone function or a separate type-class.

If the name "showCallStack" suggests the compiler-derived output, we could change it to something like "prettyCallStack" or "formatCallStack", I don't have a strong opinion there.

Thanks for the comments! Eric _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Eric Seidel

2:23 p.m.

...

...
As quite a separate point from above, I may have found a bug: I put a (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained about a redundant constraint on rewriteEqEvidence, and indeed its call information wasn't propagated. rewriteEqEvidence uses pattern guards and do-notation, but that shouldn't muck with CallStack, should it? I've not tried to reproduce this in a smaller test case.

After staring at your bug confusedly for a few minutes, wondering why I couldn't simplify it, I realized that the actual warning I was getting was in *mkTcTransCo*, not rewriteEqEvidence. mkTcTransCo does not in fact use a CallStack (by default) so the redundant constraint warning there would be correct. If I add a call to error, everything seems to check out. Can you confirm? Thanks! Eric

Richard Eisenberg

2:25 p.m.

On Dec 7, 2015, at 2:23 PM, Eric Seidel wrote:

...

After staring at your bug confusedly for a few minutes, wondering why I couldn't simplify it, I realized that the actual warning I was getting was in *mkTcTransCo*, not rewriteEqEvidence. mkTcTransCo does not in fact use a CallStack (by default) so the redundant constraint warning there would be correct. If I add a call to error, everything seems to check out.

Can you confirm?

No. I had modified mkTcTransCo to print out the call-stack, so that wasn't the problem. If you can't reproduce quickly, I'll take another look at this when I get a chance. Thanks for taking a pass. Richard

...

Thanks! Eric

Eric Seidel

2:35 p.m.

Oh I forgot to mention that I was testing on my local branch which fixes precisely this kind of bug when the CallStack is used inside a let-binder, which is what happens in rewriteEqEvidence. So it looks like my patch takes care of this issue. Thanks for the report! Sent from my iPhone

...

On Dec 7, 2015, at 11:25, Richard Eisenberg wrote:

...
On Dec 7, 2015, at 2:23 PM, Eric Seidel wrote:

After staring at your bug confusedly for a few minutes, wondering why I couldn't simplify it, I realized that the actual warning I was getting was in *mkTcTransCo*, not rewriteEqEvidence. mkTcTransCo does not in fact use a CallStack (by default) so the redundant constraint warning there would be correct. If I add a call to error, everything seems to check out.

Can you confirm?

No. I had modified mkTcTransCo to print out the call-stack, so that wasn't the problem. If you can't reproduce quickly, I'll take another look at this when I get a chance. Thanks for taking a pass.

Richard

...
Thanks! Eric

3454

Age (days ago)

3454

Last active (days ago)

List overview

Download

13 comments

8 participants

participants (8)

Bartosz Nitka
Ben Gamari
Eric Seidel
Evan Laforge
Levent Erkok
Niklas Hambüchen
Reid Barton
Richard Eisenberg