vscode debugger support for errtrace.FormatString

[philippseith]

When debugging in vscode (or dlv) errors wrapped by errtrace are not shown in a nice way.

err: error(*braces.dev/errtrace.errTrace) *{err: error(*braces.dev/errtrace.errTrace) *{err: error(*braces.dev/errtrace.errTrace) ..., pc: 7387741}, pc: 7346695}
  data: *braces.dev/errtrace.errTrace {err: error(*braces.dev/errtrace.errTrace) *{err: error(*braces.dev/errtrace.errTrace) ..., pc: 7387741}, pc: 7346695}
... and so on

It is possible use call errtrace.FormatString(err) in the vscode Watch window, but if the method is not used elsewhere in you code, you will get a could not find symbol value for errtrace from the Watch window instead.
This is caused by go's dead code elimination.

Workaround: put _ = errtrace.FormatString(errors.ErrUnsupported) somewhere in your code.

What about adding this as

func init() {
	_ = errtrace.FormatString(errors.ErrUnsupported)
}

to errtrace itself?

[abhinav]

Hello! Thanks for opening the issue.

Just to confirm: you're suggesting adding a throwaway use of FormatString so that it gets compiled into the binary instead of being removed by dead code elimination? And that this won't fix debugging view, but will make it possible to Watch for a more readable version. I'm not opposed to this, although I wonder if even that call can get optimized away in the future?

Separately, I'm surprised it's eliminated right now: the Format method on the errtrace error relies on it.

CC @prashantv

[prashantv]

I would prefer not to force the method be compiled in, if it's not necessary. However, I am also surprised it's not already there given the Format method -- it could be that FormatString is being inlined into Format. Disabling inlining may help without bloating the binary size.

I'm also curious if there's other things we can to improve the debugging window output.