declarations only used inside subsequently defined closures problematic: error "printf.go:485:6: argType declared but not used" about godebug

[jeremyschlatter]

Thanks for the report! Surprisingly, it looks like you found a bug in golang.org/x/tools/go/loader:

Minimal loader program loader.go:

package main

import (
    "fmt"

    "golang.org/x/tools/go/loader"
)

func main() {
    var conf loader.Config
    conf.CreateFromFilenames("main", "small.go")
    _, err := conf.Load()
    fmt.Println(err)
}

results on your minimal test case small.go

$ go run loader.go
small.go:7:6: touchedInClosure declared but not used
couldn't load packages due to errors: main

I'll see if I can find out what's going on and get this fixed upstream.

[omeid]

This isn't a bug. Using a variable isn't just writing to it but reading it and because the variable is never used inside it's scope, it complains about it.

[jeremyschlatter]

@omeid is right. It's unfortunate that godebug does not accept a program that the go tool does, though.

I was curious what the spec had to say about this. I found this:

Implementation restriction: A compiler may make it illegal to declare a variable inside a function body if the variable is never used.

So the spec leaves this open, and both the go tool and the loader library are in compliance. The latter is just more strict.

[jeremyschlatter]

Early versions of godebug used golang.org/x/tools/go/types for type checking. That library does not object to small.go:

package main

import (
    "fmt"
    "go/ast"
    "go/parser"
    "go/token"

    "golang.org/x/tools/go/types"
)

func main() {
    var fs token.FileSet
    f, err := parser.ParseFile(&fs, "small.go", nil, 0)
    if err != nil {
        fmt.Println("error in parsing: ", err)
        return
    }
    _, err = types.Check("main", &fs, []*ast.File{f})
    fmt.Println(err)
}

Running it:

$ go run parser.go
<nil>

The loader library provides a lot that the types library does not, so it might not be worth the effort to switch to it. But it would make godebug behave more like go for this case.

[omeid]

Please don't downgrade.

c2go has been written against an older version of Go and should be ported to the latest if they want to use godebug, not the other way around.

[jeremyschlatter]

c2go isn't outdated. It runs on tip (or, at least, my copy of tip from last week):

~/src/github.com/glycerine/c2go$ go version
go version devel +180fbb1 Fri Mar 27 00:30:14 2015 +0000 linux/amd64
~/src/github.com/glycerine/c2go$ go run *.go
usage: c2go [options] *.c
  -I string
        include directory
  -c string
        config file
  -dst string
        GOPATH root of destination (default "/tmp/c2go")
exit status 2

The surprising behavior is that godebug's type checker behaves differently from go's type checker, even though both are compliant with the language spec.

[jeremyschlatter]

@glycerine I tried just deleting that variable from the code and godebug run worked fine:

$ godebug run *.go
usage: c2go [options] *.c
  -I="": include directory
  -c="": config file
  -dst="/tmp/c2go": GOPATH root of destination

[jeremyschlatter]

Oops, I messed up my test with golang.org/x/tools/go/types. I had edited small.go before I ran the test. Running again with the original file, it gives the same error as the loader library:

$ go run parser.go
small.go:7:6: touchedInClosure declared but not used

I'm going to call this one wontfix. Sorry, @glycerine! If you want to debug that library, just delete that variable.

[glycerine]

Arg. Agree we can't fix this locally, but I am still inclined to think we
should upstream this as an issue so that "go run" and the types library are
consistent.

On Sun, Apr 5, 2015 at 9:58 PM, Jeremy Schlatter [email protected]
wrote:

Closed #14 #14.

—
Reply to this email directly or view it on GitHub
#14 (comment).

Best regards,
Jason

[glycerine]

err, I misread -- It's the "golang.org/x/tools/go/loader" library that
differs in strictness, yes?

On Mon, Apr 6, 2015 at 7:55 AM, Jason E. Aten [email protected] wrote:

Arg. Agree we can't fix this locally, but I am still inclined to think we
should upstream this as an issue so that "go run" and the types library are
consistent.

On Sun, Apr 5, 2015 at 9:58 PM, Jeremy Schlatter <[email protected]

wrote:

Closed #14 #14.

—
Reply to this email directly or view it on GitHub
#14 (comment).

Best regards,
Jason

[glycerine]

opened golang/go#10356 to track upstream

[jeremyschlatter]

go/loader and go/types behave the same way, and both are different from gc. I thought differently earlier in the ticket, but I was mistaken.