Which versions of go does this code compile cleanly in?

On Mon, 15 Feb 2016, 15:12 Ali Najafizadeh notifications@github.com wrote:

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

go1.6rc1 and go1.6rc2

What operating system and processor architecture are you using?

OSX El Capitan

What did you do?

I have started to see some wired compile issue in my project when I
upgrade to 1.6. In order to make it more clear I have strip down my entire
project and created a very small project which highlights the issues. The
repo can be found here https://github.com/alinz/goissue.git.

the wired part is that if fmt.Println("") added in Service function, it
fixes the probelm.

What did you expect to see?
Just compile the code.

What did you see instead?

Line 6, file cmd/issue/main.go

cannot use issue.Conf.OAuth2Google (type struct { ClientID string "toml:"client_id"";
ClientSecret string "toml:"client_secret""; RedirectURL string "toml:"redirect_url"" })
as type struct { ClientID string; ClientSecret string; RedirectURL string } in assignment

Line 11, file cmd/issue/main.go

internal compiler error: agen: unknown op CONV u(2) l(11) tc(1) implicit(true)
STRUCT-struct { ClientID string; ClientSecret string; RedirectURL string }

—
Reply to this email directly or view it on GitHub
#14331.

@davecheney I compiles fine in 1.5.3.

This is a weird interaction with inlining. The call to "fmt" makes service.Service not a leaf function and thus unlinable so the defintion of service.Service is not written to the head of the .a file.

/cc @rsc @ianlancetaylor

@davecheney, One other interesting thing that I found is that instead of this

func Service() {
    conf := issue.Conf.OAuth2Google

    access := &Access{
        ClientID: conf.ClientID,
    }
}

if you set ClientID directly, it works and compiles fine

func Service() {
    access := &Access{
        ClientID: issue.Conf.OAuth2Google.ClientID,
    }
}

This is a compiler bug in the handling of inlining functions with unnamed structs with tags. I wrote a simpler test case in https://golang.org/cl/19520.

I marked this 1.6, but this seems rare enough that I think it might be OK to postpone this to a future 1.6.1.

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

I'll work on a CL to disable inlining in this case for Go 1.6. We can do a proper fix in Go 1.7.

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