-
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/cgo: generate correct column info #26692
Comments
Fix is here: https://go-review.googlesource.com/c/go/+/126675. Tested manually by using self-compiled cgo with the patch; it works! |
unconvert output is broken when using Go 1.11. A quick example: With Go 1.10: > go run unconvert.go github.com/docker/docker/daemon/graphdriver/copy > /home/kir/go/src/github.com/docker/docker/daemon/graphdriver/copy/copy.go:242:28: unnecessary conversion With Go 1.11 beta 2: > go run unconvert.go github.com/docker/docker/daemon/graphdriver/copy > copy.go:242:0: unnecessary conversion Note that there are two issues: - column is 0; - file names have path stripped. The issue with column is filed as golang/go#26692; there is no way to fix it in unconvert. The second issue is currently discussed in golang/go#26671, but it might not be fixed since the new documentation says: > The filenames in line directives now remain untouched by the scanner; > there is no cleanup or conversion of relative into absolute paths > anymore, in sync with what the compiler's scanner/parser are doing. > Any kind of filename transformation has to be done by a client. This > makes the scanner code simpler and also more predictable. So, here's the alternative: if the file name is not absolute, prepend the path as we know it. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
@griesemer PTAL |
cmd/cgo inserts/deletes some lines of code (e.g., removing the In previous releases, when parsing cmd/cgo processed source files, the Due to go/scanner changes for Go 1.11, column information is no longer being tracked for cmd/cgo processed files. This is arguably more correct, because it no longer gives bogus column information for rewritten lines. However, it's also arguably a regression, because column information is now lost for lines that weren't rewritten. From a casual inspection, CL 126675 restores the (questionable) behavior from Go 1.10. I think the proper long-term fix is for cmd/cgo to emit For Go 1.11, I'm leaning towards it's better to give suboptimal output consistent with Go 1.10, rather than give a differently-suboptimal output. (I.e., I'm leaning towards CL 126675.) /cc @ianlancetaylor |
unconvert output is broken when using Go 1.11. A quick example: With Go 1.10: > go run unconvert.go github.com/docker/docker/daemon/graphdriver/copy > /home/kir/go/src/github.com/docker/docker/daemon/graphdriver/copy/copy.go:242:28: unnecessary conversion With Go 1.11 beta 2: > go run unconvert.go github.com/docker/docker/daemon/graphdriver/copy > copy.go:242:0: unnecessary conversion Note that there are two issues: - column is 0; - file names have path stripped. The issue with column is filed as golang/go#26692; there is no way to fix it in unconvert. The second issue is currently discussed in golang/go#26671, but it might not be fixed since the new documentation says: > The filenames in line directives now remain untouched by the scanner; > there is no cleanup or conversion of relative into absolute paths > anymore, in sync with what the compiler's scanner/parser are doing. > Any kind of filename transformation has to be done by a client. This > makes the scanner code simpler and also more predictable. So, here's the alternative: if the file name is not absolute, prepend the path as we know it. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Change https://golang.org/cl/126675 mentions this issue: |
Reopening to get correct column info. |
I thought I remembered one of the motivations for Also, it looks like cmd/cover/cover.go could use the same |
I believe that cmd/cover could use That said I think cmd/cover is a less interesting case since it seems less likely that people will ask for coverage of code that generates compilation errors. Getting compilation errors on cgo-generated code, on the other hand, seems like a normal stage of development. |
Oops, I was referring to commit 2a39d1e ("Now that cover does not modify the formatting of the original file or add any newline characters"), but forgot to actually link to that in my comment. |
cmd/cover no longer inserts lines, so error messages will show the correct line number. But cmd/cover does edit lines, so error messages will not show the correct column number. I think the current state of things is reasonable: cmd/cover does not state a column in the Later perhaps we should change cmd/cover to use |
I see. It seems I misunderstood "does not modify the formatting" to mean "does not modify at all." |
Sure, but if you think about it, "does not modify at all" doesn't really make sense here. The cmd/cover tool has to do something. |
I believe it should be filed as a separate issue. The original report is about missing column info for cgo-generated files which is Go-1.11beta{1,2} regression and is now fixed. The issue of skewed (not missing) column info in some (not all) lines of cgo-generated files is not a regression and is valid not just for Go 1.11beta but also earlier versions. The fact that it emerged as a followup to this issue does not mean it belongs here. |
Doesn't seem like a big deal to me in this case, but, OK, filed #26745. |
What version of Go are you using (
go version
)?go version go1.11beta2 linux/amd64
Does this issue reproduce with the latest release?
yes (currently beta2)
This is a regression in go 1.11 since when using go 1.10 there is no such issue (see below).
What operating system and processor architecture are you using (
go env
)?What did you do?
Ran unconvert (https://github.com/mdempsky/unconvert) on Moby (https://github.com/moby/moby) sources.
What did you expect to see?
Filenames and positions (file:line:column) for every error it finds. Example (when using Go 1.10.1):
What did you see instead?
Column is 0 for files that are cgo-preprocessed (i.e. contain
import "C"
):Analisys
This appears in cgo-processed files having
//line:<file>:<line>
directive (without column field), so column is 0 in call to go/token'sAddLineColumnInfo()
method. Next,unpack()
does thisand as a result in cgo-preprocessed files we have no column information at all. This is caused by commit 99c3021.
Suggestions
I see two ways of fixing this.
cmd/cgo
generated//line:
marks.The text was updated successfully, but these errors were encountered: