-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: //line problems #22660
Comments
/cc @griesemer @mdempsky |
This used to work correctly. It appears that https://go-review.googlesource.com/c/go/+/63693 broke this code (while fixing a bunch of related issues). |
/cc @crawshaw |
@crawshaw I'm inclined to revert https://go-review.googlesource.com/c/go/+/63693, it calls objabi.AbsFile early, at a place where we expect the actual filename of the //line directive, unchanged. I don't understand how this is supposed to work. |
@griesemer I suspect I didn't consider this (obvious in retrospect) case. CL 63693 also fixes #21720 which I would say is worse than this one, and was backported to 1.9 for it. So I'm disinclined to just revert it without finding a solution to both cases. I am out today, but can take a look on Monday if you like. |
Change https://golang.org/cl/77090 mentions this issue: |
@crawshaw I think actually the bug is that we don't provide both the unchanged and the cleaned absolute file name. I have a try-out CL coming shortly. |
Change https://golang.org/cl/77151 mentions this issue: |
Change https://golang.org/cl/121735 mentions this issue: |
Issues #10043, #15405, and #22660 appear to have been fixed, and whatever tests I could run locally do succeed, so remove the skips. Issue #7237 was closed in favor of #17906, so update its skip line. Issue #7634 was closed as it had not appeared for over three years. Re-enable it for now. An issue should be open if the test starts being skipped again. Change-Id: I67daade906744ed49223291035baddaad9f56dca Reviewed-on: https://go-review.googlesource.com/121735 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I'm trying to fix and test some issues around cmd/cover and line numbers, but I've run into two compiler problems with the processing of //line directives. These seem like they should be easy fixes.
Literal $GOROOT
This creates a trivial x.go with a line directive that gives a full path to a non-existent file in the GOROOT root. (The fact that the file does not exist is irrelevant.)
Then the compiler prints an error because there is no package statement in the file. The error should be reported to the fake file name, and it is, except the path name literally says $GOROOT instead of the actual GOROOT directory.
The $GOROOT appears because that's what we do want to write as the file name in the object file and export data. But for error messages we want to see the actual path name. It looks like objabi.AbsFile is being called incorrectly (a bit too early) while handling the //line directive. It looks like the code needs to distinguish between computing PosBase.filename and PosBase.absFilename, and it makes no such distinction.
Line number stack
The syntax
$line[$actualLine]
in error messages traces back to the Plan 9 C compiler, but it is problematic for code generated during a build because the bracketed path is useless noise. We should turn it off by default. If we want to preserve the ability to see those annotations, we can reintroduce the old -L (show full file names) flag to add this.For example, the error in the case above needs to say just:
without the
[x.go:2:1]
.The text was updated successfully, but these errors were encountered: