Comment 1:

To implement this we would need accurate file/line information for each pointer
dereference that might be nil.  I expect that would increase the size of binaries, and
the payback would be very small.  I'm not sure it's worth it.

Labels changed: added repo-main, release-none.

Status changed to Thinking.

Comment 2 by SRabbelier:

If it can't be fixed, might there be a way to indicate in the error message that the
location is approximate?

Comment 3:

The file/line information in a stack dump is always approximate.  The code might be
written as
    *
     p
That would valid Go (though not valid gofmt output).  What line should be shown in the
stack trace?

Comment 4 by SRabbelier:

Either line would be fine (as either would unambiguously point to the problem being with
dereferencing p). In this particular case, the compiler falsely reports the error as
being with line 13, when instead it means "somewhere in line 11-13".
In my non-reduced error case it meant I had to go through 15 statements and try to
figure out which one was actually causing the exception. The fact that I first had to
figure out that when the error said "nil panic on line 270" it actually meant "nil panic
on line 267" did not help in debugging.

Comment 5:

I'm sorry you had trouble.  But, to repeat, the file/line information is always
approximate, and making it more precise is a tradeoff that is not clearly better in all
ways.  There is no obviously right choice here.

@SRabbelier FYI running on Go1.8 on the playground https://play.golang.org/p/R1h4hdN05S
gives:

runtime.Version: go1.8
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0xffffffff addr=0x0 pc=0xc8a24]

goroutine 1 [running]:
main.main()
	/tmp/sandbox483844785/main.go:15 +0xe4

and I've highlighted the expected line 15 where the panic occured, unless I misinterpreted what's going on.

@ianlancetaylor should we close this issue?
@ianlancetaylor on your case of:

*
tp

https://play.golang.org/p/uYkaVNd6LN
it panics on the line with the tp identifier

That's great, thanks! I consider this fixed.

Thanks also, @odeke-em, for tracking this one down as well.

Not sure when/why this is fixed now, but I see the same result all the way back to 1.5.

For what it's worth, at tip (with position information no set to the left-most token uniquely identifying a syntactic construct) the error line is the line where the * is, which is what one would expect (it's the dereferencing that's causing the problem).

Closing this as well. If there are cases we've missed we can file new issues...