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: incorrect positions recorded in export data #19391

Closed
griesemer opened this issue Mar 4, 2017 · 2 comments
Closed

cmd/compile: incorrect positions recorded in export data #19391

griesemer opened this issue Mar 4, 2017 · 2 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@griesemer
Copy link
Contributor

Compiling the following file:

package p

//line c.go:10
const C = 0      // file line = 4

//line t.go:20
type T int       // file line = 7

//line v.go:30
var V T          // file line = 10

//line f.go:40
func F() {}      // file line = 13

records the following positions in the export data:

C c.go 4
T /Users/gri/tmp/x.go 14
V v.go 10
F f.go 13

Except for V they are all surprising, one way or the other. The output from the syntax package is as follows in this case:

$ go test -v -run Dump -src=$HOME/tmp/x.go
=== RUN   TestDump
     1  *syntax.File {
     2  .  PkgName: p @ /Users/gri/tmp/x.go:1
     3  .  DeclList: []syntax.Decl (4 entries) {
     4  .  .  0: *syntax.ConstDecl {
     5  .  .  .  NameList: []*syntax.Name (1 entries) {
     6  .  .  .  .  0: C @ c.go:10[/Users/gri/tmp/x.go:3]
     7  .  .  .  }
     8  .  .  .  Type: nil
     9  .  .  .  Values: *syntax.BasicLit {
    10  .  .  .  .  Value: "0"
    11  .  .  .  .  Kind: 0
    12  .  .  .  }
    13  .  .  .  Group: nil
    14  .  .  }
    15  .  .  1: *syntax.TypeDecl {
    16  .  .  .  Name: T @ t.go:20[/Users/gri/tmp/x.go:6]
    17  .  .  .  Alias: false
    18  .  .  .  Type: int @ t.go:20[/Users/gri/tmp/x.go:6]
    19  .  .  .  Group: nil
    20  .  .  .  Pragma: 0
    21  .  .  }
    22  .  .  2: *syntax.VarDecl {
    23  .  .  .  NameList: []*syntax.Name (1 entries) {
    24  .  .  .  .  0: V @ v.go:30[/Users/gri/tmp/x.go:9]
    25  .  .  .  }
    26  .  .  .  Type: T @ v.go:30[/Users/gri/tmp/x.go:9]
    27  .  .  .  Values: nil
    28  .  .  .  Group: nil
    29  .  .  }
    30  .  .  3: *syntax.FuncDecl {
    31  .  .  .  Attr: map[]
    32  .  .  .  Recv: nil
    33  .  .  .  Name: F @ f.go:40[/Users/gri/tmp/x.go:12]
    34  .  .  .  Type: *syntax.FuncType {
    35  .  .  .  .  ParamList: nil
    36  .  .  .  .  ResultList: nil
    37  .  .  .  }
    38  .  .  .  Body: []syntax.Stmt (1 entries) {
    39  .  .  .  .  0: *syntax.EmptyStmt {
    40  .  .  .  .  }
    41  .  .  .  }
    42  .  .  .  Pragma: 0
    43  .  .  .  EndLine: 13
    44  .  .  }
    45  .  }
    46  .  Lines: 14
    47  }
--- PASS: TestDump (0.18s)

which shows consistent positions with the Name nodes (albeit they are off by 1).

@griesemer griesemer added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 4, 2017
@griesemer griesemer added this to the Go1.9 milestone Mar 4, 2017
@griesemer griesemer self-assigned this Mar 4, 2017
@gopherbot
Copy link

CL https://golang.org/cl/37870 mentions this issue.

gopherbot pushed a commit that referenced this issue Mar 6, 2017
By clearing out t.nod in copytype, we effectively lose the reference
from a Type back to its declaring OTYPE Node. This means later in
typenamesym when we add typenod(t) to signatlist, we end up creating a
new OTYPE Node. Moreover, this Node's position information will depend
on whatever context it happens be needed, and will be used for the
Type's position in the export data.

Updates #19391.

Change-Id: Ied93126449f75d7c5e3275cbdcc6fa657a8aa21d
Reviewed-on: https://go-review.googlesource.com/37870
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
@gopherbot
Copy link

CL https://golang.org/cl/37936 mentions this issue.

@golang golang locked and limited conversation to collaborators Mar 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

2 participants