Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: Wrong line number in type error message #42399

Closed
ghost opened this issue Nov 5, 2020 · 8 comments
Closed

cmd/compile: Wrong line number in type error message #42399

ghost opened this issue Nov 5, 2020 · 8 comments

Comments

@ghost
Copy link

@ghost ghost commented Nov 5, 2020

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

@toothrot toothrot changed the title Wrong line number in type error message when compiling cmd/compile: Wrong line number in type error message Nov 6, 2020
@toothrot toothrot added this to the Backlog milestone Nov 6, 2020
@toothrot
Copy link
Contributor

@toothrot toothrot commented Nov 6, 2020

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Nov 6, 2020

The typechecker for generic Go (dev.typeparams branch) does this correctly. For the first and second program (using the compiler of dev.typeparams branch):

$ go tool compile -G x.go
x.go:21:3: cannot use actual_line (variable of type int32) as int value in argument

I don't understand what's wrong with the 3rd program - the error message seems correct. What am I missing?

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Nov 6, 2020

Possibly related to #23660.

Loading

@ghost
Copy link
Author

@ghost ghost commented Nov 6, 2020

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.

Loading

@ghost
Copy link
Author

@ghost ghost commented Nov 6, 2020

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.

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Nov 6, 2020

The parser does store the correct information (it's essentially the same parser as in dev.typeparams, which does it correctly).

It's a known problem that we lose position information in the nodes. Not urgent.

Loading

@ghost

This comment was marked as off-topic.

@ianlancetaylor

This comment was marked as off-topic.

@ghost ghost closed this Nov 7, 2020
@golang golang locked and limited conversation to collaborators Nov 7, 2021
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants