cmd/compile: Wrong line number in type error message #42399
Comments
toothrot
changed the title
toothrot
added
the
NeedsInvestigation
|
/cc @randall77 @griesemer |
|
The typechecker for generic Go ( I don't understand what's wrong with the 3rd program - the error message seems correct. What am I missing? |
|
Possibly related to #23660. |
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. |
|
The parser does store the correct information (it's essentially the same parser as in It's a known problem that we lose position information in the nodes. Not urgent. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ghost
closed this as 
What version of Go are you using (
go version)?go version go1.15.3 windows/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Markus\AppData\Local\go-build
set GOENV=C:\Users\Markus\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Markus\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Markus\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
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.
Test cases
Line number is off by one line:
https://play.golang.org/p/pbISInXKqch
Line number is off by two lines:
https://play.golang.org/p/wXI3m-iO9f7
Line number is the function call, but the message is misleading in this case:
https://play.golang.org/p/RBrlfV41adh
There has been this forum post I made:
https://forum.golangbridge.org/t/go-error-messages-not-helpful/21173
The text was updated successfully, but these errors were encountered: