[lighthawk]

While I totally applaud this effort, how does it not lie? It inserts code into the actual source claiming it is on a line in the original file, but it is in a different line in the compiled version. That seems like it could be a problem at some point, and despite the serious utility in this, I'm not 100% convinced it is the right tool for the job.

[jschlatter]

Author here. I agree that this could cause surprises. Are there specific cases you have in mind?

Two cases I have thought of are stack traces and logging that inspects the stack. In the former case, if you get a stack trace while debugging it will not mean much because the lines do not match those of your code. In the latter case, logging statements may print the wrong things if they depend on being called a certain number of stack frames below user code. glog does this, for example[1]. I don't have solutions to either case yet, but I have some ideas of how to start. I think the utility the tool provides is well worth those two issues, and I'm hopeful that both can be fixed.

[1] https://github.com/golang/glog/blob/master/glog.go#L536

[skybrian]

A neat trick in some languages is to modify the source so that the line numbers don't change, for example by using semicolons instead of newlines and making sure a newline never appears in inserted instrumentation code. But I'm not sure if that's possible in Go.

[aleksi]

Go has special comments for that: "//line filename:line"

[jschlatter]

Thanks, I didn't know that. The go/token docs don't say much about it. Do you know if there is better documentation somewhere?

[rsc]

http://golang.org/cmd/gc/

[vorg]

I tried using this facility a few months ago based on this very short documentation but couldn't get it working, nor could I search out any further doco on it, so because it wasn't really important I gave up. Can I ask... have any of you ever successfully used this?

[aleksi]

Yes, me. It works. :) Also it's used by "go test -cover".