Call trace for failing evaluation via new emitter mode

[SeungheonOh]

closes #7146.

This replaces #7148. Unlike my original PR which made the plugin generate callstack message, this PR uses already existing profile-all option and make no addition to plugin. Since profile-all option gives function entrance and exit, it is possible to just have another EmitterMode that can make call trace from the trace messages.

I decided added new machinery just for callstack into plugin while we have profile-all which does something similar is unfavorable. This PR is much simpler and doesn't add maintenance burden to the plugin.

We can do something more on the emitter: like putting all call traces together. I kept it simple but let me know if there something that can be improved on emitter

[github-actions]

PR Preview Action v1.6.2
🚀 View preview at https://IntersectMBO.github.io/plutus/pr-preview/pr-7178/
Built to branch gh-pages at 2025-07-10 16:34 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[Unisay]

This approach looks less invasive, indeed!

[SeungheonOh]

Sorry for all the formatting error!

[Unisay]

Looks nice, IMO: the direction of calls is clear.
Having a space between the function name and its source location makes it even easier to 👀 scan:

Trace:
-> func (test/CallTrace/Spec.hs @ 78:1-78:4)
func 1
-> nestedLinear (test/CallTrace/Spec.hs @ 71:1-71:12)
-> nestedLinear2 (test/CallTrace/Spec.hs @ 72:1-72:13)
-> nestedLinear3 (test/CallTrace/Spec.hs @ 73:1-73:13)
-> nestedLinear4 (test/CallTrace/Spec.hs @ 74:1-74:13)
-> error

[Unisay]

I don't see a value in having this golden file: what exactly is being tested here?

[SeungheonOh]

This tests that when program got evaluated without failure, there's no enter/exit marker left on the trace log.

[Unisay]

This explanation makes sense to me. Do you mind embedding it into the name of the golden file, e.g.:
successfullEvaluationYieldsNoTraceLog or something along these lines?

[Unisay]

We have recently agreed to avoid leaving orphaned TODO, FIXME comments in the code. The best course of action would be:

• Create a github issue, such that a FIXME or TODO work can be a part of our dev process: triaged, assigned to a sprint, assigned to a person ("owned") etc.
• Amend your FIXME comment with a link to the issue.

(The "triage" role that you assume this sprint includes work on removing such orphaned comments ;-) )

[SeungheonOh]

done #7203

[Unisay]

This encoding :78:1-78:4 confuses me: what does each section mean ?

[SeungheonOh]

from line 78 column 1 to line 78 column 4. this is what SrcSpan pretty printer does. I don't really want to change the pretty instance.

[Unisay]

I see!
My first attempt to parse it in the head produced this result:

1. test/CallTrace/Spec.hs
2. 78
3. 1-78
4. 4

🤣

I think that my mental parser trips over the : as a separator between the file path (LHS) and SrcSpan (RHS).
I agree that we don't want to change the way SrcSpan is printed here,
but we can avoid mixing the same char : to separate

1. File path / Src Span
2. Line / Column

I suggested to use @ as a 1. separator before.

[SeungheonOh]

We can't change this without changing Pretty instances

Just src -> nameStr <> " (" <> show (src ^. srcSpanIso) <> ")"

I think this is okay honestly. This is standard format used by GHC(and other languages as well!), e.g. test/CallTrace/Spec.hs:88:10

[Unisay]

Suggested change

import Prelude ()

[SeungheonOh]

Again, we need this because we don't have NoImplicitPrelude

[Unisay]

Add NoImplicitPrelude ? It seems to be more explicit in its purpose than import Prelude ()

[SeungheonOh]

Ah, necessity to add explicitly add NoImplicitPrelude to make prelude not implicit!

I generally not prefer adding extra language extension, but I don't really mind here.

[Unisay]

Left a few comments.

[Unisay]

great stuff, thanks a lot!