Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
set CGO_CFLAGS=-g -O2
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\Markus\AppData\Local\Temp\go-build314487018=/tmp/go-build -gno-record-gcc-switches
What did you do?
I compiled a .go file that contains a type conflict, between the given function argument and the wanted function argument.
And I wanted to get a useful error message.
What did you expect to see?
A correct line number in the error message about the type conflict.
What did you see instead?
The wrong line number, depending on the case, which is confusing.
I don't understand what's wrong with the 3rd program - the error message seems correct. What am I missing?
In this case the message is okay, because it points to the function call. But I believe it should be more specific. The line number should point to the argument, because the message starts by giving the name of the argument.
I tried to investigate, but I have looked at the Golang source for the first time today.
subr.go has a comment above hasUniquePos() which explains something similar. setlineno uses hasUniquePos to check whether the node has a line number that points to the place where something is used, instead of where it's declared.
typechecker.go and subr.go rely on setlineno to set the global lineno, instead of doing it more directly. But setlineno finds that the node has no unique position. And that might be right? Because n.Op is ONAME. If it was OCALLPART (?) or some OARG, I would find the unique position would be the line where the argument stands. But ONAME doesn't look like that and hasUniquePos tells setlineno that the node cannot have a unique pos, it does case ONAME: return false.
The line number of the node would have been the line of the declaration of what is used as argument. But that line number does not get used, instead lineno will keep some older line number.
And unfortunately, in the list or nodes there were no good XPos values either, so it looks like the parser should be modified to store the correct line number in the first place.
I didn't go on looking at it. It looks like someone who knows what he does has to invest some time. Would be really nice to have correct line numers. Also, desc() could take the index of the argument and return "argument 1 in" instead of "argument in", this would also be nice.