text:
cmd/go: go get failing with vague error 'unknown revision v0.0.0' with kubernetes

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

$ go version
go version go1.12.5 darwin/amd64

Does this issue reproduce with the latest release?
I am not sure (I am 1 patch version away from the latest release)
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/joshsamuels/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/joshsamuels/Development/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.5/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.5/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/joshsamuels/Development/go/src/git.repo/team/project/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/23/wcm3x4vj7dq87gfg1lhdjhq40000gn/T/go-build800528247=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

go get ./... in the project root
What did you expect to see?
I expected to see a list of all my dependencies being downloaded successfully
What did you see instead?
go get ./...
go: finding github.com/dsnet/compress/bzip2 latest
go: finding github.com/xi2/xz latest
go: finding k8s.io/kubernetes/pkg/kubectl latest
go: finding k8s.io/kubernetes/pkg latest
go: finding github.com/go-openapi/spec v0.17.0
go: finding k8s.io/cli-runtime v0.0.0
go: finding github.com/go-openapi/runtime v0.0.0-20180920151709-4f900dc2ade9
go: finding github.com/go-openapi/analysis v0.17.0
go: finding k8s.io/kube-aggregator v0.0.0
go: finding k8s.io/kubelet v0.0.0
go: finding k8s.io/kube-proxy v0.0.0
go: finding k8s.io/metrics v0.0.0
go: finding k8s.io/sample-apiserver v0.0.0
go: finding k8s.io/cri-api v0.0.0
go: k8s.io/cli-runtime@v0.0.0: unknown revision v0.0.0
go: k8s.io/cri-api@v0.0.0: unknown revision v0.0.0
go: finding gonum.org/v1/netlib v0.0.0-20190313105609-8cb42192e0e0
go: k8s.io/kube-aggregator@v0.0.0: unknown revision v0.0.0
go: k8s.io/kubelet@v0.0.0: unknown revision v0.0.0
go: finding k8s.io/legacy-cloud-providers v0.0.0
go: k8s.io/kube-proxy@v0.0.0: unknown revision v0.0.0
go: k8s.io/sample-apiserver@v0.0.0: unknown revision v0.0.0
go: k8s.io/metrics@v0.0.0: unknown revision v0.0.0
go: finding k8s.io/apimachinery v0.0.0
go: finding k8s.io/api v0.0.0
go: finding k8s.io/apiserver v0.0.0
go: finding k8s.io/code-generator v0.0.0
go: finding k8s.io/client-go v0.0.0
go: finding golang.org/x/exp v0.0.0-20190125153040-c74c464bbbf2
go: k8s.io/legacy-cloud-providers@v0.0.0: unknown revision v0.0.0
go: finding github.com/go-openapi/loads v0.17.0
go: k8s.io/apimachinery@v0.0.0: unknown revision v0.0.0
go: k8s.io/apiserver@v0.0.0: unknown revision v0.0.0
go: finding k8s.io/component-base v0.0.0
go: k8s.io/api@v0.0.0: unknown revision v0.0.0
go: k8s.io/code-generator@v0.0.0: unknown revision v0.0.0
go: finding k8s.io/kube-controller-manager v0.0.0
go: finding k8s.io/kube-scheduler v0.0.0
go: k8s.io/client-go@v0.0.0: unknown revision v0.0.0
go: finding k8s.io/cluster-bootstrap v0.0.0
go: finding k8s.io/cloud-provider v0.0.0
go: finding golang.org/x/tools v0.0.0-20190206041539-40960b6deb8e
go: k8s.io/component-base@v0.0.0: unknown revision v0.0.0
go: finding k8s.io/apiextensions-apiserver v0.0.0
go: k8s.io/kube-controller-manager@v0.0.0: unknown revision v0.0.0
go: k8s.io/kube-scheduler@v0.0.0: unknown revision v0.0.0
go: finding k8s.io/csi-translation-lib v0.0.0
go: k8s.io/cloud-provider@v0.0.0: unknown revision v0.0.0
go: k8s.io/cluster-bootstrap@v0.0.0: unknown revision v0.0.0
go: k8s.io/apiextensions-apiserver@v0.0.0: unknown revision v0.0.0
go: k8s.io/csi-translation-lib@v0.0.0: unknown revision v0.0.0
go: error loading module requirements

go get -v ./...
Fetching https://k8s.io/kubernetes/pkg/kubectl?go-get=1
go: finding github.com/dsnet/compress/bzip2 latest
go: finding github.com/xi2/xz latest
Parsing meta tags from https://k8s.io/kubernetes/pkg/kubectl?go-get=1 (status code 200)
get "k8s.io/kubernetes/pkg/kubectl": found meta tag get.metaImport{Prefix:"k8s.io/kubernetes", VCS:"git", RepoRoot:"https://github.com/kubernetes/kubernetes"} at https://k8s.io/kubernetes/pkg/kubectl?go-get=1
get "k8s.io/kubernetes/pkg/kubectl": verifying non-authoritative meta tag
Fetching https://k8s.io/kubernetes?go-get=1
Parsing meta tags from https://k8s.io/kubernetes?go-get=1 (status code 200)
go: finding k8s.io/kubernetes/pkg/kubectl latest
Fetching https://k8s.io/kubernetes/pkg?go-get=1
Parsing meta tags from https://k8s.io/kubernetes/pkg?go-get=1 (status code 200)
get "k8s.io/kubernetes/pkg": found meta tag get.metaImport{Prefix:"k8s.io/kubernetes", VCS:"git", RepoRoot:"https://github.com/kubernetes/kubernetes"} at https://k8s.io/kubernetes/pkg?go-get=1
get "k8s.io/kubernetes/pkg": verifying non-authoritative meta tag
go: finding k8s.io/kubernetes/pkg latest
Fetching https://k8s.io/kubernetes?go-get=1
Parsing meta tags from https://k8s.io/kubernetes?go-get=1 (status code 200)
get "k8s.io/kubernetes": found meta tag get.metaImport{Prefix:"k8s.io/kubernetes", VCS:"git", RepoRoot:"https://github.com/kubernetes/kubernetes"} at https://k8s.io/kubernetes?go-get=1
Fetching https://k8s.io/kube-aggregator?go-get=1
Fetching https://k8s.io/kube-controller-manager?go-get=1
Fetching https://k8s.io/client-go?go-get=1
go: finding github.com/go-openapi/analysis v0.0.0-20180825180245-b006789cd277
Fetching https://k8s.io/legacy-cloud-providers?go-get=1
Fetching https://k8s.io/apiserver?go-get=1
Fetching https://k8s.io/metrics?go-get=1
Fetching https://k8s.io/kube-scheduler?go-get=1
Parsing meta tags from https://k8s.io/kube-aggregator?go-get=1 (status code 200)
go: finding github.com/prometheus/procfs v0.0.0-20181204211112-1dc9a6cbc91a
get "k8s.io/kube-aggregator": found meta tag get.metaImport{Prefix:"k8s.io/kube-aggregator", VCS:"git", RepoRoot:"https://github.com/kubernetes/kube-aggregator"} at https://k8s.io/kube-aggregator?go-get=1
Parsing meta tags from https://k8s.io/client-go?go-get=1 (status code 200)
go: finding k8s.io/kube-aggregator v0.0.0
get "k8s.io/client-go": found meta tag get.metaImport{Prefix:"k8s.io/client-go", VCS:"git", RepoRoot:"https://github.com/kubernetes/client-go"} at https://k8s.io/client-go?go-get=1
Parsing meta tags from https://k8s.io/apiserver?go-get=1 (status code 200)
get "k8s.io/apiserver": found meta tag get.metaImport{Prefix:"k8s.io/apiserver", VCS:"git", RepoRoot:"https://github.com/kubernetes/apiserver"} at https://k8s.io/apiserver?go-get=1
go: finding github.com/beorn7/perks v0.0.0-20180321164747-3a771d992973
go: finding k8s.io/client-go v0.0.0
Parsing meta tags from https://k8s.io/kube-scheduler?go-get=1 (status code 200)
go: finding k8s.io/apiserver v0.0.0
get "k8s.io/kube-scheduler": found meta tag get.metaImport{Prefix:"k8s.io/kube-scheduler", VCS:"git", RepoRoot:"https://github.com/kubernetes/kube-scheduler"} at https://k8s.io/kube-scheduler?go-get=1
go: finding k8s.io/kube-scheduler v0.0.0
Parsing meta tags from https://k8s.io/legacy-cloud-providers?go-get=1 (status code 200)
get "k8s.io/legacy-cloud-providers": found meta tag get.metaImport{Prefix:"k8s.io/legacy-cloud-providers", VCS:"git", RepoRoot:"https://github.com/kubernetes/legacy-cloud-providers"} at https://k8s.io/legacy-cloud-providers?go-get=1
go: finding k8s.io/legacy-cloud-providers v0.0.0
Parsing meta tags from https://k8s.io/kube-controller-manager?go-get=1 (status code 200)
get "k8s.io/kube-controller-manager": found meta tag get.metaImport{Prefix:"k8s.io/kube-controller-manager", VCS:"git", RepoRoot:"https://github.com/kubernetes/kube-controller-manager"} at https://k8s.io/kube-controller-manager?go-get=1
go: finding k8s.io/kube-controller-manager v0.0.0
go: k8s.io/kube-scheduler@v0.0.0: unknown revision v0.0.0
Fetching https://golang.org/x/net?go-get=1
go: k8s.io/kube-aggregator@v0.0.0: unknown revision v0.0.0
Fetching https://k8s.io/sample-apiserver?go-get=1
go: k8s.io/apiserver@v0.0.0: unknown revision v0.0.0
go: k8s.io/legacy-cloud-providers@v0.0.0: unknown revision v0.0.0
Fetching https://k8s.io/cluster-bootstrap?go-get=1
Fetching https://k8s.io/component-base?go-get=1
go: k8s.io/kube-controller-manager@v0.0.0: unknown revision v0.0.0
Fetching https://k8s.io/apimachinery?go-get=1
go: k8s.io/client-go@v0.0.0: unknown revision v0.0.0
Fetching https://k8s.io/code-generator?go-get=1
Parsing meta tags from https://k8s.io/metrics?go-get=1 (status code 200)
get "k8s.io/metrics": found meta tag get.metaImport{Prefix:"k8s.io/metrics", VCS:"git", RepoRoot:"https://github.com/kubernetes/metrics"} at https://k8s.io/metrics?go-get=1
go: finding k8s.io/metrics v0.0.0
Parsing meta tags from https://k8s.io/sample-apiserver?go-get=1 (status code 200)
Parsing meta tags from https://k8s.io/component-base?go-get=1 (status code 200)
get "k8s.io/sample-apiserver": found meta tag get.metaImport{Prefix:"k8s.io/sample-apiserver", VCS:"git", RepoRoot:"https://github.com/kubernetes/sample-apiserver"} at https://k8s.io/sample-apiserver?go-get=1
get "k8s.io/component-base": found meta tag get.metaImport{Prefix:"k8s.io/component-base", VCS:"git", RepoRoot:"https://github.com/kubernetes/component-base"} at https://k8s.io/component-base?go-get=1
go: finding k8s.io/component-base v0.0.0
go: finding k8s.io/sample-apiserver v0.0.0
Parsing meta tags from https://k8s.io/cluster-bootstrap?go-get=1 (status code 200)
get "k8s.io/cluster-bootstrap": found meta tag get.metaImport{Prefix:"k8s.io/cluster-bootstrap", VCS:"git", RepoRoot:"https://github.com/kubernetes/cluster-bootstrap"} at https://k8s.io/cluster-bootstrap?go-get=1
go: finding k8s.io/cluster-bootstrap v0.0.0
Parsing meta tags from https://k8s.io/apimachinery?go-get=1 (status code 200)
Parsing meta tags from https://k8s.io/code-generator?go-get=1 (status code 200)
get "k8s.io/code-generator": found meta tag get.metaImport{Prefix:"k8s.io/code-generator", VCS:"git", RepoRoot:"https://github.com/kubernetes/code-generator"} at https://k8s.io/code-generator?go-get=1
get "k8s.io/apimachinery": found meta tag get.metaImport{Prefix:"k8s.io/apimachinery", VCS:"git", RepoRoot:"https://github.com/kubernetes/apimachinery"} at https://k8s.io/apimachinery?go-get=1
go: finding k8s.io/code-generator v0.0.0
go: finding k8s.io/apimachinery v0.0.0
Parsing meta tags from https://golang.org/x/net?go-get=1 (status code 200)
get "golang.org/x/net": found meta tag get.metaImport{Prefix:"golang.org/x/net", VCS:"git", RepoRoot:"https://go.googlesource.com/net"} at https://golang.org/x/net?go-get=1
go: finding golang.org/x/net v0.0.0-20190311183353-d8887717615a
go: finding github.com/matttproud/golang_protobuf_extensions v1.0.1
go: k8s.io/metrics@v0.0.0: unknown revision v0.0.0
Fetching https://k8s.io/cli-runtime?go-get=1
go: k8s.io/component-base@v0.0.0: unknown revision v0.0.0
Fetching https://k8s.io/kubelet?go-get=1
go: k8s.io/cluster-bootstrap@v0.0.0: unknown revision v0.0.0
Fetching https://k8s.io/api?go-get=1
go: k8s.io/sample-apiserver@v0.0.0: unknown revision v0.0.0
Fetching https://k8s.io/csi-translation-lib?go-get=1
Parsing meta tags from https://k8s.io/cli-runtime?go-get=1 (status code 200)
get "k8s.io/cli-runtime": found meta tag get.metaImport{Prefix:"k8s.io/cli-runtime", VCS:"git", RepoRoot:"https://github.com/kubernetes/cli-runtime"} at https://k8s.io/cli-runtime?go-get=1
go: finding k8s.io/cli-runtime v0.0.0
Fetching https://golang.org/x/sync?go-get=1
Parsing meta tags from https://k8s.io/kubelet?go-get=1 (status code 200)
get "k8s.io/kubelet": found meta tag get.metaImport{Prefix:"k8s.io/kubelet", VCS:"git", RepoRoot:"https://github.com/kubernetes/kubelet"} at https://k8s.io/kubelet?go-get=1
go: finding k8s.io/kubelet v0.0.0
go: k8s.io/code-generator@v0.0.0: unknown revision v0.0.0
go: k8s.io/apimachinery@v0.0.0: unknown revision v0.0.0
go: finding golang.org/x/net v0.0.0-20181201002055-351d144fa1fc
Parsing meta tags from https://k8s.io/api?go-get=1 (status code 200)
get "k8s.io/api": found meta tag get.metaImport{Prefix:"k8s.io/api", VCS:"git", RepoRoot:"https://github.com/kubernetes/api"} at https://k8s.io/api?go-get=1
Parsing meta tags from https://k8s.io/csi-translation-lib?go-get=1 (status code 200)
get "k8s.io/csi-translation-lib": found meta tag get.metaImport{Prefix:"k8s.io/csi-translation-lib", VCS:"git", RepoRoot:"https://github.com/kubernetes/csi-translation-lib"} at https://k8s.io/csi-translation-lib?go-get=1
go: finding k8s.io/csi-translation-lib v0.0.0
go: finding k8s.io/api v0.0.0
Parsing meta tags from https://golang.org/x/sync?go-get=1 (status code 200)
Fetching https://k8s.io/cri-api?go-get=1
get "golang.org/x/sync": found meta tag get.metaImport{Prefix:"golang.org/x/sync", VCS:"git", RepoRoot:"https://go.googlesource.com/sync"} at https://golang.org/x/sync?go-get=1
go: finding golang.org/x/sync v0.0.0-20181108010431-42b317875d0f
Parsing meta tags from https://k8s.io/cri-api?go-get=1 (status code 200)
get "k8s.io/cri-api": found meta tag get.metaImport{Prefix:"k8s.io/cri-api", VCS:"git", RepoRoot:"https://github.com/kubernetes/cri-api"} at https://k8s.io/cri-api?go-get=1
go: finding k8s.io/cri-api v0.0.0
Fetching https://k8s.io/kube-proxy?go-get=1
Fetching https://k8s.io/apiextensions-apiserver?go-get=1
Fetching https://k8s.io/cloud-provider?go-get=1
Parsing meta tags from https://k8s.io/apiextensions-apiserver?go-get=1 (status code 200)
get "k8s.io/apiextensions-apiserver": found meta tag get.metaImport{Prefix:"k8s.io/apiextensions-apiserver", VCS:"git", RepoRoot:"https://github.com/kubernetes/apiextensions-apiserver"} at https://k8s.io/apiextensions-apiserver?go-get=1
go: finding k8s.io/apiextensions-apiserver v0.0.0
Parsing meta tags from https://k8s.io/kube-proxy?go-get=1 (status code 200)
get "k8s.io/kube-proxy": found meta tag get.metaImport{Prefix:"k8s.io/kube-proxy", VCS:"git", RepoRoot:"https://github.com/kubernetes/kube-proxy"} at https://k8s.io/kube-proxy?go-get=1
go: finding k8s.io/kube-proxy v0.0.0
Parsing meta tags from https://k8s.io/cloud-provider?go-get=1 (status code 200)
get "k8s.io/cloud-provider": found meta tag get.metaImport{Prefix:"k8s.io/cloud-provider", VCS:"git", RepoRoot:"https://github.com/kubernetes/cloud-provider"} at https://k8s.io/cloud-provider?go-get=1
go: finding k8s.io/cloud-provider v0.0.0
go: k8s.io/cli-runtime@v0.0.0: unknown revision v0.0.0
go: k8s.io/kubelet@v0.0.0: unknown revision v0.0.0
go: k8s.io/csi-translation-lib@v0.0.0: unknown revision v0.0.0
go: k8s.io/cri-api@v0.0.0: unknown revision v0.0.0
go: k8s.io/api@v0.0.0: unknown revision v0.0.0
go: k8s.io/kube-proxy@v0.0.0: unknown revision v0.0.0
go: k8s.io/apiextensions-apiserver@v0.0.0: unknown revision v0.0.0
go: k8s.io/cloud-provider@v0.0.0: unknown revision v0.0.0
go: error loading module requirements

Likely related to https://github.com/golang/go/issues/27173#issuecomment-504807285 and https://github.com/golang/go/issues/27173#issuecomment-505089424.

@thepudds is there a workaround to this issue?

cc @liggitt @sttts

@bcmills @jayconrod

We have replace directives setup for these though: https://github.com/kubernetes/kubernetes/blob/e8738d665b29ca98d39a7907a83ef34dfbb5c5e3/go.mod#L436
Looks like go get doesn't look into replace directives?

Looks like go get doesn't look into replace directives?

replace directives in modules other than the main module are ignored when building the main module.
So a module-based consumer of k8s.io/api for example does not use any replace directives found in the go.mod file of k8s.io/api.
From https://golang.org/cmd/go/#hdr-The_main_module_and_the_build_list:

The main module's go.mod file defines the precise set of packages available for use by the go command, through require, replace, and exclude statements. Dependency modules, found by following require statements, also contribute to the definition of that set of packages, but only through their go.mod files' require statements: any replace and exclude statements in dependency modules are ignored. The replace and exclude statements therefore allow the main module complete control over its own build, without also being subject to complete control by dependencies.

k8s.io/kubernetes is not primarily intended to be consumed as a module. Only the published subcomponents are (and go get works properly with those).
If you want to consume k8s.io/kubernetes as a module, you'd probably need to add require directives for matching versions of all of the subcomponents, rather than using go get

@liggitt I am not using kubernetes/kubernetes. I am using client-go
These are some of the ones I am using
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/rest"
	"k8s.io/client-go/tools/clientcmd"

@joshmsamuels could you try to put together a minimal set of steps to reproduce, ideally starting with an empty module? (E.g., something like cd $(mktemp -d); go mod init tempmod;, etc.)?

@thepudds Should I like make a main.go for that then?

It sounds like the Go command is working as intended, but let's make sure we can reproduce this before closing. @joshmsamuels please do post a minimal example to help us see the same error. A gist or a small repo with a go.mod and a couple .go files would be fine.
As others have pointed out, replace directives are only effective for builds within the module where they appear. So if you check out k8s.io/kubernetes, the replace directives there will work, but not replace directives in other go.mod files.
Kubernetes has a complicated system for managing dependencies, and they have a lot of replace directives. Some of their dependencies are required at version v0.0.0 (which doesn't exist): those requirements must be replaced. This prevents k8s.io/kubernetes from being a requirement of other modules.
However, if you aren't depending on k8s.io/kubernetes, you shouldn't have a problem.

I am not using kubernetes/kubernetes

The "Fetching https://k8s.io/kubernetes/pkg/kubectl" text indicates something in your dependency tree is requiring that repo

@liggitt I missed that one sorry 🙃

@joshmsamuels You might or might not need a main.go. Frequently modules-related problems can be recreated without any *.go files in a test module. That said, you can also create a tempmod.go something like:
package tempmod

import (
	_ "k8s.io/client-go/kubernetes"
	_ "k8s.io/client-go/rest"
	_ "k8s.io/client-go/tools/clientcmd"
)

mkdir demo
go mod init demo

main.go
import (
        _ "k8s.io/kubernetes/pkg/kubectl"

)

func main() {

}

go get ./...

@liggitt So is there a way to use kubectl in my project? Its been working as expected for the last 2 months

If you want to consume k8s.io/kubernetes as a module, you'd probably need to add require directives for matching versions of all of the subcomponents, rather than using go get

Long-term (next few months), the plan is to publish kubectl in its own repo you could depend on as a normal module

I tried the way you suggested in other issues but go get was overriding the versions I pinned

https://github.com/kubernetes/kubectl/tree/master/pkg/util exists today, and there are a slew of PRs migrating pkg/kubectl to the published repo (like https://github.com/kubernetes/kubernetes/pull/79207) which should get merged in the next week or so.
(this is more kubernetes, than go discussion at this point though)

@nikhita Thanks! I still want a temp solution at the very least.
Youre right about it being more of a kubernetes discussion so maybe we should move this over to https://github.com/kubernetes/kubernetes/issues/79384

Closing in favor of kubernetes/kubernetes#79384

I am using a module that require kubernetes 1.16.2
To build my project, I had to port all the k8s.io/* directives under replace of kubernetes go.mod in my own go.mod. I feel so bad about it, but works :P
// this worked for the tag release-1.16, see each dependency tag in the repository to take the correct one

replace (
	k8s.io/api => k8s.io/api release-1.16
	k8s.io/apiextensions-apiserver => k8s.io/apiextensions-apiserver release-1.16
	k8s.io/apimachinery => k8s.io/apimachinery release-1.16
	k8s.io/apiserver => k8s.io/apiserver release-1.16
	k8s.io/cli-runtime => k8s.io/cli-runtime release-1.16
	k8s.io/client-go => k8s.io/client-go kubernetes-1.16.2
	k8s.io/cloud-provider => k8s.io/cloud-provider release-1.16
	k8s.io/cluster-bootstrap => k8s.io/cluster-bootstrap release-1.16
	k8s.io/code-generator => k8s.io/code-generator release-1.16
	k8s.io/component-base => k8s.io/component-base release-1.16
	k8s.io/cri-api => k8s.io/cri-api release-1.16
	k8s.io/csi-translation-lib => k8s.io/csi-translation-lib release-1.16
	k8s.io/gengo => k8s.io/gengo v0.0.0-20190822140433-26a664648505
	k8s.io/heapster => k8s.io/heapster v1.2.0-beta.1
	k8s.io/klog => k8s.io/klog v0.4.0
	k8s.io/kube-aggregator => k8s.io/kube-aggregator release-1.16
	k8s.io/kube-controller-manager => k8s.io/kube-controller-manager release-1.16
	k8s.io/kube-openapi => k8s.io/kube-openapi v0.0.0-20190816220812-743ec37842bf
	k8s.io/kube-proxy => k8s.io/kube-proxy release-1.16
	k8s.io/kube-scheduler => k8s.io/kube-scheduler release-1.16
	k8s.io/kubectl => k8s.io/kubectl release-1.16
	k8s.io/kubelet => k8s.io/kubelet release-1.16
	k8s.io/legacy-cloud-providers => k8s.io/legacy-cloud-providers release-1.16
	k8s.io/metrics => k8s.io/metrics release-1.16
	k8s.io/node-api => k8s.io/node-api release-1.16
	k8s.io/repo-infra => k8s.io/repo-infra v0.0.0-20181204233714-00fe14e3d1a3
	k8s.io/sample-apiserver => k8s.io/sample-apiserver release-1.16
	k8s.io/sample-cli-plugin => k8s.io/sample-cli-plugin release-1.16
	k8s.io/sample-controller => k8s.io/sample-controller release-1.16
	k8s.io/utils => k8s.io/utils v0.0.0-20190801114015-581e00157fb1
)

authors: andybons jayconrod joshmsamuels liggitt muka nikhita thepudds


text:
access: Trybot Access

Hello!
Some of you know me as the organizer of dotGo :)
I've had a couple CLs merged in the regexp package and plan to be increasingly active there, hopefully. Daniel Marti recommended I ask for Trybot Access. I understand the semi-hardened nature of it and will skim for malicious code (though I'll probably stick to the regexp package for now).
My Gerrit email is "sylvinus@gmail.com"
Thanks!

Done.  Enjoy.

Thanks!

source: gharchive/issue

authors: ianlancetaylor sylvinus

repo: golang/go

license_type: permissive

license_source: github-api


text:
the package "net/rpc" has no timeout mecchanism????

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

$ go version
go version go1.12.5 windows/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
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\yuyang\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=D:\golib;D:\backstage\newest\hmi-server\code\gopath;D:\BATCH_backstage\code\newest\batchServer;
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\yuyang\AppData\Local\Temp\go-build927238374=/tmp/go-build -gno-record-gcc-switches

What did you do?

What did you expect to see?
nothing,just send a rpc package to another server.
What did you see instead?
looks like the function will block forever!!!
goroutine 67 [chan receive, 15 minutes]:
net/rpc.(*Client).Call(...)
C:/Go/src/net/rpc/client.go:322
hmi-server/common/rpc/client.(*SingleConnRpcClient).Send(0xc0001f6d80, 0xc0024c3c30, 0x4, 0xc002ae2a01)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/common/rpc/client/single.go:32 +0x24a
hmi-server/agent/g.SendToVarcompute(0xae789e, 0xc, 0x9e85a0, 0xc00016a260, 0xb14cb0, 0xfc63b0)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/g/varcompute.go:29 +0x156
hmi-server/agent/cron.(*DeviceOpc).reportData.func1(0xbf4cad82ee7bb62c, 0x3a043ac3231, 0xfa95c0, 0xc002ae2a01, 0x2)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:644 +0xe1
hmi-server/agent/cron.(*DeviceOpc).reportData(0xc0000d0160)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:654 +0x2e0
created by hmi-server/agent/cron.(*DeviceOpc).start
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:300 +0x9c7
goroutine 69 [chan receive, 15 minutes]:
net/rpc.(*Client).Call(...)
C:/Go/src/net/rpc/client.go:322
hmi-server/common/rpc/client.(*SingleConnRpcClient).Send(0xc0001f6d80, 0xc0010b7ab0, 0x4, 0xc000c54101)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/common/rpc/client/single.go:32 +0x24a
hmi-server/agent/g.SendToVarcompute(0xae789e, 0xc, 0x9e85a0, 0xc0002ca9e0, 0x40a9b2, 0x10)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/g/varcompute.go:29 +0x156
hmi-server/agent/cron.(*DeviceOpc).setNetMetric(0xc0000d0420, 0xc00061b430)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:623 +0x136
hmi-server/agent/cron.(*DeviceOpc).collect(0xc0000d0420, 0xc000444000, 0x1b7b, 0x1f9c, 0xc0005e7840, 0x18, 0xc00061b430)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:596 +0x5bb
created by hmi-server/agent/cron.(*DeviceOpc).start
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:295 +0x6c0

checkmatesolo
On Tue, Aug 13, 2019, 12:56 AM radong notifications@github.com wrote:

What version of Go are you using (go version)?
$ go version
go version go1.12.5 windows/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
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\yuyang\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=D:\golib;D:\backstage\newest\hmi-server\code\gopath;D:\BATCH_backstage\code\newest\batchServer;
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\yuyang\AppData\Local\Temp\go-build927238374=/tmp/go-build -gno-record-gcc-switches
What did you do? What did you expect to see?
nothing,just send a rpc package to another server.
What did you see instead?
looks like the function will block forever!!!
goroutine 67 [chan receive, 15 minutes]:
net/rpc.(*Client).Call(...)
C:/Go/src/net/rpc/client.go:322
hmi-server/common/rpc/client.(*SingleConnRpcClient).Send(0xc0001f6d80,
0xc0024c3c30, 0x4, 0xc002ae2a01)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/common/rpc/client/single.go:32
+0x24a
hmi-server/agent/g.SendToVarcompute(0xae789e, 0xc, 0x9e85a0, 0xc00016a260,
0xb14cb0, 0xfc63b0)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/g/varcompute.go:29
+0x156
hmi-server/agent/cron.(*DeviceOpc).reportData.func1(0xbf4cad82ee7bb62c,
0x3a043ac3231, 0xfa95c0, 0xc002ae2a01, 0x2)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:644
+0xe1
hmi-server/agent/cron.(*DeviceOpc).reportData(0xc0000d0160)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:654
+0x2e0
created by hmi-server/agent/cron.(*DeviceOpc).start
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:300
+0x9c7
goroutine 69 [chan receive, 15 minutes]:
net/rpc.(*Client).Call(...)
C:/Go/src/net/rpc/client.go:322
hmi-server/common/rpc/client.(*SingleConnRpcClient).Send(0xc0001f6d80,
0xc0010b7ab0, 0x4, 0xc000c54101)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/common/rpc/client/single.go:32
+0x24a
hmi-server/agent/g.SendToVarcompute(0xae789e, 0xc, 0x9e85a0, 0xc0002ca9e0,
0x40a9b2, 0x10)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/g/varcompute.go:29
+0x156
hmi-server/agent/cron.(*DeviceOpc).setNetMetric(0xc0000d0420, 0xc00061b430)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:623
+0x136
hmi-server/agent/cron.(*DeviceOpc).collect(0xc0000d0420, 0xc000444000,
0x1b7b, 0x1f9c, 0xc0005e7840, 0x18, 0xc00061b430)
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:596
+0x5bb
created by hmi-server/agent/cron.(*DeviceOpc).start
D:/backstage/newest/hmi-server/code/gopath/src/hmi-server/agent/cron/variable.go:295
+0x6c0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/33615?email_source=notifications&email_token=AKAIVT6KKEQ4LHC3B4ESPXLQEI5I7A5CNFSM4ILHCRRKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HE3S36Q,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKAIVTZ4PEBCA4LPRE6BRBLQEI5I7ANCNFSM4ILHCRRA
.

Yes, the net/rpc package is frozen and not accepting new features. See the last line in https://golang.org/pkg/net/rpc/#pkg-overview.
See https://github.com/golang/go/issues/15236, https://github.com/golang/go/issues/16844. Please use grpc or other mature rpc frameworks.

authors: 756445638 agnivade checkmatesolo


text:
x/blog: Error in defer-panic-and-recover article

What did you expect to see?
func CopyFile(dstName, srcName string) (written int64, err error) {
    src, err := os.Open(srcName)
    defer src.Close()
    if err != nil {
        return
    }

    dst, err := os.Create(dstName)
    defer dst.Close()
    if err != nil {
        return
    }

    return io.Copy(dst, src)
}

What did you see instead?
func CopyFile(dstName, srcName string) (written int64, err error) {
    src, err := os.Open(srcName)
    if err != nil {
        return
    }
    defer src.Close()

    dst, err := os.Create(dstName)
    if err != nil {
        return
    }
    defer dst.Close()

    return io.Copy(dst, src)
}

With the current code example, in the case of a non-nil error, the defer isn't stacked before the return occurs, so the function will return without closing the source file.
Little program to prove my point : https://play.golang.org/p/UAdMVffys_P

This aspect of the example is correct and idiomatic as written.
Like most Go functions, os.Open and os.Create return zero-values (in this case, nil pointers) for the other arguments when they return a non-nil error, and calling Close on a nil receiver is generally nonsensical.
In this case, the nonsensical call is masked by the permissiveness of (*os.File).Close. Rather than panicking (as many Close implementations would), it returns ErrInvalid:
https://github.com/golang/go/blob/fc705275c34233ffc1cb34be965f289589de9ba6/src/os/file_unix.go#L230-L232

authors: Xerock bcmills


text:
runtime: TestCallersDeferNilFuncPanic failed in generating traceback (linux/arm64)

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

$ go version
go version devel +acf3ff2e8a Tue Dec 3 17:35:06 2019 +0000 linux/arm64

Does this issue reproduce with the latest release?
Reproducible with the tip.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/xiaji01/.cache/go-build"
GOENV="/home/xiaji01/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/xiaji01/.go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/xiaji01/util/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/xiaji01/util/go/pkg/tool/linux_arm64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/xiaji01/util/go.dbg2/src/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 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build624397069=/tmp/go-build -gno-record-gcc-switches"

What did you do?

cd /src
GO_GCFLAGS='-N -l' ./all.bash
What did you expect to see?
building passes.
What did you see instead?
Testing of runtime package failed:
fatal error: traceback_arm: found jmpdefer when tracing with callback
It turns out TestCallersDeferNilFuncPanic triggers the error in function 'gentraceback', so far I could reproduce the issue with running './all.bash' only, both 'go test ...' and 'go tool dist test' works fine.
My questions:

Does building Go with '-N -l' options make any sense?
Any better way to debug such issues?

Thanks a lot.

@danscales

Does building Go with '-N -l' options make any sense?

Yes, that is fine.

Any better way to debug such issues?

Posting the full stack trace that the program fails with would help.
It would be nice to find a way to get the test to fail by itself. If it fails during a GC interrupt (probably, but hard to tell without the full error log), using GOGC=1 will help tickle that bug. Also running the test in multiple goroutines simultaneously might also help.

Thanks @randall77.
Tried 'GOGC=1' and, multiple-goroutine way and others but no lucky, stack trace is enclosed. Thanks.
==============================================================
fatal error: traceback_arm: found jmpdefer when tracing with callback
runtime stack:
runtime.throw(0x312f1c, 0x38)
/home/xiaji01/work/go.testdefernil/src/runtime/panic.go:1106 +0x54 fp=0xffff5dc21560 sp=0xffff5dc21530 pc=0x488d4
runtime.gentraceback(0x46bb0, 0x4000385d20, 0x0, 0x4000302780, 0x0, 0x0, 0x7fffffff, 0xffff5dc218f0, 0x0, 0x0, ...)
/home/xiaji01/work/go.testdefernil/src/runtime/traceback.go:238 +0x145c fp=0xffff5dc21890 sp=0xffff5dc21560 pc=0x7154c
runtime.addOneOpenDeferFrame.func1()
/home/xiaji01/work/go.testdefernil/src/runtime/panic.go:713 +0x74 fp=0xffff5dc21910 sp=0xffff5dc21890 pc=0x7c604
runtime.systemstack(0xffff5dc21940)
/home/xiaji01/work/go.testdefernil/src/runtime/asm_arm64.s:237 +0xa0 fp=0xffff5dc21920 sp=0xffff5dc21910 pc=0x7e760
runtime.mstart()
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:1077 fp=0xffff5dc21920 sp=0xffff5dc21920 pc=0x4d420
goroutine 35 [running]:
runtime.systemstack_switch()
/home/xiaji01/work/go.testdefernil/src/runtime/asm_arm64.s:182 +0x8 fp=0x4000385c30 sp=0x4000385c20 pc=0x7e6a8
runtime.addOneOpenDeferFrame(0x4000302780, 0x46bb0, 0x4000385d20)
/home/xiaji01/work/go.testdefernil/src/runtime/panic.go:712 +0x64 fp=0x4000385c70 sp=0x4000385c30 pc=0x47bd4
panic(0x2b82e0, 0x5045b0)
/home/xiaji01/work/go.testdefernil/src/runtime/panic.go:921 +0xcc fp=0x4000385d20 sp=0x4000385c70 pc=0x481ec
runtime.panicmem()
/home/xiaji01/work/go.testdefernil/src/runtime/panic.go:212 +0x60 fp=0x4000385d40 sp=0x4000385d20 pc=0x46bb0
runtime.sigpanic()
/home/xiaji01/work/go.testdefernil/src/runtime/signal_unix.go:677 +0xe8 fp=0x4000385d80 sp=0x4000385d40 pc=0x605c8
runtime.jmpdefer(0x400039a0a0, 0x4000385dd8)
/home/xiaji01/work/go.testdefernil/src/runtime/asm_arm64.s:869 +0x1c fp=0x4000385d98 sp=0x4000385d90 pc=0x80cec
created by testing.(*T).Run
/home/xiaji01/work/go.testdefernil/src/testing/testing.go:1005 +0x530
goroutine 1 [chan receive, locked to thread]:
runtime.gopark(0x315a28, 0x4000396178, 0x170e, 0x2)
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:304 +0xb8 fp=0x400031f6e0 sp=0x400031f6b0 pc=0x4b128
runtime.chanrecv(0x4000396120, 0x400031f800, 0x4000000101, 0x11b610)
/home/xiaji01/work/go.testdefernil/src/runtime/chan.go:563 +0x1f0 fp=0x400031f770 sp=0x400031f6e0 pc=0x179b0
runtime.chanrecv1(0x4000396120, 0x400031f800)
/home/xiaji01/work/go.testdefernil/src/runtime/chan.go:433 +0x28 fp=0x400031f7a0 sp=0x400031f770 pc=0x17768
testing.(*T).Run(0x4000398120, 0x30b761, 0x1c, 0x316a80, 0x2a9a33c353000)
/home/xiaji01/work/go.testdefernil/src/testing/testing.go:1006 +0x558 fp=0x400031f910 sp=0x400031f7a0 pc=0x11b638
testing.runTests.func1(0x4000368000)
/home/xiaji01/work/go.testdefernil/src/testing/testing.go:1247 +0xac fp=0x400031f9b0 sp=0x400031f910 pc=0x12092c
testing.tRunner(0x4000368000, 0x400031fb98)
/home/xiaji01/work/go.testdefernil/src/testing/testing.go:954 +0x158 fp=0x400031fab0 sp=0x400031f9b0 pc=0x11b068
testing.runTests(0x400032e0a0, 0x50de20, 0x148, 0x148, 0x4000310100)
/home/xiaji01/work/go.testdefernil/src/testing/testing.go:1245 +0x344 fp=0x400031fbc0 sp=0x400031fab0 pc=0x11d1f4
testing.(*M).Run(0x4000364000, 0x0)
/home/xiaji01/work/go.testdefernil/src/testing/testing.go:1162 +0x378 fp=0x400031fe60 sp=0x400031fbc0 pc=0x11bf78
runtime_test.TestMain(0x4000364000)
/home/xiaji01/work/go.testdefernil/src/runtime/crash_test.go:28 +0x28 fp=0x400031fef0 sp=0x400031fe60 pc=0x1e2178
main.main()
_testmain.go:1172 +0xdc fp=0x400031ff70 sp=0x400031fef0 pc=0x27f8dc
runtime.main()
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:203 +0x1e4 fp=0x400031ffd0 sp=0x400031ff70 pc=0x4ad44
runtime.goexit()
/home/xiaji01/work/go.testdefernil/src/runtime/asm_arm64.s:1148 +0x4 fp=0x400031ffd0 sp=0x400031ffd0 pc=0x81034
goroutine 2 [force gc (idle)]:
runtime.gopark(0x315d28, 0x510aa0, 0x1411, 0x1)
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:304 +0xb8 fp=0x40002a8770 sp=0x40002a8740 pc=0x4b128
runtime.goparkunlock(0x510aa0, 0x4000001411, 0x1)
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:310 +0x4c fp=0x40002a87a0 sp=0x40002a8770 pc=0x4b1dc
runtime.forcegchelper()
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:253 +0xb0 fp=0x40002a87d0 sp=0x40002a87a0 pc=0x4afc0
runtime.goexit()
/home/xiaji01/work/go.testdefernil/src/runtime/asm_arm64.s:1148 +0x4 fp=0x40002a87d0 sp=0x40002a87d0 pc=0x81034
created by runtime.init.5
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:242 +0x30
goroutine 3 [GC sweep wait]:
runtime.gopark(0x315d28, 0x510ec0, 0x140c, 0x1)
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:304 +0xb8 fp=0x40002b6f70 sp=0x40002b6f40 pc=0x4b128
runtime.goparkunlock(0x510ec0, 0x35140c, 0x1)
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:310 +0x4c fp=0x40002b6fa0 sp=0x40002b6f70 pc=0x4b1dc
runtime.bgsweep(0x4000022380)
/home/xiaji01/work/go.testdefernil/src/runtime/mgcsweep.go:70 +0x98 fp=0x40002b6fd0 sp=0x40002b6fa0 pc=0x36ad8
runtime.goexit()
/home/xiaji01/work/go.testdefernil/src/runtime/asm_arm64.s:1148 +0x4 fp=0x40002b6fd0 sp=0x40002b6fd0 pc=0x81034
created by runtime.gcenable
/home/xiaji01/work/go.testdefernil/src/runtime/mgc.go:214 +0x54
goroutine 4 [GC scavenge wait]:
runtime.gopark(0x315d28, 0x510e80, 0x140d, 0x1)
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:304 +0xb8 fp=0x40002bcf20 sp=0x40002bcef0 pc=0x4b128
runtime.goparkunlock(0x510e80, 0x35140d, 0x1)
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:310 +0x4c fp=0x40002bcf50 sp=0x40002bcf20 pc=0x4b1dc
runtime.bgscavenge(0x4000022380)
/home/xiaji01/work/go.testdefernil/src/runtime/mgcscavenge.go:226 +0xd4 fp=0x40002bcfd0 sp=0x40002bcf50 pc=0x35474
runtime.goexit()
/home/xiaji01/work/go.testdefernil/src/runtime/asm_arm64.s:1148 +0x4 fp=0x40002bcfd0 sp=0x40002bcfd0 pc=0x81034
created by runtime.gcenable
/home/xiaji01/work/go.testdefernil/src/runtime/mgc.go:215 +0x74
goroutine 18 [finalizer wait]:
runtime.gopark(0x315d28, 0x53b288, 0x1410, 0x1)
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:304 +0xb8 fp=0x4000384f00 sp=0x4000384ed0 pc=0x4b128
runtime.goparkunlock(0x53b288, 0x4000021410, 0x1)
/home/xiaji01/work/go.testdefernil/src/runtime/proc.go:310 +0x4c fp=0x4000384f30 sp=0x4000384f00 pc=0x4b1dc
runtime.runfinq()
/home/xiaji01/work/go.testdefernil/src/runtime/mfinal.go:175 +0xac fp=0x4000384fd0 sp=0x4000384f30 pc=0x2ce9c
runtime.goexit()
/home/xiaji01/work/go.testdefernil/src/runtime/asm_arm64.s:1148 +0x4 fp=0x4000384fd0 sp=0x4000384fd0 pc=0x81034
created by runtime.createfing
/home/xiaji01/work/go.testdefernil/src/runtime/mfinal.go:156 +0x78
FAIL	runtime	0.025s

@shawn-xdji thanks for the bug report and the stack trace.
I can reproduce this always with debug compilation of the individual runtime test on a linux-arm64 gomote:
cd /workdir/go/src; ../bin/go test -gcflags="-N -l" runtime -test.run TestCallersDeferNilFuncPanic

The issue is that we are calling gentraceback() with a callback in order to look for the next open-coded defer frame to process in the panic case.  But calling gentraceback() with a callback on  arm64 (lr architectures) throws an error if jmpdefer is on the stack (because jmpdefer register manipulation is non-atomic).  This only happens in the one case where the defer pointer is null, since then there is a seg fault on the jmpdefer instruction that jumps though the defer pointer.  Also, it only happens if stack-allocated defers are used (since open-coded defers don't use jmpdefer), hence why this only happens when debug flags are enabled.
The simplest fix is to force the seg fault to happen in deferreturn() just before the jmpdefer().  This will cause one extra load in cases when jmpdefer is used, but that is now rare, since stack-allocated defers are now rare.

Thanks a lot @danscales , I could reproduce the issue using your command line.
Just out of curiosity, why setting GO_GCFLAGS failed to reproduce the issue?
Both the following two work fine.
GO_GCFLAGS=all='-N -l' go test -run=TestCallersDeferNilFuncPanic runtime
GO_GCFLAGS=all='-N -l' go test -run=TestCallersDeferNilFuncPanic runtime

GO_GCFLAGS is only used in make.bash/all.bash. After that it is not used. Use -gcflags instead.

authors: cherrymui danscales randall77 shawn-xdji


text:
x/build: ensure there are accessible ways to test Go pre-release versions in common CI systems

The Go project and its users benefit from additional testing of pre-release versions of Go, because it leads to a stable release with fewer issues. When beta and release candidates are released, we encourage everyone to test them as much as possible and report issues that are uncovered.
There are many CI systems that are in use today (Travis CI, Circle CI, GitHub Actions, and many more). Most of them have some level of support for testing Go code with various release versions of Go, but it's not clear whether pre-release versions are supported as well.
We should ensure it's possible and easy for users to start testing against pre-release versions of Go, so that if someone is willing to do it, we can point them to an existing solution rather than hoping they'll invent it themselves.
It is generally the responsibility of the CI solution itself to offer flexibility in the testing capabilities for its users, but perhaps there are things we can do on our side to help facilitate that.
So, the work here is to check whether this is already possible and convenient for various CI systems. If not, we can see if it can and should be made better through changes on our side. The specifics will depend on the CI system and the tools it offers. It might involve coming up with scripts or configurations, taking advantage of the existing golang.org/dl/... commands, modifying our existing API endpoints (see #34864, #36898), or something else.
This is the tracking issue for that work.
(This idea was suggested to me by @hyangah, and I was reminded about it when seeing @mvdan's https://github.com/golang/go/issues/36898#issuecomment-621915093.)
/cc @golang/osp-team @rsc @mvdan @lyoness

I think this is a good idea. I get why few companies test pre-releaess on their staging or production environments: it's extra work to set up, and extra work to be careful that it can't put the business at risk.
However, there's really no excuse to not run unit and integration tests against Go pre-releases. Most CI systems have an "allow failures" mode that would be a good fit here, so that pre-release failures can be flagged, but they won't be treated as critical.
Since a good portion of CI systems are Docker-based (like Gitlab and Drone), a nice quick win would be to have pre-releases published on Docker Hub, such as betas and RCs. I'm actually not sure why that isn't the case already.
I think another important point to keep in mind is that a general solution shouldn't require a Go version to already be installed. Some CI systems like GitHub Actions have a wide variety of software pre-installed, but that's not the norm. So I don't think we should rely on go get golang.org/dl/$prerelease here.
The only last thought I have here is that it should be easy for the end user to set this up, without having to update their CI config whenever a new beta or RC version is out. This is very related to #36898. That way, the Go project can do a shout-out for people to update their CI configs when the first beta is out, and we don't have to remind everyone to update it every other week as more pre-releases come out. They should all automatically be using the latest pre-release. The only requirement is that the logs print what version is used.

authors: dmitshur mvdan


text:
cmd/go: go build does not reject importing commands

% echo $GOPATH
/tmp/foo
% pwd
/tmp/foo/src/y
% cat main.go
package main
import (
	"fmt"
	xmain "x"
)

func main() {
	fmt.Printf("y main called\n")
	xmain.Main()
}
% cat ../x/main.go
package main
import (
	"fmt"
)

func main() {
	Main()
}

func Main() {
	fmt.Printf("x main called\n")
}

% go build
% y
y main called
x main called
% go install
% go build
# y
./main.go:4: can't find import: "x"
% go install
% rm $GOPATH/bin/y
% go build
# y
./main.go:4: can't find import: "x"
% rm -r $GOPATH/pkg
rm: cannot remove `/tmp/foo/pkg': No such file or directory
% rm $GOPATH/bin/x
% go build
%

It looks as if go build is treating the x binary as a valid prerequisite for the build
of y, which it is not.

Perhaps the build process should take into account the fact that main packages can
compile to both archives and executables.

I'm curious -- what has changed since https://golang.org/cl/4126053?  It seems like the intent of that change was to allow what https://golang.org/cl/10925 is now disallowing.

CL 4126053 is a change to the spec, which describes the language.  The language permits importing a package named main.  That can be used, for example, when writing unit tests for functions in commands that use package main.
This issue here is about the go tool, not the language.  The question is whether the go tool should permit packages to import a package that defines a command.  The general consensus is that it should not.

Got it.  Thanks.

FWIW, this "fixing" commit just made cleanly writing multicall binaries (i.e. Busybox, Toybox, git, etc) take more work, whereas prior to this it was extremely simple.

@extemporalgenome what kind of stuff broke? Can you provide more details?

@adg I've put together a minimal representative example (and explanation in the README) at https://github.com/extemporalgenome/multicall-example

I see, thanks for the thorough example.
I guess the main question is whether the brevity benefit in the minority case is worth the conceptual overhead of encoding what it means for a 'package main' to be importable. The Go tool, at least, is not equipped to deal with this properly.
I'm feeling ambivalent about it. :-/

Indeed. The main points: 1) There is at least one additional legitimate need for which importing main is strictly the simplest/shortest approach. 2) Preventing import of main isn't a direct solution to #4210 --  it merely makes the cause of #4210 impossible. A direct fix seems plausible (make the go tool aware of the difference between binaries and archives), thus I'd argue that the toolchain transparently could become well equipped to deal with these matters properly.
(Oddly enough, #4210 has never affected me -- only the commit closing #4210 will affect me).
If the toolchain change remains in place or is explicitly re-ordained, it needs to be addressed in the specification. The spec currently doesn't have any "Implementation restriction:" notes that allow the toolchain to prohibit imports of main, thus with this change, the toolchain at best supports only a subset of the [current] language.
That said, the previously mentioned CL 4126053 removed a yet-earlier language-level prohibition of such imports. Since the official toolchain is, clearly, the canonical Go implementation, toolchain changes of this nature are defacto language changes, thus this would be a defacto reversal of the prior consensus reached in the codereview 4126053.
I would personally be fully satisfied if all the LGTM's from 4126053 also put LGTM's on CL 10925, though I can't speak for @kevinwallace, who also has the same use-case as I do, and would also need to reorganize code if Ian's commit sticks through to the 1.5 release.
Additionally/alternatively, I will be at GopherCon (including the optional days), and will happily demonstrate my counter-case; if informed consensus occurs in either direction, I will of course graciously yield.

FWIW, my code has already been reorganized to work around this, and while I would be happy to see an outcome that allows importing of main packages, I'm not particularly attached to that outcome at this point.

authors: adg extemporalgenome ianlancetaylor kevinwallace rogpeppe


text:
cmd/compile: optimize maps with bool keys

In programming, sometimes it is less verbose by using a map with bool key than using an if-else block. For example:
    if condition {
        counter++
    } else {
        counter--
    }

vs.
var boolToInt = map[bool]int{true: 1, false: 0}
...

    counter += boolToInt[condition]

Or
    if condition {
        f(...)
    } else {
        g(...)
    }

vs.
var boolToFunc = map[bool]func(...){true: f, false: g}
...

    boolToFunc[condition](...)

However, currently, the map form is much less efficient than the if-else block form:
package main

import (
	"testing"
)

func f(x bool) int {
	if x {
		return 1
	} else {
		return 0
	}
}

var m = map[bool]int{true: 1, false: 0}
func g(x bool) int {
	return m[x]
}

var fr, gr int

func Benchmark_f(b *testing.B) {
	for i := 0; i < b.N; i++ {
		fr = f(true)
		fr = f(false)
	}
}

func Benchmark_g(b *testing.B) {
	for i := 0; i < b.N; i++ {
		gr = g(true)
		gr = g(false)
	}
}

Benchmark_f-4   	1000000000	         0.7478 ns/op
Benchmark_g-4   	19250287	        60.28 ns/op

Maps with bool keys could contain at most two entries, so I think it will be not hard to make optimizations for them.
If this could be implemented, it will be much helpful to improve performance for some Go programs.

This isn't an API change, so moving it out of the proposal process.  This is a feature request for the compiler.

Why don’t you want to use the f version? Seems easier than adding edge cases in the map implementation? It would be extremely difficult for the compiler to use constant propogration to optimise g to the point that f has been
btw, I’m pretty confident that f have been optimised into a loop that assigns fr = 0

Why don’t you want to use the f version?

Verbose, in particular there are many occurrences of such if-else blocks.
The f function is just for benchmark purpose here. In reality, it may be a code snippet and the arguments to its calls may be not constants.

I admit that we could use small functions to replace the maps, by harming a little gracefulness.
var m = func(condiiton bool) {
    if condition {
        counter++ // or f(...)
    } else {
        counter-- // or g(...)
    }
}

However, it gives people the impression that maps with bool keys are not recommended to be used generally.
So I don't think this optimization is an edge case, at least it doesn't belong to the edgest ones.
It makes the map use cases more complete.
Though, if it increases the code maintenance code much, I agree that it should not be implemented.

However, it gives people the impression that maps with bool keys are not recommended to be used generally.

I don't think this interpretation is incorrect.

cc @mdempsky

If booleans can be converted to integers, or there is simple builtin way to do this, then this optimization will become not very necessary:
var functions = []func(...){g, f}
...

    functions[int(condition])(...)

cc @josharian

If booleans can be converted to integers, or there is simple builtin way to do this, then this optimization will become not very necessary:

What about:
func BoolToInt(x bool) int {
	v := 0
	if x {
		v = 1
	}
	return v
}

It is ok and actually often acceptable to use a custom bool-to-int function,
though it would be better that Go could provide a cleaner and simpler way.
BTW, the bool-to-int+slice solution is a little less performant than the optimized map-with-bool-key solution, for bound checking reason.

If you add &1 to the indexing, the bounds check will go away.
SSA should probably be able to handle bounds checking phi operands though. I imagine there's already a feature request issue for this.

Now, it looks only the &1+array way eliminates bound checking, other ways don't:
package main

func BoolToInt(x bool) int {
	v := 0
	if x {
		v = 1
	}
	return v
}

var functions = [...]func(){func(){}, func(){}}
var bs = []bool{true, false, false, true}

func main() {
	for _, b := range bs {
		functions[BoolToInt(b)&1]()
	}
}

Though it is not the cleanest and most efficient solution, now I think the optimization for maps with bool keys is not very essential in practice. On the other hand, it would be still great if the optimization could be supported, for aesthetics perfection.
So please close this issue, or keep it open if it is still worth being implemented.

authors: davecheney go101 ianlancetaylor mdempsky networkimprov


text:
meta: high rate of 5XX errors from go.googlesource.com since 2021-09-08

#!watchflakes
post <- `https://go\.googlesource\.com.*: The requested URL returned error: 5\d\d`

Some of the cmd/go long-mode tests end up cloning repos controlled by the Go project, such as golang.org/x/sys.
Other long-mode tests send requests to a dedicated test server (vcs-test.golang.org), various GitHub repos, packages hosted on rsc.io, and gopkg.in. The failure rate against vcs-test.golang.org is, as far as I can tell, negligible. The GitHub and gopkg.in tests for the most part check integration with services outside the control of the Go project. The rsc.io tests have a low but nontrivial failure rate (filed as #49954), and could perhaps be migrated to vcs-test.golang.org if need be.
However, the dependency on go.googlesource.com for the x repos is not easy to avoid, and as far as I can tell its failure rate since September has dwarfed all of those other services. Many of these failures already result in long (2m+) hangs that could otherwise push the test over its deadline, so I don't think it would be viable to just add retries (#28194) — especially given that if the problem could be fixed by retrying, the server could presumably do that retry internally itself.
I would rather not lose coverage or add complexity to the tests by fetching the Go repos only through proxy.golang.org — @golang/release, is it viable to get a higher SLA on go.googlesource.com?

greplogs --dashboard -md -l -e 'https://go\.googlesource\.com.* 5\d\d\b' --since=2021-01-01

2022-01-10T17:06:19-9e7ea35/linux-386-longtest
2022-01-05T21:22:03-2b39d86/linux-386-longtest
2021-12-08T15:30:52-9fe77de/linux-amd64-longtest
2021-12-03T21:23:11-b3e1fbf/linux-386-longtest
2021-12-02T23:34:26-5f65520/linux-386-longtest
2021-12-02T22:03:11-d3bf627/linux-386-longtest
2021-12-02T20:49:56-bbe1be5/linux-386-longtest
2021-12-02T20:45:47-3c6295d/linux-386-longtest
2021-12-01T17:13:34-08ecdf7/linux-386-longtest
2021-11-30T20:04:58-7ccbcc9/linux-386-longtest
2021-11-30T18:49:39-5f63f16/linux-amd64-longtest
2021-11-30T18:09:02-931d80e/linux-386-longtest
2021-11-30T18:09:02-931d80e/linux-amd64-longtest
2021-11-29T22:02:48-2f6d382/linux-386-longtest
2021-11-24T21:11:45-b77f5f9/linux-386-longtest
2021-11-24T21:09:36-7e5331a/linux-amd64-longtest
2021-11-23T19:31:05-0f64c21/linux-amd64-longtest
2021-11-19T21:36:17-0f75a9e/linux-amd64-longtest
2021-11-16T14:33:48-50dac3b/linux-386-longtest
2021-11-11T20:20:42-3e94140/linux-386-longtest
2021-11-11T13:58:28-d76b1ac/linux-386-longtest
2021-11-10T18:24:14-6406e09/linux-amd64-longtest
2021-11-09T22:58:24-578ada4/linux-386-longtest
2021-11-09T19:01:20-526b2ef/linux-386-longtest
2021-11-09T18:23:16-55e6e82/linux-amd64-longtest
2021-11-08T16:44:14-7ee3f14/linux-amd64-longtest
2021-11-05T17:47:28-6f32d20/linux-386-longtest
2021-11-05T00:52:04-1c4cfd8/linux-386-longtest
2021-11-04T21:52:36-8ad0a7e/linux-386-longtest
2021-11-04T14:17:18-901bf29/linux-386-longtest
2021-11-03T20:30:17-7f2463c/linux-amd64-longtest
2021-11-02T13:43:24-4d7bf41/linux-386-longtest
2021-11-01T19:42:30-5f1bcd1/linux-386-longtest
2021-11-01T15:55:29-0ae4c7f/linux-amd64-longtest
2021-10-29T19:35:47-5ec139f/linux-386-longtest
2021-10-29T18:56:29-6afdf01/linux-386-longtest
2021-10-29T18:35:59-5ec2427/linux-386-longtest
2021-10-29T18:35:20-9ac1ee2/linux-386-longtest
2021-10-29T18:23:03-413672f/linux-386-longtest
2021-10-28T20:27:44-5e21728/linux-amd64-longtest
2021-10-28T16:54:29-5fce1d9/linux-386-longtest
2021-10-28T01:15:26-b2fe2eb/linux-386-longtest
2021-10-27T21:37:54-749f6e9/linux-386-longtest
2021-10-27T20:24:48-a155a30/linux-386-longtest
2021-10-27T20:03:17-68bd512/linux-386-longtest
2021-10-27T19:34:49-ffd2284/linux-386-longtest
2021-10-27T19:18:20-514ebae/linux-386-longtest
2021-10-27T18:08:49-bb49eb3/linux-386-longtest
2021-10-26T20:12:32-f8779b9/linux-amd64-longtest
2021-10-26T17:10:45-76cef81/linux-amd64-longtest
2021-10-26T14:24:17-283d8a3/linux-386-longtest
2021-10-25T17:46:41-9012996/linux-amd64-longtest
2021-10-22T00:57:18-9ff91b9/linux-amd64-longtest
2021-10-21T19:08:43-b8da7e4/linux-386-longtest
2021-10-21T02:35:47-fca46d0/linux-386-longtest
2021-10-12T20:20:41-d032b2b/linux-386-longtest
2021-10-12T14:32:53-36a265a/linux-386-longtest
2021-10-05T19:28:36-7ae83c8/linux-386-longtest
2021-10-01T14:30:33-8d494b0/linux-386-longtest
2021-09-27T19:42:34-315cec2/linux-386-longtest
2021-09-21T14:02:52-7d67f8d/linux-amd64-longtest
2021-09-15T17:32:52-6196979/linux-386-longtest
2021-09-15T17:32:52-6196979/linux-amd64-longtest
2021-09-15T16:32:27-72bb818/linux-386-longtest
2021-09-15T16:32:27-72bb818/linux-amd64-longtest
2021-09-14T23:20:18-2933c45/linux-386-longtest
2021-09-14T23:07:15-137543b/linux-amd64-longtest
2021-09-14T23:03:28-3a72175/linux-amd64-longtest
2021-09-13T21:48:41-42057e9/linux-386-longtest
2021-09-13T20:42:44-81a4fe6/linux-386-longtest
2021-09-09T01:25:40-d4579c2-d62866e/darwin-arm64-11_0-toothrot
2021-09-08T16:59:47-d419f9c/linux-amd64-longtest
2021-09-08T16:19:36-409434d/linux-386-longtest
2021-05-26T22:43:54-1d5298d/linux-amd64-longtest

is it viable to get a higher SLA on go.googlesource.com?

We should also check to make sure these errors are accurately reflected in the monitoring for these services. (It isn't obvious to me that they are even showing up.)

https://storage.googleapis.com/go-build-log/ddd0e862/linux-386-longtest_852ae099.log (a TryBot on https://go.dev/cl/382839)

greplogs -l -e 'https://go\.googlesource\.com.* 5\d\d\b' --since=2022-04-12
2022-04-27T17:20:34-f0ee7fd/linux-386-longtest
And I've noticed another log pattern that seems to be the same failure mode, just through the git binary instead of go:
greplogs -l -e 'golang\.org/x.*: git fetch .*: exit status 128:\n\s+.*The requested URL returned error: 502' --since=2021-01-01
2022-05-02T17:05:14-64369c3/linux-386-longtest
2022-04-28T15:11:42-4d35071/linux-amd64-longtest
2022-01-21T16:59:19-9eba5ff/linux-amd64-longtest
2022-01-20T19:24:26-2c2e081/linux-386-longtest
2022-01-10T22:48:40-6019a52/linux-amd64-longtest
2022-01-05T21:22:03-2b39d86/linux-386-longtest
2021-12-02T22:03:54-25f06cb/linux-386-longtest
2021-11-30T18:09:02-931d80e/linux-amd64-longtest
2021-11-10T18:24:14-6406e09/linux-amd64-longtest
2021-11-09T19:01:20-526b2ef/linux-386-longtest
2021-11-04T21:52:36-8ad0a7e/linux-386-longtest
2021-11-01T22:55:50-02e5913/linux-amd64-longtest
2021-10-29T18:56:29-6afdf01/linux-386-longtest
2021-10-28T16:54:29-5fce1d9/linux-386-longtest
2021-10-28T16:08:36-6f0185b/linux-386-longtest
2021-10-27T21:37:54-749f6e9/linux-386-longtest
2021-10-27T20:03:17-68bd512/linux-386-longtest
2021-10-26T21:17:38-091db63/linux-amd64-longtest
2021-10-22T00:57:18-9ff91b9/linux-amd64-longtest
2021-10-12T20:20:41-d032b2b/linux-386-longtest
2021-09-15T17:32:52-6196979/linux-amd64-longtest
2021-09-15T16:32:27-72bb818/linux-386-longtest
2021-09-14T23:07:15-137543b/linux-amd64-longtest
2021-09-14T23:03:28-3a72175/linux-386-longtest
2021-09-08T16:19:36-409434d/linux-386-longtest
2021-06-28T23:31:05-1519271/linux-amd64-longtest
2021-05-26T22:43:54-1d5298d/linux-amd64-longtest

greplogs -l -e 'golang\.org/x.* git .*\n(\s+.*)*The requested URL returned error: 502' --since=2022-05-03
2022-05-05T14:26:30-1926fa5/linux-amd64-longtest

greplogs -l -e 'golang\.org/x.* git .*\n(\s+.*)*The requested URL returned error: 502' --since=2022-05-05
2022-05-09T20:24:02-13bda0e/linux-amd64-longtest
2022-05-09T18:06:51-0d410d6/linux-amd64-longtest
2022-05-09T16:02:28-9ae7dc3/linux-amd64-longtest
2022-05-05T14:26:30-1926fa5/linux-amd64-longtest

Converting mod_invalid_version to use the local vcweb would help a lot with these; it seems to be the one that hits this most often.


text:
net/http: TestServerConnState failures missing second active state after TLS handshake errors

2022/03/30 05:35:07 http: TLS handshake error from 127.0.0.1:14164: EOF
2022/03/30 05:35:07 http: TLS handshake error from 127.0.0.1:33976: EOF
2022/03/30 05:35:07 http: TLS handshake error from 127.0.0.1:18644: EOF
--- FAIL: TestServerConnState (0.17s)
    serve_test.go:4199: unexpected conn in state new
    serve_test.go:4199: unexpected conn in state active
    serve_test.go:4199: unexpected conn in state closed
    serve_test.go:4241: Request(s) produced unexpected state sequence.
        Got:  [new active idle closed]
        Want: [new active idle active closed]
FAIL
FAIL	net/http	42.044s

greplogs --dashboard -md -l -e 'FAIL: TestServerConnState .*(\n    .*)*Got:\s+\[new active idle closed\]'
2022-03-29T17:21:21-f71daa6/openbsd-arm64-jsing
2022-01-19T20:54:49-1efc581/plan9-arm
2021-11-17T19:50:58-88474d4/openbsd-386-68
(CC @neild)

Most (but not all) of the failures in #56577 are this failure mode. Should we dupe this into that bug?

Yep, that seems fine.

Duplicate of #56577

authors: bcmills prattmic


text:
x/perf: regressions dashboard broken: panic: index out of range

https://perf.golang.org/dashboard/?benchmark=regressions is broken due to a panic in the handler:
2022/09/19 21:52:14 http2: panic serving 10.102.129.129:15437: runtime error: index out of range [341] with length 341
goroutine 2971853 [running]:
net/http.(*http2serverConn).runHandler.func1()
 /usr/local/go/src/net/http/h2_bundle.go:5896 +0x125
panic({0xeb82c0, 0xc0004128b8})
 /usr/local/go/src/runtime/panic.go:838 +0x207
golang.org/x/build/perf/app.renameBenchmarksWithRegressions({0xc0000a8700, 0xcf, 0xcf?}, 0xb7782e?)
 /app/perf/app/dashboard.go:394 +0x4bd
golang.org/x/build/perf/app.groupBenchmarkResults(0xf6c917?, 0x1)
 /app/perf/app/dashboard.go:426 +0x65
golang.org/x/build/perf/app.fetchAllBenchmarks({0x10a8b10, 0xc000b2b3c0}, {0x10a8d78, 0xc0007345c0}, 0x48?, {0x450797?, 0x23?, 0x1b8e440?}, {0xc0c25702dd2d545a, 0x1e0f2939c9606, ...})
 /app/perf/app/dashboard.go:272 +0x1a5
2022-09-19 14:52:14.146 PDT
...

I don't immediately see why this is occurring, but perhaps we have 2 benchmarks with the same name, leading to a collision in the regressions map. I can take a longer look later.
cc @dr2chase @mknyszek

This has actually resolved itself, even when extending the view to 90 days, which is odd.


text:
cmd/link: Add DW_AT_decl_line for DW_TAG_subprogram in DWARF table

Currently, the DWARF table does not contain DW_AT_decl_line in the DW_TAG_subprogram entries, i.e. the source code line number of the function definition is not listed in the DWARF entry of said function. I propose to add this information to the DWARF table.
DW_AT_decl_line of functions is needed to convert absolute line numbers into relative line numbers w.r.t. to the first line of the function from DWARF information. Such information is useful in the context of PGO.
CC @aclements

cc @cherrymui @thanm

I am fairly certain that adding new DWARF data does not require the proposal process. Removing.

@hoeppi-google is this attribute needed for subprogram corresponding to abstract functions? Or only regular DW_TAG_subprogram entries corresponding to vanilla functions?

discussed this offline with @prattmic , sounds like we need abstract function support as well.

authors: hoeppi-google prattmic thanm


text:
x/tools/go/ssa: function.Origin() panics with "index out of range"

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

$ go version
go version go1.20.2 darwin/arm64

Does this issue reproduce with the latest release?
Yes, 1.20.2 is the latest release.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN="/Users/ayke/bin"
GOCACHE="/Users/ayke/Library/Caches/go-build"
GOENV="/Users/ayke/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/ayke/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/ayke/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/homebrew/Cellar/go/1.20.2/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/homebrew/Cellar/go/1.20.2/libexec/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.20.2"
GCCGO="gccgo"
AR="ar"
CC="cc"
CXX="c++"
CGO_ENABLED="1"
GOMOD="/Users/ayke/src/ayke/sandbox/ssabug/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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/17/btmpymwj0wv6n50cmslwyr900000gn/T/go-build3633563543=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
To reproduce:

clone https://github.com/aykevl/sandbox
go to the ssabug subdirectory
run go run .

What did you expect to see?
I expected .Origin() (last line of the program) to return something sensible.
What did you see instead?
It panics. Here is the complete output of the program, including all debug prints:
~/src/ayke/sandbox/ssabug$ go run .
Test: ssabug/testa.Test
# Name: ssabug/testa.Test
# Package: ssabug/testa
# Location: /Users/ayke/src/ayke/sandbox/ssabug/testa/testa.go:7:6
func Test():
0:                                                                entry P:0 S:0
	t0 = ssabug/value.Map[int]()                 ssabug/value.ValueItf[int]
	return

map call: ssabug/value.Map[int]()
map fn: ssabug/value.Map[int]
# Name: ssabug/value.Map[int]
# Synthetic: instance of Map
# Location: /Users/ayke/src/ayke/sandbox/ssabug/value/value.go:16:6
func Map[int]() ValueItf[int]:
0:                                                                entry P:0 S:0
	t0 = new Mapper[int] (complit)                             *Mapper[int]
	t1 = make ValueItf[int] <- *Mapper[int] (t0)              ValueItf[int]
	return t1

make inst: make ValueItf[int] <- *Mapper[int] (t0)
method: (*ssabug/value.Mapper[int]).Get[int]
# Name: (*ssabug/value.Mapper[int]).Get[int]
# Synthetic: instance of Get
# Location: /Users/ayke/src/ayke/sandbox/ssabug/value/value.go:11:21
func (m *Mapper[int]) Get[int](fn func()):
0:                                                                entry P:0 S:0
	t0 = &m.V [#0]                                           *ValueItf[int]
	t1 = *t0                                                  ValueItf[int]
	t2 = invoke t1.Get((*Mapper[int]).Get[int]$1)                        ()
	return

param: (*ssabug/value.Mapper[int]).Get[int]$1
panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
golang.org/x/tools/go/ssa.(*Function).Origin(0x140002d6a80)
	/Users/ayke/go/pkg/mod/golang.org/x/tools@v0.7.0/go/ssa/ssa.go:1543 +0x70
main.readPackage(0x140002d4080)
	/Users/ayke/src/ayke/sandbox/ssabug/main.go:58 +0x400
main.main()
	/Users/ayke/src/ayke/sandbox/ssabug/main.go:31 +0x180
exit status 2

Note: I have also found a race condition when working with two SSA packages in a sing
le *ssa.Program that contains generics, but haven't been able to create a solid reproducer yet. I do feel like this bug could be related to that race condition.
Original issue found in https://github.com/tinygo-org/tinygo/pull/3593.

IIUC the key issue seems to be that in the test, the following happens:

ssa.Packages ssabug/testa and ssabug/value are created.
testa imports value.
testa is pkg.Build() value is not pkg.Build().
InstantiateGenerics is on.
value.Map[int]() is built. So (*ssabug/value.Mapper[int]).Get[int] is built too.
The test then asks for the Origin of (*ssabug/value.Mapper[int]).Get[int]$1.
(*ssabug/value.Mapper[T]).Get[T]$1 has not been built and its body & AnonFuncs list is empty.
There is the seen array out of bounds access.

This can be resolved by making sure the "value" package is built before asking for the Origin. Or by building the ssa.Program.
I think my question is what are you hoping for the "sensible" output to be? Are you hoping to get nil as the result? Are you hoping for the "value" package to get built if you happened to request this? A more user friendly panic message?
FWIW are you sure you do not want to build value as a stub package? (See buildssa for how to do this.) You would not have the body of (*ssabug/value.Mapper[int]).Get[int] either if this is how this was built.

Note: I have also found a race condition when working with two SSA packages in a single *ssa.Program that contains generics, but haven't been able to create a solid reproducer yet.

I'll be happy to take a look once you have more info.

Thank you for investigating!

I think my question is what are you hoping for the "sensible" output to be? Are you hoping to get nil as the result? Are you hoping for the "value" package to get built if you happened to request this? A more user friendly panic message?

I am not entirely sure. At the very least, a more useful panic message would go a long way. Also, documentation that says how this case should be handled would be helpful, something like "Origin() on a function instantiated from a different package needs to have that package already built" - not sure how to phrase this correctly.

FWIW are you sure you do not want to build value as a stub package? (See buildssa for how to do this.) You would not have the body of (*ssabug/value.Mapper[int]).Get[int] either if this is how this was built.

Hmm, perhaps I need to do this. I think the last time I tried this I ran into some issues, but I can try again.
What I really want is to get the AST node from which the generic function was built. Unfortunately, Syntax() returns nil on instantiated functions. Hence why I need to call Origin() to get the generic function so I can call Syntax(). If Origin() doesn't work across packages, then I don't think there is an API to do what I want. Do you have any suggestions?

Note: I have also found a race condition when working with two SSA packages in a single *ssa.Program that contains generics, but haven't been able to create a solid reproducer yet.

I'll be happy to take a look once you have more info.

I'm pretty sure this is a related bug, as I build the programs in parallel (which means that one pkg.Build() might not be finished before another package starts accessing its generic functions - this works fine outside generics). But if it's still present after I find a fix for the index out of range panic, then I can file a separate bug.

Building the dependencies first indeed appears to fix the problem. It does complicate the build a little bit though.

Note: I have also found a race condition when working with two SSA packages in a single *ssa.Program that contains generics, but haven't been able to create a solid reproducer yet.

I'll be happy to take a look once you have more info.

I have finally managed to make a reproducer for this race condition, and made a bug report here: https://github.com/golang/go/issues/63247

authors: aykevl timothy-king


text:
clarify WSL support policy

In triage we were discussing #63329 and we weren't actually sure what the support policy is for WSL1 vs. WSL2. Currently, our builders only build against WSL2, so it's not super surprising that WSL1 has some issues we haven't seen. Looking at https://github.com/golang/go/wiki/PortingPolicy, I don't see any concrete statement about this. It is a somewhat unique platform, so it would be good to identify what our support policy is and how we should handle such issues.
CC @golang/windows

It's not an explicit policy, but in general for configurations for which we don't have a builder (WSL1, unusual git versions, unusual container environments, QEMU, etc.) we have tended to accept patches for simple/straightforward fixes, but not actively fix them ourselves (since we don't have a way to test a potential fix) and not accept complicated workarounds (since we don't have a way to run regression tests to verify that the workaround continues to work).

I've discussed about this issue with my team at Microsoft, and we might be interested on keeping WSL1 supported a bit more. We will evaluate if there is a need for that to happen and also how can we help supporting it.

Hi all 👋🏼 I'm the Go Group manager at Microsoft. We've been discussing this internally and checking usage with customers. One question we had was whether it would be possible to add a question to the next Go quarterly survey about WSL1 usage.
We know from the previous survey that ~15% of those who answered were developing on WSL but this didn't specifically ask the question as to which version of WSL they were using.

CC @alicemerrick @fflewddur see previous comment

That is something we could add as a follow up on the survey if there’s room. What’s your criteria for determining whether to support WSL1 ? For example, if more than x% of WSL users are using WSL1, we will support it a bit more.

That is something we could add as a follow up on the survey if there’s room. What’s your criteria for determining whether to support WSL1 ? For example, if more than x% of WSL users are using WSL1, we will support it a bit more.

Yeah we'd like to better understand how many people in the community are still using WSL1. That number will help us determine a path forwards supporting it

Hi @gdams! I wanted to let you know this question was included in our latest survey. The survey is still in the field, but we have early results: currently we see 93% of respondents who use WSL saying they use WSL v2, 1% use WSL v1, 2% say they use both, and 4% aren't sure.
This is from 426 developers who work with WSL, but given the lopsided distribution and our randomized sampling, I don't expect these numbers to meaningfully shift over the next two weeks. We'll share the final numbers once the survey closes on Feb 11.

Hi @fflewddur,
Thanks very much for sharing your findings here, based on our internal findings, as well as the ones from the community survey, we (the Go team at Microsoft) don't see any reason to provide additional support WSL1. We will be focussing on WSL2 going forwards.

authors: alicemerrick bcmills fflewddur gdams ianlancetaylor mknyszek qmuntal


text:
net/http/httptest: Server does not check GetCertificate

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

go version go1.21.3 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
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/mitar/.cache/go-build'
GOENV='/home/mitar/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/mitar/.go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/mitar/.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.21.3'
GCCGO='/usr/bin/gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
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-build488527063=/tmp/go-build -gno-record-gcc-switches'

What did you do?
I am trying to test a http.Server instance with httptest's Server:
	ts := httptest.NewUnstartedServer(nil)
	ts.EnableHTTP2 = true
	ts.Config = server
	ts.Config.Handler = http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(http.StatusOK)
	})
	ts.TLS = server.TLSConfig.Clone()
	ts.StartTLS()

I want to check that server's TLS configuration works. Server's TLS configuration uses GetCertificate
What did you expect to see?
That once I call StartTLS is called, GetCertificate is called to obtain the certificate to configure the testing server and testing client.
What did you see instead?
StartTLS ignores and never calls GetCertificate but instead configures testing server and testing client to use testing certificate.
Discussion
I can call something like:

	cert, _ := ts.TLS.GetCertificate(nil) // or some other relevant ClientHelloInfo for 127.0.0.1
	ts.TLS.Certificates = []tls.Certificate{*cert}

before calling StartTLS. But ideally that should be called by StartTLS. This is documented in tls.Config:
	// Server configurations must set one of Certificates, GetCertificate or
	// GetConfigForClient.

Currently only Certificates is checked, but GetCertificate or GetConfigForClient are ignored.
My motivation is to do a test with golang.org/x/crypto/acme/autocert serving as manager against Pebble to test that http.Server's configuration and everything works correctly.

The source of the issue is here:
https://github.com/golang/go/blob/883f062fc0a097bf561030ad453fd3e300896975/src/net/http/httptest/server.go#L167-L169
I guess it could also check if GetCertificate != nil. But then I don't know what the Certificate method is supposed to return in that case.
I'll also note that this behavior of httptest.Server seems to be completely undocumented.

I thnk GetCertificate should be called with 127.0.0.1 (or more precisely s.Listener.Addr().String()) as a parameter. That is what it gets set in s.URL.

GetCertificate takes an entire ClientHelloInfo, not just a hostname.

@rittneje, yes, I know. What I mean that it should be a dummy ClientHelloInfo with s.Listener.Addr().

authors: mitar rittneje


text:
crypto/ecdsa: ecdsa.Sign() has become indeterministic in go 1.21.6

Go version
go version go1.21.6 X:boringcrypto linux/amd64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/go/.cache'
GOENV='/home/skumar12/.config/go/env'
GOEXE=''
GOEXPERIMENT='boringcrypto'
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/skumar12/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/skumar12/go'
GOPRIVATE=''
GOPROXY=''
GOROOT='/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/recipe-sysroot-native/usr/lib/go'
GOSUMDB='sum.golang.org'
GOTMPDIR='/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/build-tmp'
GOTOOLCHAIN=''
GOTOOLDIR='/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/recipe-sysroot-native/usr/lib/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.6 X:boringcrypto'
GCCGO='gccgo'
GOAMD64='v1'
AR='x86_64-ion-linux-gcc-ar'
CC='x86_64-ion-linux-gcc  -m64 -march=nehalem -mtune=generic -mfpmath=sse -msse4.2 --sysroot=/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/recipe-sysroot'
CXX='x86_64-ion-linux-g++  -m64 -march=nehalem -mtune=generic -mfpmath=sse -msse4.2 --sysroot=/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/recipe-sysroot'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/recipe-sysroot= -fdebug-prefix-map=/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/recipe-sysroot-native='
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/recipe-sysroot= -fdebug-prefix-map=/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/recipe-sysroot-native= -fvisibility-inlines-hidden'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -no-pie'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-mtune=generic -mfpmath=sse -msse4.2 --sysroot=/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/recipe-sysroot -I . -fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/ws2/skumar12/element_code2/ap/build/tmp/work/corei7-64-ion-linux/go/1.21.6-r0/build-tmp/go-build1011848331=/tmp/go-build -gno-record-gcc-switches'

What did you do?
We are working on getting FIPS certification for our products and one of the requirement is to run ECDSA and RSA PSS known answer test during boot up time.
We have our own go program which has predefined values for random, private, public keys, message and pre-computed signatures for comparison.
What did you see happen?
In 1.21.6, it seems even with all inputs to ecdsa Sign were predefined, it always generates indeterministic signature.
What did you expect to see?
It used to generate same set of signatures till 1.18.9. Was this a behaviour change recently? Is there a way to make ECDSA signature generation deterministic?
In the same context, is there  a way to set RSA PSS salt length to be 0 so that it becomes deterministic which is possible with openssl?

This looks like a duplicate of to #58637 me.
3adcce5ae7203e9ee7bee93a4ad913a3145e682e
Added this note to the SignASN1 function:

// The signature is randomized. Most applications should use [crypto/rand.Reader]
// as rand. Note that the returned signature does not depend deterministically on
// the bytes read from rand, and may change between calls and/or between versions.

I don't know, cc @FiloSottile as far as I can tell https://pkg.go.dev/filippo.io/keygen only help with deterministic key generation, not the actual Sign functions.

First of all, Go+BoringCrypto is not a supported mode, and we definitely can't assist with FIPS validation requirements in relation to it. Still, I am a bit confused by what you are trying to do, because the BoringCrypto module already has boot self-tests.
Anyway, the fact that Sign is not deterministic and that you can't expect it to stay the same across versions is clearly documented.
// The signature is randomized. Most applications should use [crypto/rand.Reader]
// as rand. Note that the returned signature does not depend deterministically on
// the bytes read from rand, and may change between calls and/or between versions.

We might at some point support deterministic ECDSA, see #64802, but we don't currently.

authors: FiloSottile Jorropo sAnjAy060897


text:
cmd/go: -cover flag is not reported by go version -m

Go version
go version devel go1.23-0767ffdf27 Tue May 14 17:18:10 2024 +0000 linux/amd64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/tmp/go-build'
GOENV='/home/hugo/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/hugo/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/hugo/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/hugo/k/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/home/hugo/k/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.23-0767ffdf27 Tue May 14 17:18:10 2024 +0000'
GODEBUG=''
GCCGO='/usr/bin/gccgo'
GOAMD64='v4'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
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-build428153909=/tmp/go-build -gno-record-gcc-switches'

What did you do?
// a.go
package main

import "fmt"

func main() {
	fmt.Println("☀								🪐")
}

> go build -cover a.go
> go version -m a

What did you see happen?
a: devel go1.23-0767ffdf27 Tue May 14 17:18:10 2024 +0000
	path	command-line-arguments
	build	-buildmode=exe
	build	-compiler=gc
	build	CGO_ENABLED=1
	build	CGO_CFLAGS=
	build	CGO_CPPFLAGS=
	build	CGO_CXXFLAGS=
	build	CGO_LDFLAGS=
	build	GOARCH=amd64
	build	GOOS=linux
	build	GOAMD64=v3

What did you expect to see?
a: devel go1.23-0767ffdf27 Tue May 14 17:18:10 2024 +0000
	path	command-line-arguments
	build	-buildmode=exe
	build	-compiler=gc
	build	-cover=true
	build	CGO_ENABLED=1
	build	CGO_CFLAGS=
	build	CGO_CPPFLAGS=
	build	CGO_CXXFLAGS=
	build	CGO_LDFLAGS=
	build	GOARCH=amd64
	build	GOOS=linux
	build	GOAMD64=v3

@gopherbot please open backport issues


text:
proposal: tool to describe exact dependencies/build environment for plugins to be shareable

Proposal Details
@lukeshu in his response found here https://www.reddit.com/r/golang/comments/b6h8qq/comment/ejkxd2k/
discusses issues he encountered using the plugin package in a real-world use case.
It would be good if there was a tool made or a command or flag in go build that spits out the EXACT dependencies and build environment that was used to build the plugin that the consumer of the plugin has to meet.
That will reduce the barriers of using plugins to create libraries to distribute to others. We can communicate it exactly to the user.
If it was a tool, ideally you can provide the actual library file and the tool would just spit out that information.

See https://github.com/golang/go/issues/63290#issuecomment-1741104730 for one approach.

I believe go version -m is enough.

authors: pjebs seankhliao thepudds


text:
Finalizer not running

What steps will reproduce the problem?
1. Copy the code from here: http://pastie.org/950783
2. Run it: rm -f /tmp/finalizertest && 6g finbug.go && 6l finbug.6
&& ./6.out

What is the expected output? What do you see instead?
When the program exits, I expect /tmp/finalizertest to be deleted, but the finalizer
does not
seem to run.

What is your $GOOS?  $GOARCH?
linux/amd64

Which revision are you using?  (hg identify)
00a2c89d642d+ tip

Could you not use a defer runtime.GC() to (partially) guarantee the finalizer will run, at least for normal process termination?
Example:
func main() {
    defer runtime.GC()
    // ... do some stuff with finalizers
}

@chowey We don't hold discussions on closed issues.  Please see https://golang.org/wiki/Questions .  Thanks.

authors: chowey hoisie ianlancetaylor


text:
cmd/compile: unnecessary zeroing of register on arm

What steps will reproduce the problem?

func add64(a, b int) int {
        x := a + b
        return x
}

What is the expected output? What do you see instead?

Expected (from 6g)

"".add64 t=1 size=32 value=0 args=0x18 locals=0x0
        0x0000 00000 (/home/dfc/src/add64.go:3) TEXT    "".add64+0(SB),4,$0-24
        0x0000 00000 (/home/dfc/src/add64.go:3) NOP     ,
        0x0000 00000 (/home/dfc/src/add64.go:3) NOP     ,
        0x0000 00000 (/home/dfc/src/add64.go:3) FUNCDATA        $2,gclocals·f90cfd099b5ec2b453c391fece9d42bb+0(SB)
        0x0000 00000 (/home/dfc/src/add64.go:3) FUNCDATA        $3,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB)
        0x0000 00000 (/home/dfc/src/add64.go:4) MOVQ    "".a+8(FP),BX
        0x0005 00005 (/home/dfc/src/add64.go:4) MOVQ    "".b+16(FP),BP
        0x000a 00010 (/home/dfc/src/add64.go:4) ADDQ    BP,BX
        0x000d 00013 (/home/dfc/src/add64.go:5) MOVQ    BX,"".~r2+24(FP)
        0x0012 00018 (/home/dfc/src/add64.go:5) RET     ,

But got on 5g

"".add64 t=1 size=24 value=0 args=0xc locals=0x0 leaf
        0x0000 00000 (/home/dfc/src/add64.go:3) TEXT    "".add64+0(SB),16,$-4-12
        0x0000 00000 (/home/dfc/src/add64.go:3) FUNCDATA        $2,gclocals·f90cfd099b5ec2b453c391fece9d42bb+0(SB)
        0x0000 00000 (/home/dfc/src/add64.go:3) FUNCDATA        $3,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB)
        0x0000 00000 (/home/dfc/src/add64.go:3) MOVW    $0,R0
        0x0004 00004 (/home/dfc/src/add64.go:4) MOVW    "".a+0(FP),R0
        0x0008 00008 (/home/dfc/src/add64.go:4) MOVW    "".b+4(FP),R1
        0x000c 00012 (/home/dfc/src/add64.go:4) ADD     R1,R0
        0x0010 00016 (/home/dfc/src/add64.go:5) MOVW    R0,"".~r2+8(FP)
        0x0014 00020 (/home/dfc/src/add64.go:5) B       ,0(R14)

Note the unnecessary zeroing of R0, which is then overwritten by the load of 0(FP)

Please use labels and text to provide additional information.

linux/arm

% go version
go version devel +6b696a34e0af Sun Aug 03 15:14:59 2014 -0700 linux/arm

As of
go version devel +3a067cc812 Fri Dec 9 06:45:08 2016 +0000 linux/amd64
this issue is no longer present:
$ GOARCH=arm go tool compile -S q.go
"".add64 t=1 size=20 args=0xc locals=0x0 leaf
        0x0000 00000 (q.go:3)   TEXT    "".add64(SB), $-4-12
        0x0000 00000 (q.go:3)   FUNCDATA        $0, gclocals·54241e171da8af6ae173d69da0236748(SB)
        0x0000 00000 (q.go:3)   FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (q.go:4)   MOVW    "".a(FP), R0
        0x0004 00004 (q.go:4)   MOVW    "".b+4(FP), R1
        0x0008 00008 (q.go:4)   ADD     R1, R0, R0
        0x000c 00012 (q.go:5)   MOVW    R0, "".~r2+8(FP)
        0x0010 00016 (q.go:5)   JMP     (R14)
...

on arm64 there is unnecessary (imho) more stack check but no zeroing:
$ GOARCH=arm64 go tool compile -S q.go
"".add64 t=1 size=48 args=0x18 locals=0x0 leaf
        0x0000 00000 (q.go:3)   TEXT    "".add64(SB), $-8-24
        0x0000 00000 (q.go:3)   MOVD    16(g), R1
        0x0004 00004 (q.go:3)   MOVD    RSP, R2
        0x0008 00008 (q.go:3)   CMP     R1, R2
        0x000c 00012 (q.go:3)   BLS     36
        0x0010 00016 (q.go:3)   FUNCDATA        ZR, gclocals·54241e171da8af6ae173d69da0236748(SB)
        0x0010 00016 (q.go:3)   FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0010 00016 (q.go:4)   MOVD    "".a(FP), R0
        0x0014 00020 (q.go:4)   MOVD    "".b+8(FP), R1
        0x0018 00024 (q.go:4)   ADD     R1, R0, R0
        0x001c 00028 (q.go:5)   MOVD    R0, "".~r2+16(FP)
        0x0020 00032 (q.go:5)   RET     (R30)
        0x0024 00036 (q.go:5)   NOP
        0x0024 00036 (q.go:3)   PCDATA  $0, $-1
        0x0024 00036 (q.go:3)   MOVD    R30, R3
        0x0028 00040 (q.go:3)   CALL    runtime.morestack_noctxt(SB)
        0x002c 00044 (q.go:3)   JMP     0

Thanks for confirming. Closing.

authors: davecheney navytux


text:
cmd/go: pass line number of generate directive in environment

It would be very useful if the go:generate command gained the ability to pass along file and line to the invoked tool, to avoid redundant definitions.
For example:
//go:generate -l stringer
type Pill int

const (
    Placebo Pill = iota
    Aspirin
)

Could pass along something like "Pill.go:42" to stringer.
Alternately, or in addition to, one could imagine //go:generate supporting a mode where it must be defined right before a type, variable or function, such that it could pass along that information to the tool.

The file name is already there, in $GOFILE.
Perhaps $GOLINE should say 'foo.go:23'.
Plain GOLINE=23 seems too opaque.
@robpike

@rsc Ah, I had missed the $GOFILE environment variable. That's obviously cleaner than having command line arguments to go generate. Adding a $GOLINE to pair with it would be perfect.

authors: prencher rsc


text:
Create sumto.go

This is an efficient way to add number from 1 to say 100.

Sorry, we don't use pull requests.
See https://github.com/golang/go/pull/9220.

And this API addition hasn't been discussed, and I'm sure
we won't add that.

source: gharchive/pull-request


text:
proto3: int64 missing json "string" tag

Running into an issue interoperating between json and protobuf when working across languages when using the int64 type.  As per proto3 spec, the expected json representation for an int64 is a string.  Accordingly, when serializing to json from other languages (e.g. python's MessageToJson) int64 data is serialized to a string.
However, when attempting to call json.Unmarshal(), I'm seeing the following error:
json: cannot unmarshal string into Go struct field Test.data of type int64
In investigating further, this looks to be because the generated go code looks like this
type Test struct {
	Data int64 `protobuf:"varint,1,opt,name=data" json:"data,omitempty"`
}

which is notably missing the ",string" tag (e.g. see here)
Can the ",string" json tag be added so this interoperates correctly, or at least can there be an option to generate it with this tag added?, e.g.
Data int64 `protobuf:"varint,1,opt,name=data" json:"data,string,omitempty"`

For reference, here is the example proto I am using:
syntax = "proto3";

package mytest;

message Test {
    int64 data = 1;
}

Use the jsonpb package for marshaling and unmarshaling between protobufs and JSON.

Adding the json tags was a mistake because it gives the mistaken notion that the standard library json package and jsonpb are compatible. Currently, it is not possible to implement the JSON<->PB spec with json tags alone. I would like to see the json tags removed in the future.

authors: cybrcodr dsnet pullstringjeremy

repo: golang/protobuf

license_source: bigquery


text:
Add a callback to jsonpb.Unmarshaler to report unknown fields.

This is useful when parsing JSON that is expected to exactly match a
protobuf schema, but is permitted to drift slightly. In this case
unknown fields can be reported to higher-level code to decide whether
the parse succeeded.

\cc @cybrcodr
Related to golang/go#15314

Here are my thoughts on this PR.  This requires that user sets AllowUnknownField=true for the handler to be called.  This means if user sets the handler and didn't set AllowUnknownField to true, nothing happens.  I talked to @dsnet regarding this and we have differing opinions on it.
Also, the handler you're proposing is simply given the field name.  I'd expect that it would be more useful if it is allowed to do more with the input value, and hence I'd also suggest naming it as ResolveUnknownField or HandleUnknownField, then again perhaps it can be an interface similar to  AnyResolver.
Anyways, the package does already allow for custom unmarshaling of message if the message implements jsonpb.UnmarshalJSONPB.  This means that the custom unmarshaler can possibly detect for unknown fields.  I understand that it may require a bit more work on your end, but it also allows us time to think of how to handle this situation more appropriately.

authors: cybrcodr dsnet jmillikin-stripe


text:
tour: "many implementations" link is broken

Context: https://tour.golang.org/methods/21
many implementations link is broken - open REDACTED: file does not exist

dup

repo: golang/tour


text:
tour: GoLang Playground states "Error communicating with remote server

Context: https://go.dev/tour/welcome/1
EDIT: Hit 'enter' instead of 'shift'
Attempting to use the "A Tour of Go" page, the web app states "Error communicating with remote server." and exits the program.

noticed there was already an issue opened for this. Closing.


text:
Issues with page objects

OS name and version - Win 10 (x64)
Python version - Python 3.6.3 (v3.6.3:2c5fed8, Oct  3 2017, 17:26:49) [MSC v.1900 32 bit (Intel)] on win32
Golem version - I don't know where I can check it (latest installed with pip)

I faced with the following problem:
For unknown for me reasons golem doesn't save elements in page objects (without showing any tips or message) or doesn't show objects if I fill it in  mode.
Sometimes it erased objects if saved it before.
More details please see on attached videos:
http://recordit.co/by6VOYYFXk
http://recordit.co/yzWWx4bUxC

I am unable to recreate this problem on both windows and mac using the pip version of golem (using chrome on both machines).
In case you used an older version of golem it is recommended to clear the browser cache (learned this from @lucianopuccio)

Hi there.
After some period I've returned to discovering of  Golem and again faced with the same issue.
Now I investigate behavior little bit deeper  (F12 in browser) and  can definitely say that it is not cache . Stacktrace  for my case almost the same like for the issue https://github.com/lucianopuccio/golem/issues/85 with title builtins.TypeError
TypeError: 'NoneType' object is not subscriptable

My assumption that it can be somehow connected with Python version (v.3.6)

I've check my assumption, after re-installation (downshifting) of python 3.6.3 ->3.4.4 Golem works as expected (for now)

Closing. Reopen if this is still happening. Thanks.

authors: ArtemSukhomlyn luciano-renzi r-roos

repo: golemhq/golem

license: MIT


text:
Ability to Deprecate IPs

Instead of deleting an IP from the IPAM, it would be nice to be able to deprecate that. For safety reasons, we set our IPs to deprecated for a period of time before an outside process comes through and reclaims them.

Updating the plugin to have a deprecate on delete flag at the integration level. This does cause the IP to still appear to remove from the UI (otherwise a major rewrite to the sync code would have to be done as well).  Next sync of that network it will come in as deprecated.
Note: This should not cause duplicates with automated IP Addressing since we ask for next available from netbox.

Latest can be found on share. Grab the applicable to your version of Morpheus
https://share.morpheusdata.com/morpheus-netbox-plugin/about

repo: gomorpheus/morpheus-netbox-plugin


text:
Google/CloudMessaging.h' file not found for ios on CORDOVA

Hi guys
I will get this error during build "Google/CloudMessaging.h' file not found"
I have read other reported bugs on same issue, the problem is I am using crodova so there is no pod file for us to change or changing xcode project options,
Has any body ever integrate with cordova or phonegap?

Hi ,
got an error while compiling code
The following build commands failed:
CompileC build/hGCM.build/Debug-iphonesimulator/hGCM.build/Objects-normal/x86_64/GCMPushPlugin.o hGCM/Plugins/cordova-plugin-gcmpushplugin/GCMPushPlugin.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
Ld build/emulator/hGCM.app/hGCM normal x86_64
GenerateDSYMFile build/emulator/hGCM.app.dSYM build/emulator/hGCM.app/hGCM

add   pod 'Google/CloudMessaging' to podfile

authors: RezaRahmati healthyStyle inni-indraneel

repo: gonzaloaune/GCMPushPlugin

license: mit