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

go/format: Modified AST is formatted weirdly #49846

Open
ghost opened this issue Nov 29, 2021 · 2 comments
Open

go/format: Modified AST is formatted weirdly #49846

ghost opened this issue Nov 29, 2021 · 2 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@ghost
Copy link

ghost commented Nov 29, 2021

What version of Go are you using (go version)?

$ go version
go version go1.17.2 darwin/arm64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/andreas.linz/Library/Caches/go-build"
GOENV="/Users/andreas.linz/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/andreas.linz/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/andreas.linz/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/homebrew/Cellar/go/1.17.2/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/homebrew/Cellar/go/1.17.2/libexec/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.17.2"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/andreas.linz/work/code//go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/qw/jbp3zpr56t14wdsc394hlhdr0000gq/T/go-build3434274700=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I implemented a small refactoring tool that modifies the AST of a Go source file and writes the modified AST back to the file using go/format. The problem is that the formatting of the modified part looks off, i.e. format.Node seems to randomly add indentation and linebreaks. This playground demonstrates the issue: https://go.dev/play/p/je4wZaGRZjq.

What did you expect to see?

In the playground linked above I expected this to be the output of format.Node:

package main

import "fmt"

func main() {
	s := struct{ A string }{
		A: strings.Join([]string{"Hello", " World!"}, ","),
	}

	fmt.Println(s.A)
}

What did you see instead?

This is what was rendered instead:

package main

import "fmt"

func main() {
	s := struct{ A string }{
		A: strings.Join(
			[]string{"Hello",

				" World!"},
			","),
	}

	fmt.Println(s.A)
}
@seankhliao
Copy link
Member

maybe a dup of #23771 ?

@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 29, 2021
@ghost
Copy link
Author

ghost commented Nov 30, 2021

I found a solution: https://go.dev/play/p/PzwikCXTqzB

The main difference to the playground example I gave in the issue description is the following:

	replacement, err := parser.ParseExprFrom(fset, "replacement.go", string(rawReplacement), parser.AllErrors|parser.ParseComments)

Before I used parser.ParseExpr which is a convenience wrapper around parser.ParseExprFrom that passes in an empty token.FileSet and an empty filename. The problem was that the replacement expression nodes had the wrong position information after they got inserted into the example.go AST. Reusing fset when parsing the replacement expression solved the issue.

I attached the ast.Print output of the modified AST with wrong position information and the one that has correct position information:

fixed.ast.txt
with-wrong-position-information.ast.txt

# diff {fixed,with-wrong-position-information}.ast.txt
119c119
<    118  .  .  .  .  .  .  .  .  .  .  .  .  .  NamePos: replacement.go:1:1
---
>    118  .  .  .  .  .  .  .  .  .  .  .  .  .  NamePos: example.go:1:1
124c124
<    123  .  .  .  .  .  .  .  .  .  .  .  .  .  NamePos: replacement.go:1:9
---
>    123  .  .  .  .  .  .  .  .  .  .  .  .  .  NamePos: example.go:1:9
129c129
<    128  .  .  .  .  .  .  .  .  .  .  .  Lparen: replacement.go:1:13
---
>    128  .  .  .  .  .  .  .  .  .  .  .  Lparen: example.go:1:13
133c133
<    132  .  .  .  .  .  .  .  .  .  .  .  .  .  .  Lbrack: replacement.go:1:14
---
>    132  .  .  .  .  .  .  .  .  .  .  .  .  .  .  Lbrack: example.go:2:1
136c136
<    135  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  NamePos: replacement.go:1:16
---
>    135  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  NamePos: example.go:3:2
141c141
<    140  .  .  .  .  .  .  .  .  .  .  .  .  .  Lbrace: replacement.go:1:22
---
>    140  .  .  .  .  .  .  .  .  .  .  .  .  .  Lbrace: example.go:3:8
144c144
<    143  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  ValuePos: replacement.go:1:23
---
>    143  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  ValuePos: example.go:3:9
149c149
<    148  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  ValuePos: replacement.go:1:32
---
>    148  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  ValuePos: example.go:5:4
154c154
<    153  .  .  .  .  .  .  .  .  .  .  .  .  .  Rbrace: replacement.go:1:41
---
>    153  .  .  .  .  .  .  .  .  .  .  .  .  .  Rbrace: example.go:5:13
158c158
<    157  .  .  .  .  .  .  .  .  .  .  .  .  .  ValuePos: replacement.go:1:44
---
>    157  .  .  .  .  .  .  .  .  .  .  .  .  .  ValuePos: example.go:6:2
164c164
<    163  .  .  .  .  .  .  .  .  .  .  .  Rparen: replacement.go:1:47
---
>    163  .  .  .  .  .  .  .  .  .  .  .  Rparen: example.go:6:5

I hope that my explanation was clear enough, if not please just ask.

@seankhliao seankhliao added this to the Unplanned milestone Aug 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

1 participant