Hello there @mattcary, thanks for reporting this. So if I understood your issue right, it is that the line number reporting is inaccurate right? That on Go1.9.2 you are getting the error reported on line 9

func forEach(data []int, f func(int)) {
        for _, i := range data {
                f(i)
        } // <--- right here

Please try with Go1.10 beta, the line numbers now seem to report on line 8

func forEach(data []int, f func(int)) {
        for _, i := range data {
                f(i) // <--- right here
        }

$ go test -v
=== RUN   TestHelper
--- FAIL: TestHelper (0.00s)
	tf_test.go:8: Saw 2 instead of 3
FAIL
exit status 1
FAIL	_/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/23249	0.006s

Thanks for your reply Emmanuel.

Just downloaded the beta, it reports the error at the call to f(i) identically in 1.9.2 as in 1.10beta1.

However, the issue is that the line number is in the wrong function altogether: it should report an error in TestHelper(), not in forEach() at all. Putting a call to tb.Helper in forEach() makes the line number display correctly:

func forEach(tb testing.TB, data []int, f func(int)) {
tb.Helper()
for _, i := range data {
f(i)
}
}

But this requires plumbing tb through, which would not be possible if forEach were a non-testing utility method.

Happy New Year! :)

Thank you @mattcary for the clarification, and happy new year to you too!

Oh I see, so if I may paraphrase, your issue is that you'd like *testing.B.Helper() and *testing.T.Helper() to propagate/nest the behavior(using the parent function's file and line information), to any callers that are any call-level after the original marking?

I'll also page @cespare and @ianlancetaylor.

Yes, something like that. I was thinking that the highest T.Helper() call in the stack should have as parent the testing line we want to display as an error.

Thx

Awesome, thank you for the clarification @mattcary, I'll re-amend the title for even more precision, please feel free to edit it.

With the suggested change, in order to decide whether or not to mark a method as a helper, you need to know whether there is a helper higher up in the call chain. In the given code, for instance, forEach will only be ignored as a helper if it is called from a helper; if you call forEach directly from TestHelper, then you'll have the same issue where the printed line number will be inside forEach.

With t.Helper's existing behavior, the rule is simple: if you want a function to be ignored when go test prints file:line, mark it as a helper. You can make this choice function-by-function without ever considering the full set of call paths that reach the function.

Additionally, I think it's too late to change this behavior because t.Helper is in a released version of Go.

I too am having this issue and it would be very useful for Helper() to do this.