text:
cmd/gofmt: fails on type aliases

go version go1.8.3 linux/amd64
I've pulled latest versions of all deps, including golang.org/x/net/context. Now 1.8 go fmt ./... fails with:
vendor/golang.org/x/net/context/go19.go:15:14: expected type, found '='
vendor/golang.org/x/net/context/go19.go:20:17: expected type, found '='

https://travis-ci.org/google/syzkaller/builds/262119828
Not sure what exactly part is guilty. But I guess it will affect a bunch of users.
Go1.9 is not released yet, and I am not sure when it will appear on travis-ci.org.
go fmt ignores build tags, which is reasonable.
1.8 go does not ignore vendor dirs.
I cannot not update packages because our cloud APIs continue to break public interfaces.
Any way we can resolve this?

@dvyukov for now, I've added for you a PR at https://github.com/google/syzkaller/pull/329, please test it out on Travis CI and it should be able to run the tests against Go1.9rc1 as well as tip, instead of against 1.8.1 on which aliases are gonna trip out, and when Go1.9 is released then we can update from 1.9rc1 to 1.9.

That's unfortunate. Even if we did a Go 1.8.x release for this, user also wouldn't get that.
So really the answer is for people to move to Go 1.9 if they use deps using Go 1.9 (even +build conditional Go 1.9) features I guess.
This is something to keep in mind for rolling out any future language changes.
/cc @ianlancetaylor @griesemer @robpike @broady @rsc

It seems that x/net/context added type aliases too early. I mean it's a widely used package and 1.9 is not even released.

I don't think so.
The whole point of +build tags is so we can do just that.
I think the bug here is that gofmt should respect +build go1.N tags at least, or at least least respect them enough to ignore them if the parse fails.
That is, if I'm running go1.14 and it's formatting a file with +build go1.16, it should try its best to format that file, unless it gets a parse error, in which case it should silently do nothing and not fail.

gofmt doesn't touch a file if it contains syntax errors, but I'm not convinced that it shouldn't complain. A script could trivially discard any error output. Or, perhaps for manual use, maybe there could be a -silent flag.

@griesemer you mean always running go fmt as: go fmt ./... 2>/dev/null || true?

@dvyukov Not always, but perhaps in situations where we don't care about errors.

Still exists in
go version go1.8 linux/amd64

Found this bug while generating swagger doc for my api
2017/11/14 12:20:03 Generate swagger docs....
2017/11/14 12:20:03 Generate general API Info
2017/11/14 12:20:03 ParseFile panic:vendor/golang.org/x/net/context/go19.go:15:14: expected type, found '=' (and 1 more errors)
panic: ParseFile panic:vendor/golang.org/x/net/context/go19.go:15:14: expected type, found '=' (and 1 more errors)

goroutine 1 [running]:
log.Panicf(0x7d359e, 0x13, 0xc421104fb8, 0x1, 0x1)
        /usr/local/go/src/log/log.go:329 +0xda
github.com/swaggo/swag.(*Parser).getAllGoFileInfo.func1(0xc4262c5b30, 0x27, 0x962040, 0xc4262bd6c0, 0x0, 0x0, 0x0, 0x0)
        /home/fahim/go/src/github.com/swaggo/swag/parser.go:228 +0x1a2
path/filepath.walk(0xc4262c5b30, 0x27, 0x962040, 0xc4262bd6c0, 0xc42025c220, 0x0, 0x0)
        /usr/local/go/src/path/filepath/path.go:351 +0x81
path/filepath.walk(0xc42625dea0, 0x1f, 0x962040, 0xc421c22680, 0xc42025c220, 0x0, 0x0)
        /usr/local/go/src/path/filepath/path.go:376 +0x414
path/filepath.walk(0xc42614d680, 0x17, 0x962040, 0xc421a86ea0, 0xc42025c220, 0x0, 0x0)
        /usr/local/go/src/path/filepath/path.go:376 +0x414
path/filepath.walk(0xc424a09c00, 0x13, 0x962040, 0xc4227cc820, 0xc42025c220, 0x0, 0x0)
        /usr/local/go/src/path/filepath/path.go:376 +0x414
path/filepath.walk(0xc424a09b60, 0x11, 0x962040, 0xc4227cc750, 0xc42025c220, 0x0, 0x0)
        /usr/local/go/src/path/filepath/path.go:376 +0x414
path/filepath.walk(0xc42017452a, 0x6, 0x962040, 0xc4202a7860, 0xc42025c220, 0x0, 0x0)
        /usr/local/go/src/path/filepath/path.go:376 +0x414
path/filepath.walk(0x7ce199, 0x2, 0x962040, 0xc4201204e0, 0xc42025c220, 0x0, 0x10)
        /usr/local/go/src/path/filepath/path.go:376 +0x414
path/filepath.Walk(0x7ce199, 0x2, 0xc42025c220, 0x1a, 0x0)
        /usr/local/go/src/path/filepath/path.go:398 +0x14c
github.com/swaggo/swag.(*Parser).getAllGoFileInfo(0xc42020c500, 0x7ce199, 0x2)
        /home/fahim/go/src/github.com/swaggo/swag/parser.go:234 +0x7b
github.com/swaggo/swag.(*Parser).ParseApi(0xc42020c500, 0x7ce199, 0x2, 0x7cfbfe, 0x9)
        /home/fahim/go/src/github.com/swaggo/swag/parser.go:59 +0xd2
github.com/swaggo/swag/gen.(*Gen).Build(0xc4201b1950, 0x7ce199, 0x2, 0x7cfbfe, 0x9, 0x0, 0x0)
        /home/fahim/go/src/github.com/swaggo/swag/gen/gen.go:27 +0x42a
main.main.func1(0xc420088840, 0x0, 0xc420088840)
        /home/fahim/go/src/github.com/swaggo/swag/cmd/swag/main.go:23 +0x55
github.com/urfave/cli.HandleAction(0x7557e0, 0x7e1f60, 0xc420088840, 0xc420270100, 0x0)
        /home/fahim/go/src/github.com/urfave/cli/app.go:502 +0xd4
github.com/urfave/cli.Command.Run(0x7ce7c4, 0x4, 0x0, 0x0, 0xc42025c100, 0x1, 0x1, 0x7d1bd5, 0xe, 0x0, ...)
        /home/fahim/go/src/github.com/urfave/cli/command.go:210 +0xb87
github.com/urfave/cli.(*App).Run(0xc420388000, 0xc42000c5c0, 0x2, 0x2, 0x0, 0x0)
        /home/fahim/go/src/github.com/urfave/cli/app.go:259 +0x7b7
main.main()
        /home/fahim/go/src/github.com/swaggo/swag/cmd/swag/main.go:29 +0x196

Also Duting go fmt
gateway/vendor/golang.org/x/net/context/go19.go:15:14: expected type, found '='
gateway/vendor/golang.org/x/net/context/go19.go:20:17: expected type, found '='
exit status 2
gateway/vendor/golang.org/x/net/ipv4/batch.go:59:14: expected type, found '='
gateway/vendor/golang.org/x/net/ipv4/batch.go:78:2: expected declaration, found 'if'
exit status 2
gateway/vendor/golang.org/x/net/ipv6/batch.go:56:14: expected type, found '='
gateway/vendor/golang.org/x/net/ipv6/batch.go:69:2: expected declaration, found 'if'
exit status 2

here what go19.go file looks like
// Copyright 2017 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

// +build go1.9

package context

import "context" // standard library's context, as of Go 1.7

// A Context carries a deadline, a cancelation signal, and other values across
// API boundaries.
//
// Context's methods may be called by multiple goroutines simultaneously.
type Context = context.Context

// A CancelFunc tells an operation to abandon its work.
// A CancelFunc does not wait for the work to stop.
// After the first call, subsequent calls to a CancelFunc do nothing.
type CancelFunc = context.CancelFunc

@sh0umik Yes, that specific problem with gofmt is fixed in the 1.9 release.
This issue is about whether gofmt should somehow honor build tags to avoid this kind of crash in the future.

I got this error today during make generate. My code is rebased on 8bd6bd63 ('prog: allow escaping paths but don't generate them').
`vendor/golang.org/x/net/context/go19.go:15:14: expected type, found '='
vendor/golang.org/x/net/context/go19.go:20:17: expected type, found '='
exit status 2
vendor/golang.org/x/net/http2/transport.go
vendor/google.golang.org/grpc/status/status.go
vm/qemu/qemu.go
make[1]: *** [format_go] Error 1
`
Any suggestion how to move on?
Thanks.

Hi Noa,
We require Go 1.9+ because of this, please upgrade. Also if you are going to do any changes, then 1.9 or 1.10, but not 1.11 because of breaking changes in gofmt output.

authors: bradfitz dvyukov griesemer ianlancetaylor noaos odeke-em sh0umik


text:
os: Stdin.SetDeadline() fails on Linux even when stdin is a pipe

What version of Go are you using (go version)?
go version go1.10 linux/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/vol/var/root/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/vol/var/root/go"
GORACE=""
GOROOT="/vol/var/build/go-1.10"
GOTMPDIR=""
GOTOOLDIR="/vol/var/build/go-1.10/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build675138706=/tmp/go-build -gno-record-gcc-switches"
What did you do?
On Linux os.Stdin.SetDeadline() fails with file type does not support deadline even when the standard input is a pipe. The following code demonstrates this:
package main

import (
        "fmt"
        "log"
        "os"
        "os/exec"
        "time"
)

func main() {
        if len(os.Args) == 2 && os.Args[1] == "do_test" {
                err := os.Stdin.SetDeadline(time.Now().Add(time.Minute))
                fmt.Println(err)
                f, err := os.Open("/proc/self/fd/0")
                if err != nil {
                        log.Fatal(err)
                }
                err = f.SetDeadline(time.Now().Add(time.Minute))
                fmt.Println(err)
                os.Exit(0)
        }

        r, w, err := os.Pipe()
        if err != nil {
                log.Fatal(err)
        }
        cmd := exec.Command(os.Args[0], "do_test")
        cmd.Stdin = r
        cmd.Stdout = os.Stdout
        cmd.Stderr = os.Stderr
        err = cmd.Run()
        if err != nil {
                log.Fatal(err)
        }
        r.Close()
        w.Close()
}

The program creates a pipe and then run itself the second time with the stdin of the second invocation connected to the pipe. Then the second copy calls os.Stdin.SetDeadline(). That fails with the above mentioned error that the program prints.
Then, as a workaround, the code opens the stdin again via Linux-specific /proc/self/fd/0 and calls SetDeadline on that. This time the SetDedaline reports a success.  Note that this is not a universal workaround as /proc may not be available when, for example, the code runs in a restricted Linux container.
On play.golang.org the first SetDedaline call works as expected while the attempt to open /proc/self/fd/0 fails.
What did you expect to see?
The program should print:
<nil>
<nil>

to indicate that both SetDedaline calls returned nil as error.
What did you see instead?
file type does not support deadline
<nil>

It happens in my system too.
It seems that deadlines never works with os.Files obtained with os.NewFile (like os.Stdin is).
Take a look at this code (assume that stdin is a pipe):
func main() {
    fopen, err := os.Open("/proc/self/fd/0")
    if err != nil {
        log.Fatal(err)
    }
    err = fopen.SetDeadline(time.Now().Add(time.Minute))
    fmt.Println(err)  // prints "<nil>"
    fnew := os.NewFile(fopen.Fd(), fopen.Name())
    err = fnew.SetDeadline(time.Now().Add(time.Minute))
    fmt.Println(err)  // prints "file type does not support deadline"
}

os.NewFile calls newFile with kind == newFileKind, therefore according to the comment "the file is not added to the runtime poller".
// newFile is like NewFile, but if called from OpenFile or Pipe
// (as passed in the kind parameter) it tries to add the file to
// the runtime poller.
func newFile(fd uintptr, name string, kind newFileKind) *File {

There is unfortunately no good way to support this.  The SetDeadline support requires that the file be in non-blocking mode.  When you call os.Pipe the pipes are created in non-blocking mode.  Standard input is normally in blocking mode.  We can't reasonably change the blocking mode of standard input, as that would affect any other programs that are using the same descriptor for standard input, including, in a common case, the shell after our program exits.
In the future 1.11 release, if you put the standard input pipe into nonblocking mode before starting the Go program, then SetDeadline will work.  That's the best we can do.
Closing this issue because I don't see any way to fix it.

@ianlancetaylor I am surprised that SetDeadline has not changed on its own file from blocking to non-blocking. Was was the reason for that? As the new API it could be a reasonable opt-in.
In any case, why not provide an explicit API for 1.11 to make a descriptor non-blocking or have a version of SetDeadline that makes so on supported file descriptors? Without that it seems it will be still impossible to write a command line go application like a trivial cat-like program without using system-specific hacks like opening /proc/self/fd/0. Upon receiving an  exit signal such application should close stdin and write all data that it read to stdout and exits.

I see how SetDeadline could help your case.  It's not that you want to set a deadline, it's that you want to interrupt the Read.  In this case, just call syscall.Close(0) and give the Read a few milliseconds.  It should have the same effect.

@ianlancetaylor In my Linux system (go1.10.1) syscall.Close(0) will not unblock an os.Stdin.Read.
Same effect with os.Stdin.Close, though calling that from a different goroutine doesn't seem to be explicitly supported.
Both do close os.Stdin in the sense that the next read will return an error immediately, but the current read will not unblock unless some data arrives.
You can always leave it blocked and os.Exit (or return from main) at will, but there is a race because the Read could unblock just after your program has decided to give up on it, and you would lose one Read's data.
Not so common need, but I can imagine other scenarios, for example to implement something like a read -t timeout similar to the shell builtin.

I agree that it won't unblock a read.  That's why I suggested waiting a few milliseconds to see if the read will complete.  It's not going to complete after the descriptor is closed.
Anyhow for your specific use case it seems to me that you can do this:
package main

import (
	"fmt"
	"os"
	"syscall"
	"time"
)

func main() {
	if err := syscall.SetNonblock(0, true); err != nil {
		panic(err)
	}
	f := os.NewFile(0, "stdin")
	go func() {
		time.Sleep(time.Millisecond)
		fmt.Println("setting deadline")
		if err := f.SetDeadline(time.Now().Add(-time.Millisecond)); err != nil {
			panic(err)
		}
	}()
	var buf [1]byte
	_, err := f.Read(buf[:])
	if err == nil {
		panic("Read succeeded")
	}
	fmt.Println("read failed as expected:", err)
	if err := syscall.SetNonblock(0, false); err != nil {
		panic(err)
	}
}

@ianlancetaylor

I agree that it won't unblock a read. That's why I suggested waiting a few milliseconds to see if the read will complete. It's not going to complete after the descriptor is closed.

My tests seem to suggest that it will complete if some data arrives:
$ { sleep 30; echo test; } | mygoprogram
test
copy err: read /dev/stdin: bad file descriptor

mygoprogram:
func main() {
    go func() {
        time.Sleep(time.Second)
        syscall.Close(0)
    }()
    _, err := io.Copy(os.Stdout, os.Stdin)
    fmt.Println("copy err:", err)
}

Thanks for your useful code sample; syscall.SetNonblock works for me and Read doesn't block.
If I run it like this: sleep 30 | mygoprogram I get:
read failed as expected: read stdin: resource temporarily unavailable

If I run it like this: echo test | mygoprogram I get:
panic: Read succeeded
[...]

The spawned goroutine doesn't seem to have a chance to start in either cases (even if I print something at the top I don't see it). You probably intended for it to be run with go1.11 that will have this feature.

You're right, I was assuming 1.11.  Any change in this area would only be in 1.11 anyhow, it would not be backported to 1.10.

I was hopping to have a solution in 1.11 without syscall.*, but rather via some os.* portable API. But single syscall.SetNonblock() followed by os.NewFile() does not look bad.

source: gharchive/issue

authors: ianlancetaylor ibukanov pam4

repo: golang/go

license_type: permissive

license_source: github-api


text:
doc: link to main entry point for modules documentation is not working and various module sections are not recognized as headers

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
Go 1.11 doc at golang.org:
https://golang.org/doc/go1.11
Does this issue reproduce with the latest release?
Yes.
Issue
Clicking on the modules link in the release notes (where the text is new concept called “modules,”) does not take you to the modules documentation because the fragment identifier does not exist any longer on the go command documentation page:
https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more
If you look at the sections present in the HTML documentation at https://golang.org/cmd/go, there are various sections that are not being treated as headers (including they don't show up in the table of contents, and they are not formatted as headers in the main body of the documentation).
'Bad' sections include:

The go.mod file
Edit go.mod from tools or scripts
Modules, module versions, and more

Interestingly, the documentation on tip.golang.org seems to not have this issue. For example, this works:
https://tip.golang.org/cmd/go/#hdr-Modules__module_versions__and_more
Perhaps some variation or re-occurrence of #26938 or similar...

This is also a 'bad' / missing section header that is present on tip.golang.org but missing at golang.org:

Gofmt (reformat) package sourcesGo

The 'bad' / missing section headers all seem to include at least one of (, ), or . characters, whereas the 'good' / present section headers do not have those characters.
It seems the golang.org doc might have been generated without either of these:
https://golang.org/cl/122407        // from ~2 months ago
https://golang.org/cl/129677        // from a ~week ago
Maybe the Go 1.10 or some other non-recent version was used to generate the Go 1.11 golang.org doc site?

This is due to #27205.

This has since been resolved. Thanks.

authors: FiloSottile andybons thepudds


text:
gccgo: etcd reportedly doesn't compile on gccgo

Pulling this into its own issue from https://github.com/golang/go/issues/19074#issuecomment-435929915 where @glaubitz says:

gccgo doesn't build all packages that golang builds. I know it's supposed to be compatible, but it isn't. I can provide a list of Debian packages which don't build.
See, for example, etcd: https://buildd.debian.org/status/fetch.php?pkg=etcd&arch=ppc64&ver=3.2.18%2Bdfsg-1&stamp=1539989343&raw=0
Fails with:

# github.com/coreos/etcd/pkg/cpuutil
src/github.com/coreos/etcd/pkg/cpuutil/endian.go:31:13: error: array bound is not constant
  if v := (*[intWidth]byte)(unsafe.Pointer(&i)); v[0] == 0 {
             ^
src/github.com/coreos/etcd/pkg/cpuutil/endian.go:31:51: error: array index out of bounds
  if v := (*[intWidth]byte)(unsafe.Pointer(&i)); v[0] == 0 {
                                                   ^

This is now fixed on GCC 7 branch, GCC 8 branch, and tip.  Sorry for the trouble.
@glaubitz: Please do report cases where the gc toolchain works and gccgo does not.  That's the only way we will know to fix the problems.  Thanks.

This is now fixed on GCC 7 branch, GCC 8 branch, and tip. Sorry for the trouble.

Thanks. That was a very quick fix.

Please do report cases where the gc toolchain works and gccgo does not. That's the only way we will know to fix the problems. Thanks.

This has been on my TODO list forever. I will try to take care of this this week. There are a couple of packages left that have issues.

@ianlancetaylor There are a couple of packages which actually build but where the testsuite fails:

https://buildd.debian.org/status/fetch.php?pkg=golang-github-ugorji-go-codec&arch=ppc64&ver=1.1.1-1&stamp=1539998621&raw=0
https://buildd.debian.org/status/fetch.php?pkg=golang-github-spf13-cobra&arch=ppc64&ver=0.0.3-1&stamp=1539989839&raw=0
https://buildd.debian.org/status/fetch.php?pkg=golang-golang-x-tools&arch=ppc64&ver=1%3A0.0~git20180501.d3e4ceb5%2Bds-1&stamp=1539989961&raw=0
https://buildd.debian.org/status/fetch.php?pkg=golint&arch=ppc64&ver=0.0%2Bgit20161013.3390df4-2&stamp=1539990009&raw=0
https://buildd.debian.org/status/fetch.php?pkg=govendor&arch=ppc64&ver=1.0.9%2Bds1-1&stamp=1539990039&raw=0
https://buildd.debian.org/status/fetch.php?pkg=hugo&arch=ppc64&ver=0.47.1-2&stamp=1539990488&raw=0

@glaubitz Do you know if they fail with gccgo on amd64 also, or also on PPC64?  Is there a way that I could find out?
There are of course various possible reasons for this to happen, ranging from a gccgo bug to a non-portable test.  I guess we'll just have to examine each one to see what is going on.

@ianlancetaylor Tested all these packages on amd64 with gccgo-8 instead of gc. They all fail the testsuite with gccgo but pass it with gc.

@glaubitz, feel free to file as many new bugs as you'd like. But reusing this one risks it being ignored, because our dashboard don't track closed issues.

@glaubitz, feel free to file as many new bugs as you'd like. But reusing this one risks it being ignored, because our dashboard don't track closed issues.

Sure, I‘m aware of that. This was just a quick check and you see there is actually a noticable amount of build issues with gccgo.
I have requested Debian‘s Go packaging team now to fix all their packages which have a hard build dependency to switch that to „golang-any“ such that these packages can attempt to build on the gccgo-only architectures. I expect around 50-60 packages which won’t build with gccgo out that. We‘ll see.

I expect around 50-60 packages which won’t build with gccgo out that. We‘ll see.

We look forward to the reports.
When you do report, though, be sure to note exactly what failed: actually building (e.g. compilation failures) vs test failures. The latter is often due to things like tests assuming certain gc-specific behaviors, like naming of symbols in stack frames. In any case, I assume you'll post links to failure logs, so it should be obvious.

authors: bradfitz glaubitz ianlancetaylor


text:
x/tools/go/packages: binary built with Go 1.11.1 but running with Go 1.10.4 can't import C

When I compile a program that uses go/packages with Go 1.11.1, but then run the program so that it shells out to a Go 1.10.4, then importing packages that use cgo fails.
$ cat $GOPATH/src/sandbox/bar/bar.go
package bar

import "C"

$ cat foo.go
package main

import (
	"fmt"

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

func main() {
	cfg := &packages.Config{
		Mode: packages.LoadAllSyntax,
	}
	pkgs, err := packages.Load(cfg, "sandbox/bar")
	fmt.Println(err)
	packages.PrintErrors(pkgs)
}

$ go version
go version go1.11.1 linux/amd64

# Building the program with Go 1.11.1
$ go build foo.go

# Running the program with Go 1.11.1, success
$ ./foo
<nil>

$ PATH=~/go/bin:$PATH go version
go version go1.10.4 linux/amd64

# Running the program with Go 1.10.4, fails
$ PATH=~/go/bin:$PATH ./foo
<nil>
/tmp/gopackages197109030/go-build/runtime_cgo/_cgo_gotypes.go:7:10: could not import runtime/cgo (no metadata for runtime/cgo)

# Plain go build has no issues.
$ PATH=~/go/bin:$PATH go build sandbox/bar; echo $?
0

# Debug output with Go 1.11.1 and Go 1.10.4 respectively
$ GOPACKAGESDEBUG=1 ./foo
2019/01/07 14:45:32 116.362087ms for GOROOT= GOPATH=/home/dominikh/prj/ GO111MODULE= PWD=/tmp go [list -e -json -compiled -test=false -export=false -deps=true -find=false -- sandbox/bar]

$ GOPACKAGESDEBUG=1 PATH=~/go/bin:$PATH ./foo
2019/01/07 14:45:50 8.65362ms for GOROOT= GOPATH=/home/dominikh/prj/ GO111MODULE= PWD=/tmp go [list -e -json -compiled -test=false -export=false -deps=true -find=false -- sandbox/bar]
2019/01/07 14:45:51 623.45465ms for GOROOT= GOPATH=/home/dominikh/prj/ GO111MODULE= PWD=/tmp go [list -e -json -- sandbox/bar]
2019/01/07 14:45:51 354.261038ms for GOROOT= GOPATH=/home/dominikh/prj/ GO111MODULE= PWD=/tmp go [list -e -json -- internal/race runtime runtime/cgo runtime/internal/atomic runtime/internal/sys sync sync/atomic syscall unsafe]
<nil>
/tmp/gopackages628127153/go-build/runtime_cgo/_cgo_gotypes.go:7:10: could not import runtime/cgo (no metadata for runtime/cgo)

This is surprising, since all version-specific behaviour in go/packages should be dynamically decided at runtime, not at compile time. Wiping ~/.cache/go-build has no effect, either.
/cc @matloob @ianthehat @mvdan

golang.org/cl/166537 has been submitted removing the 1.10 support.
Marking this "Obsolete".

authors: dominikh matloob


text:
cmd/go: go mod tidy gitlab.com error: RPC failed; result=22, HTTP code = 404

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

$ go version
go version go1.12.4 linux/amd64

Does this issue reproduce with the latest release?
Yes, it does.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/liuliqiang/soft/installed/dev/go/gopath"
GOPROXY=""
GORACE=""
GOROOT="/home/liuliqiang/soft/installed/dev/go/go"
GOTMPDIR=""
GOTOOLDIR="/home/liuliqiang/soft/installed/dev/go/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build306223789=/tmp/go-build -gno-record-gcc-switches"

What did you do?

i just input go mod tidy in the project root directory and get the following error:
go mod tidy Output
$ go mod tidy
go: finding k8s.io/apiserver/pkg/features latest
go: finding k8s.io/apiserver/pkg/authentication/user latest
go: finding k8s.io/apiserver/pkg/util/feature latest
go: finding k8s.io/apiserver/pkg/authentication/authenticator latest
go: finding k8s.io/apiserver/pkg/authentication/serviceaccount latest
go: finding k8s.io/apiserver/pkg/registry/generic latest
go: finding k8s.io/apiserver/pkg/authentication latest
go: finding k8s.io/apiextensions-apiserver/pkg/features latest
go: finding k8s.io/apiserver/pkg latest
go: finding k8s.io/apiserver/pkg/util latest
go: finding k8s.io/apiserver/pkg/registry latest
go: finding k8s.io/apiextensions-apiserver/pkg latest
go: finding k8s.io/cloud-provider/features latest
go: finding k8s.io/apiserver latest
go: finding k8s.io/apiextensions-apiserver latest
go: finding k8s.io/cloud-provider latest
go: finding k8s.io/apiserver/pkg/registry/rest latest
go: finding k8s.io/apiserver/pkg/util/feature/testing latest
go: finding k8s.io/apiserver/pkg/storage latest
go: finding k8s.io/apiserver/pkg/endpoints/request latest
go: finding k8s.io/apiserver/pkg/storage/names latest
go: finding k8s.io/apiserver/pkg/endpoints latest
go: finding github.com/prometheus/client_golang/prometheus latest
go: finding github.com/docker/distribution/reference latest
go: finding github.com/globalsign/mgo v0.0.0-20180905125535-1ca0a4f7cbcb
go: finding github.com/globalsign/mgo v0.0.0-20181015135952-eeefdecb41b8
go: finding modernc.org/mathutil v1.0.0
go: finding modernc.org/cc v1.0.0
go: finding modernc.org/golex v1.0.0
go: finding modernc.org/xc v1.0.0
go: finding modernc.org/strutil v1.0.0
go: modernc.org/golex@v1.0.0: git fetch -f https://gitlab.com/cznic/golex refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /home/liuliqiang/soft/installed/dev/go/gopath/pkg/mod/cache/vcs/9aae2d4c6ee72eb1c6b65f7a51a0482327c927783dea53d4058803094c9d8039: exit status 128:
        error: RPC failed; result=22, HTTP code = 404
        fatal: The remote end hung up unexpectedly
go: modernc.org/cc@v1.0.0: git fetch -f https://gitlab.com/cznic/cc refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /home/liuliqiang/soft/installed/dev/go/gopath/pkg/mod/cache/vcs/3dac616a9d80602010c4792ef9c0e9d9812a1be8e70453e437e9792978075db6: exit status 128:
        fatal: unable to access 'https://gitlab.com/cznic/cc/': TCP connection reset by peer
go: modernc.org/mathutil@v1.0.0: git fetch -f https://gitlab.com/cznic/mathutil refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /home/liuliqiang/soft/installed/dev/go/gopath/pkg/mod/cache/vcs/fb72eb2422fda47ac75ca695d44b06b82f3df3c5308e271486fca5e320879130: exit status 128:
        error: RPC failed; result=22, HTTP code = 404
        fatal: The remote end hung up unexpectedly
go: modernc.org/xc@v1.0.0: git fetch -f https://gitlab.com/cznic/xc refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /home/liuliqiang/soft/installed/dev/go/gopath/pkg/mod/cache/vcs/29fc2f846f24ce3630fdd4abfc664927c4ad22f98a3589050facafa0991faada: exit status 128:
        error: RPC failed; result=22, HTTP code = 404
        fatal: The remote end hung up unexpectedly
go: modernc.org/strutil@v1.0.0: git fetch -f https://gitlab.com/cznic/strutil refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /home/liuliqiang/soft/installed/dev/go/gopath/pkg/mod/cache/vcs/f48599000415ab70c2f95dc7528c585820ed37ee15d27040a550487e83a41748: exit status 128:
        error: RPC failed; result=22, HTTP code = 404
        fatal: The remote end hung up unexpectedly

and i go to directory: /home/liuliqiang/soft/installed/dev/go/gopath/pkg/mod/cache/vcs/f48599000415ab70c2f95dc7528c585820ed37ee15d27040a550487e83a41748 and watch the repo address, it show as following:
$ git remote -v
origin  https://gitlab.com/cznic/strutil (fetch)
origin  https://gitlab.com/cznic/strutil (push)

does it should be https://gitlab.com/cznic/strutil.git ？
What did you expect to see?
go mod tidy run success.
What did you see instead?
I get some error in the detail show upper.

This looks like a connectivity issue between you and gitlab.com, or perhaps a transient server error on the GitLab side.
Are you still able to reproduce this issue?
Here's what I got (using go build rather than go mod tidy, but with the same dependencies):
example.com$ go1.12.6 mod init example.com
go: creating new go.mod: module example.com

example.com$ go1.12.6 get modernc.org/golex@v1.0.0
go: finding modernc.org/golex v1.0.0
go: downloading modernc.org/golex v1.0.0
go: extracting modernc.org/golex v1.0.0
go: finding modernc.org/lex v1.0.0
go: finding modernc.org/lexer v1.0.0
go: downloading modernc.org/lex v1.0.0
go: extracting modernc.org/lex v1.0.0
go: downloading modernc.org/lexer v1.0.0
go: extracting modernc.org/lexer v1.0.0
go: finding modernc.org/fileutil v1.0.0
go: finding golang.org/x/exp/ebnf latest
go: downloading modernc.org/fileutil v1.0.0
go: extracting modernc.org/fileutil v1.0.0
go: finding golang.org/x/exp latest
go: downloading golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522
go: extracting golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522
go: finding github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802
go: finding golang.org/x/mobile v0.0.0-20190312151609-d3739f865fa6
go: finding golang.org/x/tools v0.0.0-20190312151545-0bb0c0a6e846
go: finding golang.org/x/sys v0.0.0-20190312061237-fead79001313
go: finding golang.org/x/image v0.0.0-20190227222117-0694c2d4d067
go: finding golang.org/x/text v0.3.0
go: finding golang.org/x/net v0.0.0-20190311183353-d8887717615a
go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a

example.com$ go1.12.6 build modernc.org/golex/...

example.com$

Thanks @bcmills ，After try at different times, i found maybe it's because there are some network issue in my machine.
Because when i get this error, i try command nslookup gitlab.com and i can't get the information for that.
I close this issue now.

authors: bcmills liuliqiang


text:
go: github.com/Sirupsen/logrus@v1.4.2: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"

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

$ go version
go version go1.12.6 linux/amd64

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
dingrui@ubuntu:~/projects/heterogeneous/client$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dingrui/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/dingrui/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/dingrui/projects/heterogeneous/client/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 -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build123236790=/tmp/go-build -gno-record-gcc-switches"

What did you do?
I want to use docker SDK, I find the same issue, but I don't know what they talking about.
  "github.com/moby/moby/client"
  "github.com/moby/moby/api/types"
  "github.com/moby/moby/api/types/container"
  "github.com/moby/moby/pkg/stdcopy"

go.mod
module heterogeneous

go 1.12

require (
	github.com/acroca/go-symbols v0.1.1 // indirect
	github.com/docker/distribution v2.7.1+incompatible // indirect
	github.com/docker/docker v1.13.1 // indirect
	github.com/docker/go-connections v0.4.0 // indirect
	github.com/docker/go-units v0.4.0 // indirect
	github.com/golang/protobuf v1.3.2
	github.com/keegancsmith/rpc v1.1.0 // indirect
	github.com/mdempsky/gocode v0.0.0-20190203001940-7fb65232883f // indirect
	github.com/moby/moby v0.7.3-0.20190731150326-928381b2215c
	github.com/opencontainers/go-digest v1.0.0-rc1 // indirect
	github.com/pkg/errors v0.8.1 // indirect
	github.com/ramya-rao-a/go-outline v0.0.0-20181122025142-7182a932836a // indirect
	github.com/sirupsen/logrus v1.4.2 // indirect
	github.com/stamblerre/gocode v0.0.0-20190327203809-810592086997 // indirect
	golang.org/x/crypto v0.0.0-20190701094942-4def268fd1a4 // indirect
	golang.org/x/lint v0.0.0-20190409202823-959b441ac422 // indirect
	golang.org/x/net v0.0.0-20190724013045-ca1201d0de80 // indirect
	golang.org/x/sys v0.0.0-20190712062909-fae7ac547cb7 // indirect
	golang.org/x/text v0.3.2 // indirect
	golang.org/x/tools v0.0.0-20190723021737-8bb11ff117ca // indirect
	google.golang.org/grpc v1.22.0
)

What did you expect to see?
How to solve this problem
What did you see instead?

See https://github.com/golang/go/issues/28489. This is because Sirupsen and sirupsen are different. If you try with tip, then you should get a better error message.

@agnivade is there any other action you think should be taken on this bug? Otherwise we can close this.

I agree. I was just waiting to let OP have a chance to respond. Thanks for following up.

authors: agnivade dingrui37 katiehockman


text:
x/sys/unix: ./mkall.sh failes with readlink: illegal option -- f

What version of Go are you using (go version)?
go version go1.13.4 darwin/amd64
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="amd64"
GOBIN=""
GOCACHE="/Users/uparmar/Library/Caches/go-build"
GOENV="/Users/uparmar/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/Users/uparmar/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13.4/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="0"
GOMOD="/Users/uparmar/Development/sys/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 -m64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/l7/x5hcvngd5m99k62kxv7srrdr0000gn/T/go-build301769780=/tmp/go-build -gno-record-gcc-switches"

What did you do?
export GOOS=linux
export GOARCH=amd64
./mkall.sh from sys/unix directory.

What did you expect to see?
No error
What did you see instead?
readlink: illegal option -- f
usage: readlink [-n] [file ...]
docker: Error response from daemon: create .: volume name is too short, names should be at least two alphanumeric characters.

darwin readlink doesn't support -f option.


text:
x/build/cmd/gopherbot: for repos not mirrored to GitHub, close issues listed under "Fixes" when CL is submitted (to an active branch)

I recently sent a series of CLs (ending with https://golang.org/cl/232742) to fix a gollvm bug, https://github.com/golang/go/issues/38728.
Gopherbot noticed the CLs as they were put up, adding "mentioned" notices to the issue:
 Change https://golang.org/cl/232742 mentions this issue: gollvm: add workaround for hard-wired cf-protection=branch
however when the CLs were merged, it didn't take any actions. In particular the bot didn't annotate the issue with the merge, and didn't auto-close the bug.
Wondering if there is something I did wrong with the CLs (I used the usual "Updates/Fixes" notation), or if there is something else gumming up the works?
Any pointers appreciated. Thanks.

@dmitshur @andybons

I think this is because gollvm is only on Gerrit, not mirrored to GitHub.

Ah. OK, I will keep that in mind.

/cc @cagedmantis (and me)

I believe @cherrymui's analysis in https://github.com/golang/go/issues/38961#issuecomment-625955528 is accurate. The gollvm repo isn't mirrored to GitHub, so we can't rely on issues getting closed that way.
Instead, gopherbot needs to close the corresponding issue manually. We already have logic in gopherbot to do this for issues that are merged to non-master branches, see here.
Another relevant issue here is https://github.com/golang/go/issues/29599#issuecomment-452073954. It's likely we need to resolve that before we can implement this, otherwise gopherbot would close not only issue mentioned in "Fixes #123", but also in "Updates #456" lines.

I think we're running into this issue on the dev.fuzz branch. See https://github.com/golang/go/issues/46633#issuecomment-870805962 and https://github.com/golang/go/issues/46632 which we would have expected to be closed when they were merged since they have the Fixes #XXXXX line, but were not.

authors: cherrymui dmitshur katiehockman thanm toothrot


text:
cmd/go/internal/bug: the implementation should have more comments

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

$ go version
go version devel go1.17-6edd573218 Tue Apr 27 11:55:52 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/manlio/.local/bin"
GOCACHE="/home/manlio/.cache/go-build"
GOENV="/home/manlio/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE="*.local"
GOMODCACHE="/home/manlio/.local/lib/go/pkg/mod"
GONOPROXY=""
GONOSUMDB="*.local"
GOOS="linux"
GOPATH="/home/manlio/.local/lib/go:/home/manlio/src/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/manlio/src/contrib/go/go.googlesource.com/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/manlio/src/contrib/go/go.googlesource.com/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.17-6edd573218 Tue Apr 27 11:55:52 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build955556188=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version devel go1.17-6edd573218 Tue Apr 27 11:55:52 2021 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel go1.17-82aae74cb5 Tue Apr 27 14:48:20 2021 +0200
uname -sr: Linux 5.11.16-arch1-1
/usr/lib/libc.so.6: GNU C Library (GNU libc) release release version 2.33.
gdb --version: GNU gdb (GDB) 10.1

What did you do?
Currently, the implementation of the go bug command is a bit confusing.

go version is obtained using runtime.Version
go env is obtained invoking os.Executable env, falling back to GOROOT/bin/go env
go env output is OS specific (UNIX, Windows and plan9), but it is not clear if using only UNIX output is possible
go version is printed a second time, using the label GOROOT/bin/go version, invoking GOROOT/bin/go env.
The code don't says why there is a second version printed; is it for compatibility reasons?
Another issue is that the go command invoked may be different from the one invoked in 2.
Is this the intended behavior?
The label GOROOT/bin/go tool compile has the same issues as 4.

Note that if go env output is allowed to be in the UNIX style for all platforms, it will possible to use the envcmd API instead of invoking go env, as it was done for go version.
Here is a simple patch:
diff --git a/src/cmd/go/internal/bug/bug.go b/src/cmd/go/internal/bug/bug.go
index df63c579d9..c0dff1b831 100644
--- a/src/cmd/go/internal/bug/bug.go
+++ b/src/cmd/go/internal/bug/bug.go
@@ -20,6 +20,7 @@ import (

 	"cmd/go/internal/base"
 	"cmd/go/internal/cfg"
+	"cmd/go/internal/envcmd"
 	"cmd/go/internal/web"
 )

@@ -90,17 +91,23 @@ func printEnvDetails(w io.Writer) {
 	fmt.Fprintf(w, "### What operating system and processor architecture are you using (`go env`)?\n\n")
 	fmt.Fprintf(w, "go env Output

\n")
 	fmt.Fprintf(w, "$ go env\n")
-	goexe, err := os.Executable()
-	if err != nil {
-		goexe = filepath.Join(runtime.GOROOT(), "bin/go")
-	}
-	printCmdOut(w, "", goexe, "env")
+	printGoEnv(w)
 	printGoDetails(w)
 	printOSDetails(w)
 	printCDetails(w)
 	fmt.Fprintf(w, "
\n\n")
 }

+func printGoEnv(w io.Writer) {
+	env := envcmd.MkEnv()
+	env = append(env, envcmd.ExtraEnvVars()...)
+	env = append(env, envcmd.ExtraEnvVarsCostly()...)
+
+	for _, e := range env {
+		fmt.Fprintf(w, "%s=\"%s\"\n", e.Name, e.Value)
+	}
+}
+
 func printGoDetails(w io.Writer) {
 	printCmdOut(w, "GOROOT/bin/go version: ", filepath.Join(runtime.GOROOT(), "bin/go"), "version")
 	printCmdOut(w, "GOROOT/bin/go tool compile -V: ", filepath.Join(runtime.GOROOT(), "bin/go"), "tool", "compile", "-V")

I don't really see a bug here, in the sense of behavior that is incorrect and should change.  Discussion about the code can be on golang-nuts.
Also, please don't post patches on the issue tracker.  Please only send them via GitHub or Gerrit.  Patches on the issue tracker don't have any copyright licensing, so we can't use them.  Thanks.  Please do go ahead and send in the patch via GitHub or Gerrit if you want somebody to review it.

cc @bcmills
Thanks for filing this. As Ian said, this is probably not the best place to discuss this or to send patches. Thanks.

Excluding the patch (that was only an example, not intended to be used/submitted), isn't code not well documented and possibly ambiguous considered an issue?
Thanks.

If the code is unclear or not well documented (and I agree that this particular code is at least the latter), it's fine to send a CL to improve the documentation, with or without an issue filed.
To the specific questions:

go version is obtained using runtime.Version

Yes. That is a recent and intentional change.

go env is obtained invoking os.Executable env, falling back to GOROOT/bin/go env

I think that falling back to go env is probably a mistake, but I expect that code path is taken approximately never, so it's a very benign mistake.
Better still would be to avoid starting a go subprocess entirely.

go env output is OS specific (UNIX, Windows and plan9), but it is not clear if using only UNIX output is possible

The go env output from go bug should exactly match what the user would see if they ran go env with the same go executable. So it isn't feasible to emit only UNIX output.

go version is printed a second time, using the label GOROOT/bin/go version, invoking GOROOT/bin/go env.
The code don't says why there is a second version printed; is it for compatibility reasons?

A bit of code archaeology reveals that those lines were added in CL 32643, for #15877. They are there to help diagnose mismatches between the user's GOROOT and PATH, which was a more common error in the past than it is today (because in most cases users no longer need to set GOROOT explicitly), but is still surprisingly common (I think due to users working from outdated tutorials found around the web).

Another issue is that the go command invoked may be different from the one invoked in 2.
Is this the intended behavior?

Yes.

The label GOROOT/bin/go tool compile has the same issues as 4.

From the discussion on #15877, it appears that is intended to diagnose the case when cmd/compile is built at a version that doesn't match cmd/go, but I haven't the faintest idea why we would expect that to come up often enough to be worth including in go bug. The discussion on #15877 mentions using it to diagnose #15372, but #15372 was fixed a long time ago.

About 3., formatting an environment variable takes a lot of code:
https://github.com/golang/go/blob/4c1a7ab49c4c68907bc7f7f7f776edd9116584a5/src/cmd/go/internal/envcmd/env.go#L350
So, in order to avoid starting a go subprocess, the envcmd package should export a FormatEnv function, so I'm not sure it is worth the effort.
Thanks.

authors: bcmills cherrymui ianlancetaylor perillo


text:
x/build/cmd/releasebot: pushing issues and closing milestone didn't work for major release

There seems to be a problem in pushIssues for major releases. It's documented to move issues for major releases:
// pushIssues moves open issues to the milestone of the next release of the same kind.
// For major releases, it's the milestone of the next major release (e.g., 1.14 → 1.15).
// For minor releases, it's the milestone of the next minor release (e.g., 1.14.1 → 1.14.2).
// For other release types, it does nothing.
func (w *Work) pushIssues()

Yet it didn't move issues for the Go 1.17 release, issue #47719.
The milestone wasn't closed either, despite the log message:
2021/08/16 17:01:07 closing milestone go1.17

From a quick look, a hypothesis is that gopherbot may have incorrectly thought milestone was "go1.17" (lower-case 'g'), but it's actually "Go1.17", and maybe GitHub is case sensitive (or has become). Edit: This hypothesis wasn't right.
CC @golang/release, @mknyszek.

It worked fine for Go 1.18, moving 8 non-release-blocking issues from Go1.18 milestone to Go1.19 (as seen here).
There were some changes that might've helped, so maybe it was that, or maybe something else. Either way, closing because there's nothing more to do here for now.


text:
Add Unwrappable interface to errors package

I think it would be great if there was an Unwrappable interface in the errors package to show that it's possible to unwrap structured errors without having to refer to the source code for Unwrap.
For example, can I unwrap MyError if I add a receiver Unwrap() error?
type MyError struct {
    Err        error
    StatusCode int
}

func (e MyError) Unwrap() error {
    return e.Err
}

Duplicate of #35306

authors: gerobinson seankhliao


text:
runtime: Stack trace of bound method of embedded interface inside slice causes an infinite loop

(Apologies for the overly long title, but I've only been able to isolate this to that specific case.)
What version of Go are you using (go version)?
Tested on 1.18rc1 and master.

% go version
go version go1.18rc1 darwin/arm64

% ../bin/go version
go version devel go1.19-936c7fbc1c 2022-02-28 22:24:58 +0000 linux/amd64

Does this issue reproduce with the latest release?
Not with the latest stable release (Go 1.17.7). Yes with the latest unstable release.
What operating system and processor architecture are you using (go env)?
Tested on macOS with Go 1.18rc1, and on Linux with 1.18rc1 and master.
go env Output
macOS
% go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/abg/Library/Caches/go-build"
GOENV="/Users/abg/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/abg/go/pkg/mod"
GONOPROXY="*.uber.internal"
GONOSUMDB="*.uber.internal"
GOOS="darwin"
GOPATH="/Users/abg/go"
GOPRIVATE="*.uber.internal"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/abg/.gimme/versions/go1.18rc1.darwin.arm64"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/abg/.gimme/versions/go1.18rc1.darwin.arm64/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.18rc1"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/abg/Uber/bound-method-loop-repro/go.mod"
GOWORK=""
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/fk/y8ktgnhs5pnd6kh4tsck5wqr0000gn/T/go-build2122832388=/tmp/go-build -gno-record-gcc-switches -fno-common"

Linux
% ../bin/go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/go/pkg/mod"
GONOPROXY="*.uber.internal"
GONOSUMDB="*.uber.internal"
GOOS="linux"
GOPATH="/home/user/go"
GOPRIVATE="*.uber.internal"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/user/src/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/user/src/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.19-936c7fbc1c 2022-02-28 22:24:58 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/user/src/go/repro/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3005549744=/tmp/go-build -gno-record-gcc-switches"

What did you do?
In the course of testing Go 1.18rc1 on our internal codebase, I ran into a test that timed out. Upon investigation, I was able to isolate the issue to code with roughly the following structure:
There are two interfaces Outer and Inner where Outer only embeds Inner. Given a reference to Outer, a function builds a slice with a bound reference to the method defined on Inner. A different function takes this slice and calls that bound method. The method attempts to capture its stack trace.
The following code reproduces this issue on Go 1.18rc1 and master.
package repro

import (
	"errors"
	"runtime"
	"testing"
)

type Outer interface{ Inner }

type impl struct{}

func New() Outer { return &impl{} }

type Inner interface {
	DoStuff() error
}

func (a *impl) DoStuff() error {
	return newError()
}

func newError() error {
	// Pretend this is an error library that captures a stack trace.
	stack := make([]uintptr, 50)
	length := runtime.Callers(2, stack[:])
	stack = stack[length:]
	_ = stack

	return errors.New("great sadness")
}

func TestRepro(t *testing.T) {
	funcs := listFuncs(New())
	for _, f := range funcs {
		_ = f()
	}
}

// Inlining this function into TestRepro resolves the issue.
func listFuncs(outer Outer) []func() error {
	return []func() error{outer.DoStuff}
}

https://go.dev/play/p/l7rdkzfwX3I?v=gotip
What did you expect to see?
The code to run and return instantly.
What did you see instead?
It loops forever.
If I terminate it with SIGQUIT (Ctrl-\) the core dump includes the following:
Core dump
=== RUN   TestRepro
SIGQUIT: quit
PC=0x10219acec m=0 sigcode=0

goroutine 0 [idle]:
runtime.pcdatavalue({0x10231d1d0, 0x1023270a0}, 0x2000, 0x16dcb29c8, 0x129113fff)
	/Users/abg/.gimme/versions/go1.18rc1.darwin.arm64/src/runtime/symtab.go:1069 +0xc
runtime.gentraceback(0x16dcb2cc8?, 0x10233e7a0?, 0x0?, 0x14000113380, 0x2, 0x14000044d58, 0x32, 0x0, 0xe9320001021adb08?, 0x0)
	/Users/abg/.gimme/versions/go1.18rc1.darwin.arm64/src/runtime/traceback.go:360 +0x1194
runtime.callers.func1()
	/Users/abg/.gimme/versions/go1.18rc1.darwin.arm64/src/runtime/traceback.go:903 +0x60
runtime.systemstack()
	/Users/abg/.gimme/versions/go1.18rc1.darwin.arm64/src/runtime/asm_arm64.s:237 +0x6c

goroutine 18 [running]:
runtime.systemstack_switch()
	/Users/abg/.gimme/versions/go1.18rc1.darwin.arm64/src/runtime/asm_arm64.s:194 +0x8 fp=0x14000044cc0 sp=0x14000044cb0 pc=0x1021aa9d8
runtime.callers(0x0?, {0x14000044d58?, 0x0?, 0x1021f9e60?})
	/Users/abg/.gimme/versions/go1.18rc1.darwin.arm64/src/runtime/traceback.go:902 +0x7c fp=0x14000044d30 sp=0x14000044cc0 pc=0x1021a487c
runtime.Callers(...)
	/Users/abg/.gimme/versions/go1.18rc1.darwin.arm64/src/runtime/extern.go:235
github.com/abhinav/bound-method-loop-repro.newError()
	/Users/abg/bound-method-loop-repro/getter_test.go:26 +0x50 fp=0x14000044ef0 sp=0x14000044d30 pc=0x1022300c0
github.com/abhinav/bound-method-loop-repro.(*impl).DoStuff(0x606522a492a?)
	/Users/abg/bound-method-loop-repro/getter_test.go:20 +0x20 fp=0x14000044f00 sp=0x14000044ef0 pc=0x102230050
github.com/abhinav/bound-method-loop-repro.listFuncs(...)
	/Users/abg/bound-method-loop-repro/getter_test.go:42
github.com/abhinav/bound-method-loop-repro.listFuncs(...)
	/Users/abg/bound-method-loop-repro/getter_test.go:42
github.com/abhinav/bound-method-loop-repro.listFuncs(...)
	/Users/abg/bound-method-loop-repro/getter_test.go:42
github.com/abhinav/bound-method-loop-repro.listFuncs(...)
[... snip ...]

Worth noting that the core dump also loops infinitely—or at least for 5 seconds (I didn't give it longer)—on reporting this line of code:
	return []func() error{outer.DoStuff}

Additional information
Worth noting that if I run the same with delve, it passes:
% dlv version
Delve Debugger
Version: 1.8.0
Build: $Id: 6a6c9c332d5354ddf1f8a2da3cc477bd18d2be53 $

% dlv test
Type 'help' for list of commands.
(dlv) c
PASS
Process 31721 has exited with status 0

Passes with 1.17 and gccgo, fails with 1.18.
CC @aclements @prattmic @mknyszek

The method wrapper Outer.DoStuff-fm has an inline tree attached to it saying the whole function body is inlined from listFuncs, which is clearly incorrect.
The infinite loop comes from that in that malformed inline tree, the "parent PC" of the entry of Outer.DoStuff-fm points to itself.

The method wrapper is generated at https://cs.opensource.google/go/go/+/master:src/cmd/compile/internal/walk/closure.go;l=238 , which sets Pos conditionally. For this case the condition seems false, which leaves base.Pos whatever it is before.

Why we don't set the Pos to AutogeneratedPos, like most compiler-generated functions do?
While the comment says "Set line number equal to the line number where the method is declared", the code seems to set it to where it is referenced (the selection expression)? Why?
(If we do want to use the Pos of that selection expression) why that selection expression has unknown Pos?

cc @mdempsky

Why we don't set the Pos to AutogeneratedPos, like most compiler-generated functions do?

I think just historical. If changing it to AutogeneratedPos works and fixes this issue, I think doing that instead sounds good.

While the comment says "Set line number equal to the line number where the method is declared", the code seems to set it to where it is referenced (the selection expression)? Why?

dot.Selection points to the selected method itself, not the AST identifier's position. (Were you thinking of go/ast's SelectorExpr.Sel?)

The CL above tries to use AutogeneratedPos. It seems to work. Not sure if this is the best solution, though.

If the trybots are happy with AutogeneratedPos, then I'm happy. :)

@cherrymui @mdempsky, thanks for the quick diagnosis and fix!
This issue appears to be tagged for the Go 1.19 milestone.
If I think this fix should be included in 1.18, should I create a separate backport request?
Thanks!

authors: abhinav cherrymui ianlancetaylor mdempsky


text:
x/tools/gopls: either stop trimming the AST or don't print the confusing errors that result

In the latest version of gopls i get errors like
17:19:07 falling back to safe trimming due to type errors: [/usr/local/google/home/pjw/go/pkg/mod/github.com/google/go-cmp@v0.5.7/cmp/options.go:469:24: invalid operation: signed shift count iota (untyped int constant 0) requires go1.13 or later
that result from trimming the AST.
I am running go 1.18.
These are confusing, so either they or their cause should be suppressed. Was AST trimming put in for some sort of performance improvement?

this is a duplicate. closed


text:
affected/package: go mod download segfault on arm with with 1.18

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

$ go version
go version go1.18.1 linux/arm

Does this issue reproduce with the latest release?
Run go mod download in Ubuntu22.04 with qemu 7.0 (http://ftp.de.debian.org/debian/pool/main/q/qemu/qemu-user-static_7.0+dfsg-7_amd64.deb) and get a segfault:
root@f683ddd33818:/build# go mod download
qemu: Unsupported syscall: 403
qemu: Unsupported syscall: 397
qemu: Unsupported syscall: 397
qemu: Unsupported syscall: 398
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
qemu: Unsupported syscall: 403
qemu: Unsupported syscall: 403

Note: This is was done in a Windows Docker environment with the WSL2 Kernel for docker. In a virtual machine running qemu, the go install ... crashes afterwards.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.18"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.18/pkg/tool/linux_arm"
GOVCS=""
GOVERSION="go1.18.1"
GCCGO="gccgo"
GOARM="6"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/build/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build914925232=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Just execute go mod download.
What did you expect to see?
Go mod download to download the packages
What did you see instead?
go mod download segfaulted.

Please try with Go 1.18.3 first - your version is somewhat out of date and there have been numerous fixes since then.

Same error:
root@0cfd94a25424:/build# /usr/local/go/bin/go mod download
qemu: Unsupported syscall: 403
qemu: Unsupported syscall: 397
qemu: Unsupported syscall: 397
qemu: Unsupported syscall: 397
qemu: Unsupported syscall: 398
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
qemu: Unsupported syscall: 403
root@0cfd94a25424:/build# /usr/local/go/bin/go version
qemu: Unsupported syscall: 403
qemu: Unsupported syscall: 397
qemu: Unsupported syscall: 397
qemu: Unsupported syscall: 397
qemu: Unsupported syscall: 398
go version go1.18.3 linux/arm
qemu: Unsupported syscall: 403

Are you running go inside user mode qemu inside a docker container on windows with a WSL2 backend?

Yes i'm running go inside a user mode qemu inside a docker with WSL2 backend.

https://github.com/golang/go/issues/1508 tracks actually supporting and testing user-mode qemu. Fixing that bug by adding a builder and making all tests pass would surely need to fix this problem as well, so I'm not sure that keeping more issues open is necessary. That issue already functions as an umbrella to track user-mode qemu support.

Given the Unsupported syscall messages, this looks to me like a QEMU bug that happens to be triggered by running a Go program.
I suggest escalating it to the QEMU maintainers. I don't think there's anything we can plausibly do on the Go side without a fix (and active maintainer) for #1508.

authors: ProLoDs bcmills mvdan seankhliao


text:
security: fix CVE-2022-30635

This is a PRIVATE issue tracked in http://b/231318421 and fixed by http://tg/1484771
This is for 1.17.12 and 1.18.4.
/cc https://github.com/orgs/golang/teams/security and https://github.com/orgs/golang/teams/release

@gopherbot please open backport issues for this security fix


text:
image/color: NRGBA provides alpha-premultiplied values, and RGBA provides non-alpha-premultiplied values. The doc claims the exact opposite.

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

$ go version
go version go1.19 linux/amd64

Does this issue reproduce with the latest release?
Yes. This issue has been present in every version since weekly.2011-10-06.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/marc/.cache/go-build"
GOENV="/home/marc/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/marc/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/marc/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3829980571=/tmp/go-build -gno-record-gcc-switches"

What did you do?

https://go.dev/play/p/ckINKpbqQ2L
What did you expect to see?
This should be alpha-premultiplied (0 0 0 0): 0 0 0 0
This should be alpha-premultiplied (0 0 0 0): 0 0 0 0
This shouldn't be alpha-premultiplied (0 32639 65535 0): 0 32639 65535  0
This shouldn't be alpha-premultiplied (0 2147483647 4294967295 0): 0 2147483647 4294967295 0
What did you see instead?
This should be alpha-premultiplied (0 0 0 0): 0 32639 65535 0
This should be alpha-premultiplied (0 0 0 0): 0 32767 65535 0
This shouldn't be alpha-premultiplied (0 32639 65535 0): 0 0 0 0
This shouldn't be alpha-premultiplied (0 2147483647 4294967295 0): 0 0 0 0

I may be completely misinterpreting the documentation, or even misinterpreting the concept of alpha-premultiplication, but based on the Wikipedia page for Alpha compositing the current behavior is inverted.

Also, the 64bit color.RGBA64 and color.NRGB64 return uint32's. This does not feel correct and is not what I expected. However, the documentation does not specify the range of color.RGB64() so this may be the intended behavior. Either way, I think the documentation could be made clearer.
Would I need to start a new issue for this problem specifically?

I think you indeed misinterpreted the documentation. For RGBA, the pre-multiplication means that the R, G, B components in the struct are already multiplied with A, so it doesn't need to multiply again. For NRGBA, it is the opposite, i.e. the components in the struct is not already multiplied, so it needs to be multiplied.
Also, see https://pkg.go.dev/image/color#RGBA64
// An alpha-premultiplied color component c has been scaled by alpha (a),
// so has valid values 0 <= c <= a.

So color.RGBA{0, 0x7F, 0xFF, 0} is not actually valid.
For your second comment, the RGBA method satisfies the https://pkg.go.dev/image/color#Color interface. Note that for RGBA64 and NRGBA64, the total bits of R+G+B+A is 64, not each individual component is 64-bit, so returning uint32 is still enough.
Closing as working as intended. Thanks.

Thanks, I had already started working all of this out in the time after submitting this. I still feel like something could be changed to make it harder to accidentally create an invalid struct. Maybe it'd be worth it to add a NewColor function that takes straight r,g,b,a values and returns a valid color.RGBA object, doing the multiplication for the developer.
Otherwise, developers will keep making their own structs manually which often results in incorrect behavior. But, it could be argued that it's up to the developers to avoid making this kind of mistake.

Since https://pkg.go.dev/image/color#RGBA already documents that

An alpha-premultiplied color component C has been scaled by alpha (A), so has valid values 0 <= C <= A.

I think it is expected that the user would not create invalid values. For a NewColor (or perhaps NewRGBA) function, it is unclear what to do if the given input is invalid. Panic? Maybe, but doesn't sound much better than just documenting the requirement. So maybe not worth adding a new API. Thanks.

Commenting here since this currently is the first Google result for golang nrgba premultiplication.
All the handling of alpha values by the standard library is a bit funky. The premultiplication done by method RGBA() of type color.NRGBA occurs without any color space conversions, which while that isn't in conflict with the documentation, is not usually what you would want. The alpha value generally indicates amount of coverage over the pixel below it, whatever it is going to be, so it must not be biased towards either end of the luminosity spectrum and thus needs to be applied in linear RGB. However, when I use the png package to load a PNG with an alpha channel, I get the unaltered values as NRGBA color model, meaning NRGBA is then storing sRGB data. I had been confused for the past hour or so why an image of mine with transparency had dark outlines when magnifying interpolation is happening, while the non-premultiplied equivalent looked fine, and I confirmed this to be the cause. As I said, considering the documentation, this is not a bug (there is no indication that NRGBA is in any color space of any sort), it's just a subtle design detail that I did not expect, and I think other developers should be aware of as well.

authors: ScienceMarc Zyl9393 cherrymui


text:
go/types, types2: consider interpreting type X [P]T as generic type with missing constraint if P is not declared

See #55961 for back story.

The argument is that it is more likely that
type X[P] <some type literal>

where P is not defined, is a generic type declaration with missing constraint (e.g., any) rather than an array type declaration with missing array length P.

cc: @mdempsky @findleyr for feedback.

This sounds reasonable to me.
One concern is how to handle follow-on errors. E.g., I think ideally go/types would only report "P is undeclared" for the package below, though even today it also reports "cannot index a (variable of type X)". So it seems okay if we instead report a spurious "cannot use X without instantiation" error.
package p

type X [P]int

var a X
var b int = a[0]

Per discussion on the CL, while it's not hard to interpret an array declaration with an undefined length identifier as a generic type declaration with a missing type constraint, the re-interpretation leads to incorrect population of the various type-checker maps used by tools. Instead, opt for a better error message about the invalid array length.

authors: griesemer mdempsky


text:
net/http/pprof: consistently failing with unexpected signal during runtime execution on plan9-amd64-0intro

#!watchflakes
post <- goos == "plan9" && goarch == "amd64" && pkg == "net/http/pprof" && `unexpected signal during runtime execution`

https://build.golang.org/log/2e297537e3f24155c6ecb5139c2bcc1417279ce4:

fatal error: unexpected signal during runtime execution
[signal sys: trap: code=0x0 addr=0x0 pc=0x257227]

runtime stack:
runtime.throw({0x537f29?, 0x45b7b028?})
	/tmp/workdir-gnot/go/src/runtime/panic.go:1077 +0x65 fp=0x7fffffffe968 sp=0x7fffffffe938 pc=0x236e45
runtime.sigpanic()
	/tmp/workdir-gnot/go/src/runtime/os_plan9.go:75 +0x48c fp=0x7fffffffe9e8 sp=0x7fffffffe968 pc=0x232fcc
runtime.fpTracebackPCs(...)
	/tmp/workdir-gnot/go/src/runtime/trace.go:954
runtime.traceStackID(0x4b99f63c9f6?, {0x45b7b018, 0x7fffffffea78?, 0x80}, 0x2000120?)
	/tmp/workdir-gnot/go/src/runtime/trace.go:928 +0x207 fp=0x7fffffffea30 sp=0x7fffffffe9e8 pc=0x257227
runtime.traceEventLocked(0x9000?, 0x10?, 0x48006d00?, 0x4803d1d0, 0x4, 0x0, 0x1, {0x7fffffffeb80, 0x1, 0x1})
	/tmp/workdir-gnot/go/src/runtime/trace.go:771 +0x292 fp=0x7fffffffeaa8 sp=0x7fffffffea30 pc=0x256972
runtime.traceEvent(0x1d?, 0x1, {0x7fffffffeb80, 0x1, 0x1})
	/tmp/workdir-gnot/go/src/runtime/trace.go:703 +0xa9 fp=0x7fffffffeb10 sp=0x7fffffffeaa8 pc=0x256669
runtime.traceGomaxprocs(...)
	/tmp/workdir-gnot/go/src/runtime/trace.go:1426
runtime.procresize(0x1)
	/tmp/workdir-gnot/go/src/runtime/proc.go:5013 +0x70 fp=0x7fffffffebd0 sp=0x7fffffffeb10 pc=0x242e70
runtime.startTheWorldWithSema(0x0)
	/tmp/workdir-gnot/go/src/runtime/proc.go:1351 +0x7d fp=0x7fffffffec38 sp=0x7fffffffebd0 pc=0x23bc5d
runtime.startTheWorld.func1()
	/tmp/workdir-gnot/go/src/runtime/proc.go:1187 +0x15 fp=0x7fffffffec50 sp=0x7fffffffec38 pc=0x25f9b5
runtime.systemstack()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:509 +0x4d fp=0x7fffffffec60 sp=0x7fffffffec50 pc=0x26506d

goroutine 18 [running]:
runtime.systemstack_switch()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:474 +0x8 fp=0x48236c58 sp=0x48236c48 pc=0x265008
runtime.startTheWorld()
	/tmp/workdir-gnot/go/src/runtime/proc.go:1187 +0x25 fp=0x48236c88 sp=0x48236c58 pc=0x23b725
runtime.startTheWorldGC()
	/tmp/workdir-gnot/go/src/runtime/proc.go:1220 +0x13 fp=0x48236cb0 sp=0x48236c88 pc=0x23b873
runtime.StartTrace()
	/tmp/workdir-gnot/go/src/runtime/trace.go:336 +0x2f6 fp=0x48236d38 sp=0x48236cb0 pc=0x255756
runtime/trace.Start({0x45d969d8?, 0x48029580})
	/tmp/workdir-gnot/go/src/runtime/trace/trace.go:125 +0xa8 fp=0x48236d90 sp=0x48236d38 pc=0x2c7a68
net/http/pprof.Trace({0x5af9a0, 0x48029580}, 0x480306f0?)
	/tmp/workdir-gnot/go/src/net/http/pprof/pprof.go:170 +0x29d fp=0x48236e28 sp=0x48236d90 pc=0x49c4fd
net/http/pprof.TestHandlers.func1(0x480e3520)
	/tmp/workdir-gnot/go/src/net/http/pprof/pprof_test.go:60 +0x118 fp=0x48236f70 sp=0x48236e28 pc=0x49eef8
testing.tRunner(0x480e3520, 0x48022d90)
	/tmp/workdir-gnot/go/src/testing/testing.go:1595 +0x139 fp=0x48236fc0 sp=0x48236f70 pc=0x2d48d9
testing.(*T).Run.func1()
	/tmp/workdir-gnot/go/src/testing/testing.go:1648 +0x25 fp=0x48236fe0 sp=0x48236fc0 pc=0x2d5905
runtime.goexit()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:1622 +0x1 fp=0x48236fe8 sp=0x48236fe0 pc=0x266e81
created by testing.(*T).Run in goroutine 9
	/tmp/workdir-gnot/go/src/testing/testing.go:1648 +0x3bd

goroutine 1 [chan receive]:
runtime.gopark(0x480b99e0?, 0x20cbea?, 0x80?, 0xa1?, 0x18?)
	/tmp/workdir-gnot/go/src/runtime/proc.go:387 +0xce fp=0x4823d978 sp=0x4823d958 pc=0x2396ee
runtime.chanrecv(0x48062380, 0x480b9a5f, 0x1)
	/tmp/workdir-gnot/go/src/runtime/chan.go:583 +0x3cd fp=0x4823d9f0 sp=0x4823d978 pc=0x20536d
runtime.chanrecv1(0x83dcc0?, 0x4c1880?)
	/tmp/workdir-gnot/go/src/runtime/chan.go:442 +0x12 fp=0x4823da18 sp=0x4823d9f0 pc=0x204f92
testing.(*T).Run(0x48007860, {0x52af8b?, 0x175f5203c198a962?}, 0x55b3d8)
	/tmp/workdir-gnot/go/src/testing/testing.go:1649 +0x3d8 fp=0x4823dad8 sp=0x4823da18 pc=0x2d5798
testing.runTests.func1(0x83eb40?)
	/tmp/workdir-gnot/go/src/testing/testing.go:2054 +0x3e fp=0x4823db28 sp=0x4823dad8 pc=0x2d7a5e
testing.tRunner(0x48007860, 0x480b9c40)
	/tmp/workdir-gnot/go/src/testing/testing.go:1595 +0x139 fp=0x4823db78 sp=0x4823db28 pc=0x2d48d9
testing.runTests(0x4807db80?, {0x837740, 0x3, 0x3}, {0x21303f?, 0x480b9d00?, 0x83e3a0?})
	/tmp/workdir-gnot/go/src/testing/testing.go:2052 +0x465 fp=0x4823dc70 sp=0x4823db78 pc=0x2d7945
testing.(*M).Run(0x4807db80)
	/tmp/workdir-gnot/go/src/testing/testing.go:1925 +0x6d3 fp=0x4823deb8 sp=0x4823dc70 pc=0x2d6233
main.main()
	_testmain.go:51 +0x19c fp=0x4823df38 sp=0x4823deb8 pc=0x4a117c
runtime.main()
	/tmp/workdir-gnot/go/src/runtime/proc.go:256 +0x2dd fp=0x4823dfe0 sp=0x4823df38 pc=0x23929d
runtime.goexit()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:1622 +0x1 fp=0x4823dfe8 sp=0x4823dfe0 pc=0x266e81

goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
	/tmp/workdir-gnot/go/src/runtime/proc.go:387 +0xce fp=0x4804ffa0 sp=0x4804ff80 pc=0x2396ee
runtime.goparkunlock(...)
	/tmp/workdir-gnot/go/src/runtime/proc.go:393
runtime.forcegchelper()
	/tmp/workdir-gnot/go/src/runtime/proc.go:311 +0xa7 fp=0x4804ffe0 sp=0x4804ffa0 pc=0x239527
runtime.goexit()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:1622 +0x1 fp=0x4804ffe8 sp=0x4804ffe0 pc=0x266e81
created by runtime.init.6 in goroutine 1
	/tmp/workdir-gnot/go/src/runtime/proc.go:299 +0x1a

goroutine 3 [runnable]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
	/tmp/workdir-gnot/go/src/runtime/proc.go:387 +0xce fp=0x48050f78 sp=0x48050f58 pc=0x2396ee
runtime.goparkunlock(...)
	/tmp/workdir-gnot/go/src/runtime/proc.go:393
runtime.bgsweep(0x0?)
	/tmp/workdir-gnot/go/src/runtime/mgcsweep.go:280 +0x94 fp=0x48050fc8 sp=0x48050f78 pc=0x224754
runtime.gcenable.func1()
	/tmp/workdir-gnot/go/src/runtime/mgc.go:178 +0x25 fp=0x48050fe0 sp=0x48050fc8 pc=0x219545
runtime.goexit()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:1622 +0x1 fp=0x48050fe8 sp=0x48050fe0 pc=0x266e81
created by runtime.gcenable in goroutine 1
	/tmp/workdir-gnot/go/src/runtime/mgc.go:178 +0x66

goroutine 4 [GC scavenge wait]:
runtime.gopark(0x48062000?, 0x5aa268?, 0x0?, 0x0?, 0x0?)
	/tmp/workdir-gnot/go/src/runtime/proc.go:387 +0xce fp=0x48051f70 sp=0x48051f50 pc=0x2396ee
runtime.goparkunlock(...)
	/tmp/workdir-gnot/go/src/runtime/proc.go:393
runtime.(*scavengerState).park(0x83e4a0)
	/tmp/workdir-gnot/go/src/runtime/mgcscavenge.go:425 +0x49 fp=0x48051fa0 sp=0x48051f70 pc=0x221f89
runtime.bgscavenge(0x0?)
	/tmp/workdir-gnot/go/src/runtime/mgcscavenge.go:658 +0x59 fp=0x48051fc8 sp=0x48051fa0 pc=0x222599
runtime.gcenable.func2()
	/tmp/workdir-gnot/go/src/runtime/mgc.go:179 +0x25 fp=0x48051fe0 sp=0x48051fc8 pc=0x2194e5
runtime.goexit()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:1622 +0x1 fp=0x48051fe8 sp=0x48051fe0 pc=0x266e81
created by runtime.gcenable in goroutine 1
	/tmp/workdir-gnot/go/src/runtime/mgc.go:179 +0xa5

goroutine 5 [finalizer wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
	/tmp/workdir-gnot/go/src/runtime/proc.go:387 +0xce fp=0x4804ae28 sp=0x4804ae08 pc=0x2396ee
runtime.runfinq()
	/tmp/workdir-gnot/go/src/runtime/mfinal.go:193 +0x107 fp=0x4804afe0 sp=0x4804ae28 pc=0x2185a7
runtime.goexit()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:1622 +0x1 fp=0x4804afe8 sp=0x4804afe0 pc=0x266e81
created by runtime.createfing in goroutine 1
	/tmp/workdir-gnot/go/src/runtime/mfinal.go:163 +0x3d

goroutine 7 [syscall]:
syscall.Syscall(0xe, 0x4802a3c0, 0x0, 0x0)
	/tmp/workdir-gnot/go/src/syscall/asm_plan9_amd64.s:21 +0x10 fp=0x4804eae8 sp=0x4804ea30 pc=0x271090
syscall.open({0x4802a3a8?, 0x0?}, 0x4804eb98?)
	/tmp/workdir-gnot/go/src/syscall/zsyscall_plan9_amd64.go:61 +0x85 fp=0x4804eb60 sp=0x4804eae8 pc=0x270705
syscall.Open({0x4802a3a8, 0x11}, 0x7?)
	/tmp/workdir-gnot/go/src/syscall/syscall_plan9.go:396 +0xa9 fp=0x4804ebc8 sp=0x4804eb60 pc=0x2700c9
os.openFileNolog({0x4802a3a8, 0x11}, 0x0, 0x0)
	/tmp/workdir-gnot/go/src/os/file_plan9.go:119 +0xc8 fp=0x4804ec30 sp=0x4804ebc8 pc=0x28b768
os.OpenFile({0x4802a3a8, 0x11}, 0x0, 0x5298ed?)
	/tmp/workdir-gnot/go/src/os/file.go:334 +0x3e fp=0x4804ec68 sp=0x4804ec30 pc=0x28abfe
os.Open(...)
	/tmp/workdir-gnot/go/src/os/file.go:314
net.(*netFD).acceptPlan9(0x480000c0)
	/tmp/workdir-gnot/go/src/net/ipsock_plan9.go:262 +0x185 fp=0x4804edf8 sp=0x4804ec68 pc=0x3b2ea5
net.(*TCPListener).accept(0x48024460)
	/tmp/workdir-gnot/go/src/net/tcpsock_plan9.go:51 +0x1e fp=0x4804ee20 sp=0x4804edf8 pc=0x3bb47e
net.(*TCPListener).Accept(0x48024460)
	/tmp/workdir-gnot/go/src/net/tcpsock.go:315 +0x45 fp=0x4804ee50 sp=0x4804ee20 pc=0x3bad65
net/http.(*onceCloseListener).Accept(0x5affe8?)
	<autogenerated>:1 +0x24 fp=0x4804ee68 sp=0x4804ee50 pc=0x496c24
net/http.(*Server).Serve(0x480dc000, {0x5afcd0, 0x48024460})
	/tmp/workdir-gnot/go/src/net/http/server.go:3054 +0x3c8 fp=0x4804ef98 sp=0x4804ee68 pc=0x478048
net/http/httptest.(*Server).goServe.func1()
	/tmp/workdir-gnot/go/src/net/http/httptest/server.go:310 +0x70 fp=0x4804efe0 sp=0x4804ef98 pc=0x49b630
runtime.goexit()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:1622 +0x1 fp=0x4804efe8 sp=0x4804efe0 pc=0x266e81
created by net/http/httptest.(*Server).goServe in goroutine 1
	/tmp/workdir-gnot/go/src/net/http/httptest/server.go:308 +0x65

goroutine 9 [chan receive]:
runtime.gopark(0x4804ba58?, 0x20cc18?, 0x30?, 0xa3?, 0x18?)
	/tmp/workdir-gnot/go/src/runtime/proc.go:387 +0xce fp=0x4804b9f0 sp=0x4804b9d0 pc=0x2396ee
runtime.chanrecv(0x48062770, 0x4804bad7, 0x1)
	/tmp/workdir-gnot/go/src/runtime/chan.go:583 +0x3cd fp=0x4804ba68 sp=0x4804b9f0 pc=0x20536d
runtime.chanrecv1(0x83dcc0?, 0x4c1880?)
	/tmp/workdir-gnot/go/src/runtime/chan.go:442 +0x12 fp=0x4804ba90 sp=0x4804ba68 pc=0x204f92
testing.(*T).Run(0x48007d40, {0x52d208?, 0x0?}, 0x48022d90)
	/tmp/workdir-gnot/go/src/testing/testing.go:1649 +0x3d8 fp=0x4804bb50 sp=0x4804ba90 pc=0x2d5798
net/http/pprof.TestHandlers(0x48007a00?)
	/tmp/workdir-gnot/go/src/net/http/pprof/pprof_test.go:57 +0x2e5 fp=0x4804bf70 sp=0x4804bb50 pc=0x49ed05
testing.tRunner(0x48007d40, 0x55b3d8)
	/tmp/workdir-gnot/go/src/testing/testing.go:1595 +0x139 fp=0x4804bfc0 sp=0x4804bf70 pc=0x2d48d9
testing.(*T).Run.func1()
	/tmp/workdir-gnot/go/src/testing/testing.go:1648 +0x25 fp=0x4804bfe0 sp=0x4804bfc0 pc=0x2d5905
runtime.goexit()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:1622 +0x1 fp=0x4804bfe8 sp=0x4804bfe0 pc=0x266e81
created by testing.(*T).Run in goroutine 1
	/tmp/workdir-gnot/go/src/testing/testing.go:1648 +0x3bd

goroutine 16 [GC worker (idle)]:
runtime.gopark(0x4804cf80?, 0x175f5203fe2c476c?, 0x60?, 0xcf?, 0x27bd6f?)
	/tmp/workdir-gnot/go/src/runtime/proc.go:387 +0xce fp=0x4804cf40 sp=0x4804cf20 pc=0x2396ee
runtime.gcBgMarkWorker()
	/tmp/workdir-gnot/go/src/runtime/mgc.go:1297 +0xe5 fp=0x4804cfe0 sp=0x4804cf40 pc=0x21b305
runtime.goexit()
	/tmp/workdir-gnot/go/src/runtime/asm_amd64.s:1622 +0x1 fp=0x4804cfe8 sp=0x4804cfe0 pc=0x266e81
created by runtime.gcBgMarkStartWorkers in goroutine 15
	/tmp/workdir-gnot/go/src/runtime/mgc.go:1221 +0x1c
FAIL	net/http/pprof	1.143s

(attn @golang/plan9 @0intro)

Above is a CL which deactivates FP unwinding on Plan 9. Actually on plan9/arm64 the tests would pass. Maybe it is because BP is used for the syscall numbers in sys_plan9_amd64.s. I would have to look into this more closely. One option might be to save the registers before each syscall and restore them afterwards


text:
x/website: go.dev/cl redirector does not work for CL 80780043

According to https://github.com/golang/go/commit/881d693c8603510bee3b88205a90ca97942ee0b9 that change was reviewed on https://golang.org/cl/80780043.  However, neither that link nor https://go.dev/cl/80780043 resolves to the actual change.  I'm unable to find the change on codereview.appspot.com, although other changes around that one do still exist.
The conversation remains at https://groups.google.com/g/golang-codereviews/c/6waUN-WcrRM/m/rn7OsN-pShEJ .
Not sure what happened here.

cc @golang/tools-team

The redirector is working as expected, it appears the target is missing the change.

/cc @rsc who might have more context on https://codereview.appspot.com.

From internal discussion

Looking at the Datastore viewer that record seems to just be gone. It is possible that the CL author used Edit Issue > Delete.

@rsc started a process to copy the remaining data to prevent this type of loss in the future. Thanks!

authors: heschi hyangah ianlancetaylor jamalc


text:
go/doc,x/pkgsite: struct fields inconsistently linked in doc comments

https://go.dev/doc/comment#doclinks currently says:

Doc links are links of the form “[Name1]” or “[Name1.Name2]” to refer to exported identifiers in the current package

but it is somewhat ambiguous about whether the [Name1.Name2] form can refer to struct fields or only methods.

In practice, people do seem to intuitively expect references to struct fields to work; for example, this comment on types.Package.GoVersion (written by @rsc) refers to the go/ast.File.GoVersion struct field, and pkg.go.dev appears to render that reference correctly:

However, similar references within the same package are not rendered as links. For example, the reference to [CheckedFiles.SizeError] from zip.CheckedFiles.Err is currently rendered as plain text:

go/doc.Parser uses different functions to resolve intra- vs. inter-package references: it appears that the LookupPackage hook being used by pkgsite does resolve struct fields, whereas the LookupSym hook does not.

I think the bug is in go/doc. Although the Package.syms field lacks a clarifying comment, in practice it appears not to include struct fields:
https://cs.opensource.google/go/go/+/refs/heads/master:src/go/doc/doc.go;l=159-171;drc=fe5af1532ab9c749d880c05e0ffe0e17bf874d7f

This is blocked awaiting code review, so moving to Backlog.

I was about to file an issue for net/http.Transport documentation rendering and then I found this issue.
¶ go doc http.Transport | grep -A3 'Transport caches'
    By default, Transport caches connections for future re-use. This may
    leave many open connections when accessing many hosts. This behavior
    can be managed using Transport.CloseIdleConnections method and the
    [Transport.MaxIdleConnsPerHost] and [Transport.DisableKeepAlives] fields.

Hope https://go.dev/cl/510315 gets some attention soon.

I would love to see this hit 1.23 is there any chance of that @bcmills ?

I'm no longer on the Go team so there's zero chance of my CL landing as-is — but you're welcome to clone it and shepherd it through the review process! 🙃

This is quite a visible issue with rendered package docs. There are about 30 instances where it occurs in the net/http documentation alone.

@griesemer and @golang/pkgsite -- can you suggest a good person to own this?

authors: artyom bcmills cespare stevenh


text:
gopls: out-of-bounds index in "stub methods" code action

Another crash reported by telemetry:
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods fromReturnStmt:18
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods GetStubInfo:10
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods DiagnosticForError:6
golang.org/x/tools/gopls/internal/lsp (*Server).codeAction
golang.org/x/tools/gopls/internal/lsp (*Server).codeAction:210
golang.org/x/tools/gopls/internal/lsp (*Server).CodeAction:1
- golang.org/x/tools/gopls@v0.14.1 go1.19.1 darwin/amd64 (1)

func fromReturnStmt(fset *token.FileSet, ti *types.Info, pos token.Pos, path []ast.Node, rs *ast.ReturnStmt) (*StubInfo, error) {
	returnIdx := -1
	for i, r := range rs.Results {
		if pos >= r.Pos() && pos <= r.End() {
			returnIdx = i
		}
	}
	if returnIdx == -1 {
		return nil, fmt.Errorf("pos %d not within return statement bounds: [%d-%d]", pos, rs.Pos(), rs.End())
	}
	concObj, pointer := concreteType(rs.Results[returnIdx], ti)
	if concObj == nil || concObj.Obj().Pkg() == nil {
		return nil, nil
	}
	ef := enclosingFunction(path, ti)
	if ef == nil {
		return nil, fmt.Errorf("could not find the enclosing function of the return statement")
	}
	iface := ifaceType(ef.Results.List[returnIdx].Type, ti) /// <--- this line fails, presumably because the index is OOB
	if iface == nil {
		return nil, nil
	}
...

This program reproduces the panic. The int("") triggers a "cannot convert" error, which causes GetStubInfo to assume the problem is because of a mismatched return operand and result type, but in fact there is no corresponding result type.
package p

func f() error {
	return nil, myerror{int("")}
}

type myerror struct{}

This stack Mw6nJQ was reported by telemetry:
gopls/bug
golang.org/x/tools/gopls/internal/bug.report:35
golang.org/x/tools/gopls/internal/bug.Errorf:2
golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction.func1.1:2
runtime.gopanic:80
runtime.panicmem:?260
runtime.sigpanic:9
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods.fromReturnStmt:18
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods.GetStubInfo:10
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods.DiagnosticForError:6
golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction.func1:11
golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction:210
golang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction:1
golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch:142
golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1:5
golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1:52
golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1:2

golang.org/x/tools/gopls@v0.14.2 go1.19.6 windows/amd64 vscode (1)

Issue created by golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.

This stack 8eUSuQ was reported by telemetry:
gopls/bug
golang.org/x/tools/gopls/internal/bug.report:35
golang.org/x/tools/gopls/internal/bug.Errorf:2
golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction.func1.1:2
runtime.gopanic:80
runtime.goPanicIndex:2
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods.fromReturnStmt:18
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods.GetStubInfo:10
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods.DiagnosticForError:6
golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction.func1:11
golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction:210
golang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction:1
golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch:142
golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1:5
golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1:52
golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1:2
golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2:3

golang.org/x/tools/gopls@v0.14.2 go1.20.4 linux/amd64 vscode (1)

Issue created by golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.

This stack NNo9gw was reported by telemetry:
gopls/bug
golang.org/x/tools/gopls/internal/bug.report:35
golang.org/x/tools/gopls/internal/bug.Errorf:2
golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction.func1.1:2
runtime.gopanic:50
runtime.panicmem:?261
runtime.sigpanic:19
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods.fromReturnStmt:18
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods.GetStubInfo:10
golang.org/x/tools/gopls/internal/lsp/analysis/stubmethods.DiagnosticForError:6
golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction.func1:11
golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction:210
golang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction:1
golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch:142
golang.org/x/tools/gopls/internal/lsp/lsprpc.(*StreamServer).ServeStream.ServerHandler.func3:5
golang.org/x/tools/gopls/internal/lsp/lsprpc.(*StreamServer).ServeStream.handshaker.func4:52
golang.org/x/tools/gopls/internal/lsp/protocol.Handlers.MustReplyHandler.func1:2

golang.org/x/tools/gopls@v0.14.2 go1.22.0 darwin/arm64 vscode (2)
golang.org/x/tools/gopls@v0.14.2 devel darwin/arm64 vscode (1)

Issue created by golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.


text:
proposal: Go 2: error return with ?

Proposal Details
Wrapping the error in Err() alone gives it a flag that enables catching the error and using specific APIs such as .panic and .?
func fn1() (int, string, Err(error)) {

}

func fn2() (Err(error)) {
	// Throw an error
	n,s := fn1()?
	// Throw panic
	n,s := fn1().panic()
	// Deal with it again
	n,s := fn1() Err(err) {
		fmt.Println("fn2 error: ", err)
		return xxx
	}
}

Duplicate of #39451

authors: mllcms seankhliao


text:
x/tools/internal/refactor/inline: analyzer is non-deterministic

Go version
not relevant
Output of go env in your module/workspace:
not relevant

What did you do?
While preparing the reproducer for (https://go.dev/issue/67336), I encounter non-determinism in the analyzer or test-framework. I don't know if there is a smaller reproducer either.
func TestImport(t *testing.T) {
	files := map[string]string{
		"define/my/typ/foo.go": `
		package typ
		type T int
		`,

		"some/other/pkg/foo.go": `
		package pkg
		import "context"
		import "define/my/typ"
		func Foo(typ.T) context.Context{ return nil }
		`,

		"one/more/pkg/foo.go": `
		package pkg
		func Bar() {}
		`,

		"to/be/inlined/foo.go": `
			package inlined

			import "context"
			import "some/other/pkg"
			import "define/my/typ"

			// inlineme
			func Baz(ctx context.Context) context.Context {
				return pkg.Foo(typ.T(5))
			}
		`,

		"b/c/foo.go": `
package c
import (
	"context"
	"to/be/inlined"
	"one/more/pkg"
)

const (
	// This is a variable
	someConst = 5
)

func foo() {
	inlined.Baz(context.TODO()) // want "inline call of inlined.Baz"
	pkg.Bar()
}
		`,
		"b/c/foo.go.golden": `package c
import (
	"context"
	"one/more/pkg"
	pkg0 "some/other/pkg"

	// This is a variable
	"define/my/typ"
)

const (
	someConst = 5
)

func foo() {
	var _ context.Context = context.TODO()
	pkg0.Foo(typ.T(5)) // want "inline call of inlined.Baz"
	pkg.Bar()
}`,
	}
	dir, cleanup, err := analysistest.WriteFiles(files)
	if err != nil {
		t.Fatal(err)
	}
	analysistest.RunWithSuggestedFixes(t, dir, analyzer.Analyzer, "b/c")
	cleanup()
}

What did you see happen?
Sometimes the test fails (non-deterministically) with:
=== RUN   TestImport
    third_party/golang/go_tools/go/analysis/analysistest/analysistest.go:263: suggested fixes failed for /tmp/analysistest1470885990/src/b/c/foo.go:
        --- /tmp/analysistest1470885990/src/b/c/foo.go.golden
        +++ actual
        @@ -14,7 +14,8 @@
         )

         func foo() {
        -       var _ context.Context = context.TODO()
        +       var _ context.
        +               Context = context.TODO()
                pkg0.Foo(typ.T(5)) // want "inline call of inlined.Baz"
                pkg.Bar()
         }
--- FAIL: TestImport (1.43s)

I don't know if this is an issue with the test framework or with the analyzer.
What did you expect to see?
I would expect the test to always pass (minus the bug tracked in https://go.dev/issue/67336).

cc: @adonovan

Thanks for the very helpful test case, which reproduces the bug for me. My immediate guess as to the cause is that the order in which the files (e.g. caller and callee) are added to the token.FileSet is nondeterministic, and that the relative token.Pos values affect the formatter logic that decides when to insert a line break.

Seems like this is not going to make it to v0.17. @adonovan it sounds like you've spent some time thinking about this -- is there a quick fix?

I could not reproduce this, I'm afraid. I suspect it has to do with the offsets caused by import reformatting, which I have fixed in #67336.
Therefore, I think this fixed but can't be sure, so I'll bump to the next release.

Running the test exactly as it appears in the issue body, I can still reproduce the failure nondeterministically (20%) at master (1e0d4ee).
I also notice that the output deterministically (100%) includes a blank line after the import of  "context".

Just ran into this in a test I added, and could reproduce reliable within a couple seconds.
The problem is (again) that we're formatting callee nodes using the caller fset. If ever the callee positions are actually in range of a file in the caller fileset, we can end up with an erroneous line break in between nodes.
I have a fix, which is to clear positions correctly before we ever splice in callee nodes.

authors: adonovan findleyr lfolger


text:
mail.ParseAddress incorrectly parses email addresses without Top Level Domains

Go version
go version go1.23.0 linux/amd64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/grqphical/.cache/go-build'
GOENV='/home/grqphical/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/grqphical/development/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/grqphical/development/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.0'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/grqphical/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/grqphical/development/go/inference-lab/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3855366447=/tmp/go-build -gno-record-gcc-switches'
GOROOT/bin/go version: go version go1.23.0 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.23.0
uname -sr: Linux 5.15.153.1-microsoft-standard-WSL2
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 2.36-9+deb12u7) stable release version 2.36.

What did you do?
https://go.dev/play/p/CWyOyotPGm2
What did you see happen?
mail.ParseAddress returned no error when parsing an email without a TLD
What did you expect to see?
I expected it to return an error.
Not sure if this is intended behaviour or not. I couldn't find anything concrete online about if the email address specification allows addresses without TLDs

Related Issues and Documentation

net/mail: ParseAddress doesn't support using a domain-literal in the domain of an email address #60206 (closed)
net/mail: ParseAddress() accepts valid RFC 5322 addresses with domain part starting with a dash which are invalid RFC 1035 addresses, should we tighten the permissive validation? #39488
net/mail: mail.ParseAddress() does not handle comments correctly #38447
mail.ParseAddress("145175208@qq") return a valid result #45056 (closed)
net/mail: address parsing fails when name contains '@' #66447 (closed)
net/mail: parseAddressList doesn't allow commas with empty email address #36959 (closed)
net/mail: ParseAddress allows unquoted non ascii × #68234 (closed)
net/mail: ParseAddress cannot parse email address with name contains chinese character #36200 (closed)
net/mail: mail.ParseAddress() allows invalid characters in local-part and domain-literal #59039 (closed)
net/mail: mail ParseAddressList can bypass and panic   #43714 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Technically, "name@domain" is a valid email address under the RFC 5322. Since the net/email package follows the syntax from this RFC, the parser is working as expected here. Although a domain without a TLD might look incomplete, RFC 5322 actually allows it. The rule requiring a TLD comes from RFC 5321, which isn’t part of the package’s validation.

Closing as working as intended.

authors: gabyhelp gazerro grqphical seankhliao


text:
Fix LastRecordOffset behaviour

LastRecordOffset updates its value in Write which is the wrong place to do it. It needs to happen during Next. The tests failed to catch this bug because the tests write their test records in a single Write call, which mimics the correct behavior, but if a record is written in multiple calls to Write, the value of LastRecordOffset is wrong.

PTAL

source: gharchive/pull-request

repo: golang/leveldb

license_source: bigquery


text:
unix: Add readv/writev for illumos

iovec read/writes (readv, writev, preadv, pwritev) are present on illumos,
but they weren't added to the package. This commit added those missing
features.
Updates golang/go#36201

@googlebot I signed it!

@googlebot I fixed it..

repo: golang/sys


text:
tour: add additional context for for why dropping the first two values reduces cap but slicing to zero length does not

Context: https://go.dev/tour/moretypes/11
`
func main() {
s := []int{2, 3, 5, 7, 11, 13}
printSlice(s)
// Slice the slice to give it zero length.
s = s[:0]
printSlice(s)

// Extend its length.
s = s[:4]
printSlice(s)

// Drop its first two values.
s = s[2:]
printSlice(s)

}
`
Would be helpful for authors to include an explanation for why the capacity only changes when "dropping the first two values". Some explanation found on stack over flow here

had the same confusion, thank u for the stackoverflow link 🙏

repo: golang/tour


text:
🛑 Properstar.ch homepage is down

In d431110, Properstar.ch homepage (https://www.properstar.ch) was down:

HTTP code: 502
Response time: 432 ms

Resolved: Properstar.ch homepage is back up in fd239dd after 9 minutes.

repo: goncharov/powersite-uptime

license: MIT


text:
blas,graph,lapack: fix imports and code generation

@btracey Please take a look.

add  an updates comment?
LGTM

I don't think there is a relevant issue.

authors: btracey kortschak

repo: gonum/gonum


text:
blas/gonum: add Ztbmv

Please take a look.
Updates #184
I don't understand how it happened that Zhbmv was not gofmted and that is was not detected.

I have also switched the test to use subtests, only recently I realized that we can finally use them.
PTAL


text:
Metadata uses "text" for iterables?

Whereas "text" is used elsewhere for the text nodes, the Metadata class appears to use "text" for its children; this seems inconsistent.

Yes, that is inappropriate. I think I will require all  elements to have  children, so I can make it use "metas" for getting children. Either way, "text" is the wrong thing to call it.

This should be resolved by a32c295127758c260c5a4cb2e82702ae52abb7e8 (actually before, but this commit is the first one that isn't broken I think).
While Metadata.text is renamed to Metadata.metas, you can still use .text (but you'll get a DeprecationWarning) in case any code relies on it. Also, I still have Meta.text even though some examples (like the OLAC example) have nested XML, and I've stated in the paper that deeper XML structure is possible under . I'm not certain what to do here, yet, since without a schema or fixed format, I don't know how to parse the deeper structure into a Python representation. Some options:

Parse into a pseudo-JSON-like dictionary
Re-serialize anything under  to text and just store it in the text attribute
Have special parsers for non-text  content (e.g. a special one for OLAC)

authors: goodmami rgeorgi

repo: goodmami/xigt

license: mit


text:
Raspbian facter/puppet service provider broken

Warning: Found multiple default providers for service: init, systemd; using init
Puppet service provider set here:
https://github.com/puppetlabs/puppet/blob/7.9.0_release/lib/puppet/provider/service/systemd.rb
This looks for Debian in $operatingsystem not Raspbian.  In facter > 2.4.6 (ie >4.0.0) $operatingsystem changes from Debian to Raspbian and breaks the default system provider.
It can't be set by default, at least not in serverless agent setup Maverick is using.
For now, try to downgrade facter to 2.4.6.

https://ask.puppet.com/question/396/howto-force-systemd-as-service-provider-globally/

Worked around but not inherently fixed, reopening to raise and track a proper fix.

repo: goodrobots/maverick


text:
How capture image of the rendering model and save to local as png or jpg.

I want to capture the image of the model and save to local folder.
To achieve this I tried some code like arFragment.getArSceneView().getArFrame().acquireCameraImage()
this is giving Image class object, I thought from here I will get bitmap object but bitmap is always null.
Please update how to achieve this functionality.

You can use the PixelCopy API as described in the following codelabs:
https://codelabs.developers.google.com/codelabs/sceneform-intro/index.html?index=..%2F..%2Fio2018#14

Thanks, its working fine.

authors: RavindraVirat SimonMarquis

repo: google-ar/sceneform-android-sdk