text:
crypto/x509: go.1.15 onwards CreateCertificate signed by CA cert adds unparseable ASN1 blocks under x509.Certificate.Extensions

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

$ go version
go version go1.16.6 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/golang"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build757437385=/tmp/go-build -gno-record-gcc-switches"

What did you do?
We are trying to upgrade our bullds from go 1.14.4 to latest release. However, blocked by this issue: creating an x509.Certificate with valid signed by a CA w/ BasicConstraints: true set using a self-signed RSA keypair. The certificate has some custom ASN.1 keypair/values under ExtraExtensions. The certificate fails to parse because there is always  an extra pkix.Extension element containing some unparseable ASN.1 data which was not being added in go 1.14.x along with the enbdedded ASN.1 blocks . This issue is observed w/ all releases go 1.15 onwards.
Playground link
Note: Issue is not observed when:
IsCA: false
What did you expect to see?
No error
What did you see instead?
Failure unmarshalling ASN1 Attributes: asn1: structure error: tags don't match (19 vs {class:2 tag:0 length:20 isCompound:false}) {optional:false explicit:false application:false private:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} string @2

Note: the issue is observed with Windows builds as well:
go version
go1.16.6 windows/amd64

This is the X509v3 Authority Key Identifier or authorityKeyIdentifier and you really should be checking the id (since the value could contain anything) before unmarshaling

@seankhliao this behavior was not seen in go 1.14. I've been through the documentation but not able to figure out what has changed in x509.
x509.Certificate.AuthorityKeyId is not initialized explicitly and is taken from the x509.Certificate.SubjectKeyId of the parent as per. Currently it is being set to the default sha1 hash of PublicKey per this from x509.CreateCertificate.
The only way I can work around this is to explicitly drop the new pkix.Extension elements in the final x509.Certificate after the certificate is generated. Would appreciate some guidance on this. I haven't been able to figure out why this is failing in go 1.15 and upwards. Am I creating the certificate wrong?

authors: manuullas seankhliao


text:
affected/package:

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

$ go version

Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?

What did you expect to see?
What did you see instead?

@bmizerany

source: gharchive/issue

repo: golang/go

license_type: permissive

license_source: github-api


text:
https://pkg.go.dev/encoding/base64 needs aa EncodeString() function

The DecodeString() method cannot be removed, but an EncodeString() method should be added as it will not break forward compatibility and conform to a standard naming structure and module offering.
https://pkg.go.dev/encoding/base64

Duplicate of https://github.com/golang/go/issues/51290

authors: andrewhodel davecheney


text:
testing: respect -count when running fuzz corpus tests

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

$ go version
go version go1.18 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/e/.cache/go-build"
GOENV="/home/e/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/e/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/e/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/nix/store/h2w6bc9dpcfvr76cfz8ymv7l5llfjjsj-go-1.18/share/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/nix/store/h2w6bc9dpcfvr76cfz8ymv7l5llfjjsj-go-1.18/share/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/e/Downloads/fuzzcount/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1871101059=/tmp/go-build -gno-record-gcc-switches"

What did you do?
$ cat fuzzcount_test.go
package fuzzcount

import "testing"

func TestA(t *testing.T) {
	t.Logf("TestA: ran")
}

func FuzzA(f *testing.F) {
	f.Add([]byte("test"))
	f.Fuzz(func(t *testing.T, _ []byte) {
		t.Logf("FuzzA: ran")
	})
}
$ go mod init fuzzcount
$ go test -count 5 -v .
=== RUN   TestA
    fuzzcount_test.go:6: TestA: ran
--- PASS: TestA (0.00s)
=== RUN   TestA
    fuzzcount_test.go:6: TestA: ran
--- PASS: TestA (0.00s)
=== RUN   TestA
    fuzzcount_test.go:6: TestA: ran
--- PASS: TestA (0.00s)
=== RUN   TestA
    fuzzcount_test.go:6: TestA: ran
--- PASS: TestA (0.00s)
=== RUN   TestA
    fuzzcount_test.go:6: TestA: ran
--- PASS: TestA (0.00s)
=== RUN   FuzzA
=== RUN   FuzzA/seed#0
    fuzzcount_test.go:12: FuzzA: ran
--- PASS: FuzzA (0.00s)
    --- PASS: FuzzA/seed#0 (0.00s)
PASS
ok  	fuzzcount	0.001s

What did you expect to see?
5 instances of FuzzA: ran.
What did you see instead?
Only one instance of FuzzA: ran.
Specifying -count XX to go test is for repeating test runs XX times; I'd expect the same behaviour for tests implied by a fuzz target corpus.

(attn @golang/fuzzing)

authors: bcmills elias-orijtech


text:
os/signal: Notify leaks a goroutine

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

$ go version
go1.18.1 darwin/arm64

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/inanc/Library/Caches/go-build"
GOENV="/Users/inanc/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/inanc/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/inanc/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m4/qbbxcxxx2h3b_ydm_6j6vhr40000gn/T/go-build3719417202=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
https://go.dev/play/p/Y6Lq4oaMSoi
What did you expect to see?
No leaked goroutine.
What did you see instead?
A goroutine leak:
panic: err

goroutine 1 [running]:
main.main()
        /Users/inanc/.../main.go:17 +0x90

goroutine 33 [syscall]:
os/signal.signal_recv()
        /usr/local/go/src/runtime/sigqueue.go:148 +0x30
os/signal.loop()
        /usr/local/go/src/os/signal/signal_unix.go:23 +0x20
created by os/signal.Notify.func1.1
        /usr/local/go/src/os/signal/signal.go:151 +0x30
exit status 2

I don't know whether this is intentional or not. Is there a way to prevent this leakage?
This previous issue might be related to this one: https://github.com/golang/go/issues/21576

This is working as designed and intended.  We could add a mechanism to shut down that goroutine when no more signals are being handled, but very few programs would ever execute that code path, and even fewer would care about the extra goroutine.  It doesn't seem worth it.

Thanks, @ianlancetaylor. Glad to hear that it's intentional.

authors: ianlancetaylor inancgumus


text:
x/tools/gopls/internal/regtest/modfile: TestUnknownRevision failure with All files must be saved first

#!watchflakes
post <- pkg == "golang.org/x/tools/gopls/internal/regtest/modfile" &&
        test == "TestUnknownRevision" && `All files must be saved first`

greplogs -l -e 'FAIL: TestUnknownRevision.*(?:\n\s+.*)*All files must be saved first' --since=2022-02-01
2022-09-07T18:17:13-3ee1710-dfdf551/linux-s390x-ibm
2022-09-07T16:39:44-dd1bab2-027ff3f/linux-s390x-ibm

I see the race in this test: the test may advance to applying code actions before changes are processed (because there is both a didChange and didSave notification being processed, and we proceed once either of them is done, not both).
I have an in-progress improvement to our expectations that should make it easy to fix this.

Confusingly, there was a second bug (root caused in https://go.dev/cl/461418) which I believe was causing the same symptom, albeit with less frequency and only on s390x, which must have low clock precision.
I'm pretty confident in the fix.

authors: bcmills findleyr


text:
affected/package: FuncForPC not work like 1.8 before

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

$ go version  1.19.4

Does this issue reproduce with the latest release?
no
What operating system and processor architecture are you using (go env)?
go env Output
$ go env  this bug not cast by system

What did you do?
func (ctrl *BaseController) setFunc(f func(), father *BaseController) {
ctrl.rpcFunc = f
ctrl.http = &httpBase{Data: map[string]any{}}
ptr := reflect.ValueOf(f).Pointer()
functionInfo := runtime.FuncForPC(ptr)
file, line := functionInfo.FileLine(ptr)
file = file[strings.LastIndex(file, "/")+1:] //strings.ReplaceAll(file, utils.GetRuntimePath()+"/", "")
name := functionInfo.Name()
file = name[:strings.LastIndex(name, ".")]
file = file[:strings.LastIndex(file, ".")]
name = name[strings.LastIndex(name, ".")+1:]
ctrl.funcName = utils.CombineString(name[strings.LastIndex(name, ".")+1:], "(", file, ":", utils.AllToString(line), ")")
ctrl.father = father
}

What did you expect to see?
if use 1.17 this file and line return the value I want  but now it work not well
it not return the function in witch file and line number
What did you see instead?

You're using a version of Go that is several years out of support. Apologies, but upgrading is the only path forward.

sorry,I edit version by misstake,I use the newest version and this funtion not work properly

please reopen my issue,and I had change content version


text:
plugin: /usr/bin/ld: failed to set dynamic section sizes: bad value

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

$ go version
go version go1.19.6 linux/amd64

Using golang:1.19.6-bullseye Docker image.

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="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.6"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/src/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3821714963=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Trying to build plugin with the following code:
Go playground: https://go.dev/play/p/D0QJ0S09DX7?v=goprev
Ran go build -buildmode=plugin --ldflags '-s -w' -o plugin.so .
What did you expect to see?
Expect plugin.so to be built.
What did you see instead?
The following error:
go build -buildmode=plugin Output
+ go build -buildmode=plugin --ldflags '    -s -w     -X '\''main.Plugin=aperture-plugin-attributesprocessor'\''     -X '\''main.BuildHost=buildkitsandbox'\''     -X '\''main.BuildOS=linux/amd64'\''     -X '\''main.BuildTime=$(date -Iseconds)'\''     -X '\''main.GitBranch='\''     -X '\''main.GitCommitHash='\'' ' -o /plugins/aperture-plugin-attributesprocessor.so .
# github.com/fluxninja/aperture/plugins/agent/aperture-plugin-attributesprocessor
/usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.newParser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.newParser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.newParser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: /tmp/go-link-2649145681/go.o:(*IND*+0x0): multiple definition of `github.com/alecthomas/participle/v2.Build[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"('
/usr/bin/ld: $WORK/b001/exe/a.out.so: version node not found for symbol github.com/alecthomas/participle/v2.(*Parser[go.shape.struct { Invocation github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.invocation "parser:\"(@@\""; Converter *github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.converter "parser:\"|@@)\""; WhereClause *github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl.booleanExpression "parser:\"( 'where' @@ )?\"" }_0]).getElidedTypes
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

Previously, the package attributesprocessor was being used in our main executable. We started seeing this error when we moved the code to build as a plugin.

CC @golang/runtime.

Hmmm, I guess this may be due to that the external linker doesn't like certain characters in the symbol names. Previously only type symbols can contain weird characters, and we mangle them in plugin mode to avoid problems. With generics, function symbols can has well, because it contains the instantiation type, like the case above. I guess we may need to mangle more symbol names. Or, the compiler could drop at least the struct field tags from the shape name (which don't affect GC shape), probably field names as well.

authors: cherrymui dmitshur hasit


text:
cmd/compile: constant propagation on amd64

parent: 16892:ac183442f328 tip

The following program:

package main
func main() {
        println(foo(true))
}
func foo(f bool) int {
        if f {
                return 42
        }
        return -42
}

Generates the following code:

        println(foo(true))
  400c17:       48 c7 c0 01 00 00 00    mov    $0x1,%rax
  400c1e:       80 f8 00                cmp    $0x0,%al
  400c21:       74 1a                   je     400c3d <main.main+0x3d>
  400c23:       48 c7 c0 2a 00 00 00    mov    $0x2a,%rax
  400c2a:       48 89 04 24             mov    %rax,(%rsp)
  400c2e:       e8 7d ce 00 00          callq  40dab0 <runtime.printint>

The compiler can do constant propagation and generate just:
  400c2a:       48 89 04 24             mov    $0x2a,(%rsp)
  400c2e:       e8 7d ce 00 00          callq  40dab0 <runtime.printint>

Here is another missed constant propagation which I believe is more common:
package test
func S() int {
        a := 1
        a += 5
        if a > 1 {
                return 0
        }
        return 9
}

Generated code is
        0x0000 00000 (a.go:2)   TEXT    "".S(SB), $0-8
        0x0000 00000 (a.go:2)   NOP
        0x0000 00000 (a.go:2)   NOP
        0x0000 00000 (a.go:2)   FUNCDATA        $0, gclocals·5184031d3a32a42d85027f073f873668(SB)
        0x0000 00000 (a.go:2)   FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (a.go:3)   MOVQ    $1, BX
        0x0007 00007 (a.go:4)   ADDQ    $5, BX
        0x000b 00011 (a.go:4)   NOP
        0x000b 00011 (a.go:5)   CMPQ    BX, $1
        0x000f 00015 (a.go:5)   JLE     27
        0x0011 00017 (a.go:6)   MOVQ    $0, "".~r0+8(FP)
        0x001a 00026 (a.go:6)   RET
        0x001b 00027 (a.go:8)   MOVQ    $9, "".~r0+8(FP)
        0x0024 00036 (a.go:8)   RET

There are two missed propagation: a += 5 and a > 1. The whole function's body can be replaced with return 9.
Another example involving nil check:
package test
func S() int {
        a := 0
        if &a == nil {
                return 0
        }
        return 9
}

        0x0000 00000 (a.go:2)   TEXT    "".S(SB), $8-8
        0x0000 00000 (a.go:2)   SUBQ    $8, SP
        0x0004 00004 (a.go:2)   FUNCDATA        $0, gclocals·5184031d3a32a42d85027f073f873668(SB)
        0x0004 00004 (a.go:2)   FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0004 00004 (a.go:3)   MOVQ    $0, "".a(SP)
        0x000c 00012 (a.go:4)   LEAQ    "".a(SP), BX
        0x0010 00016 (a.go:4)   MOVQ    $0, BP
        0x0012 00018 (a.go:4)   CMPQ    BX, BP
        0x0015 00021 (a.go:4)   JNE     37
        0x0017 00023 (a.go:5)   MOVQ    $0, "".~r0+16(FP)
        0x0020 00032 (a.go:5)   ADDQ    $8, SP
        0x0024 00036 (a.go:5)   RET
        0x0025 00037 (a.go:7)   MOVQ    $9, "".~r0+16(FP)
        0x002e 00046 (a.go:7)   ADDQ    $8, SP
        0x0032 00050 (a.go:7)   RET

Again &a == nil is always false, so a is unused (dead store) so the whole function's body can be replaced with return 9.

@brtzsnr, which compiler version is that?

I updated the comment.

SSA may help here.

These are all fixed on tip SSA.
(Except for the last example, where a is still initialized despite not being used.)

authors: bradfitz brtzsnr dvyukov randall77 rsc


text:
x/tools/gopls: GOPACKAGESDRIVER calls happen at intervals that make the results incorrect

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

$ go version
1.20.3

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="off"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOEXPERIMENT="nocoverageredesign,nounified"
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/go-code/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user/go-code"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/user/.cache/bazel/_bazel_jamy/b97476d719d716accead0f2d5b93104f/external/go_sdk_linux_amd64"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/user/.cache/bazel/_bazel_jamy/b97476d719d716accead0f2d5b93104f/external/go_sdk_linux_amd64/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.3 X:nounified,nocoverageredesign"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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 -fdebug-prefix-map=/tmp/go-build2135155060=/tmp/go-build -gno-record-gcc-switches"

What did you do?
With GOPACKAGESDRIVER enabled, adding an import (whether by inline writing code and accepting an import suggestion; or manually adding it to the imports section) will trigger a query to the packages driver. However, this trigger will happen prior to the file being saved, yet the packagesdriver will only get a filename to load packages for.
This triggers a bit of a race condition in build systems like Bazel:

Current imports in file.go are a, b, c
I add import d
GoPLS immediately tries to look up package info from the driver using the filename ($ pkgdrvr file=file.go)
Since the file isn't saved at this point in time, the packagesdriver will only see imports a, b, c and thus only return info for those 3
GoPLS gets incomplete results back and flags import d as bad.
Even after save, there is no re-trigger of the packagesdriver, which means this bad imports stays bad until after the imports are changed again; or the language server is restarted.

What did you expect to see?
Since the packagesdriver works with files on disk (in the general case) we should not query the packagesdriver until the IDE has committed the changes on disk.
Alternatively we can extend the packages driver call to query directly for the information of the imported package, rather than indirectly querying for the file the import is added to.
What did you see instead?
Package import resolution fails until language server restart.
I will try to get a project where we can repro this situation in.

Can you share which gopackagesdriver you are using.
The default gopackage driver go list handles this case by using overlay.
https://pkg.go.dev/golang.org/x/tools/go/packages#Config
Is it possible to make your gopackagesdriver recognize the overlay info?
@golang/tools-team I think we need documentation on gopackagesdriver https://github.com/golang/go/issues/34341

We use the rules_go one. Is the overlay JSON sent as the stdin when calling the driver?

We discussed this a bit more in our team meeting, and decided it would probably be very difficult to support this in the bazel driver (based on our understanding of bazel).
So we'll leave this open: it would be nice to fix, but unlikely to get prioritized any time soon. The work to implement this would be approximately:

accumulate invalidations in cache.snapshot.clone while the user types.
only invalidate and reload packages when the user saves all files

...but this will be very tricky to implement, and even after implemented may have to a subtly confusing UX.

@findleyr  Hello, What is the status of this support programme?
We had a similar problem when we implemented a packagedriver ourselves and he would dynamically generate code to return package information. but because of caching issues, there is no way to get the latest generated code. Is there a recommended solution? Apart from rebooting

@li-jin-gou I think this issue may have been superseded by #68002. I plan to implement #68002 this year. It is currently targetting the v0.17.0 release, which is tentatively planned for October.

@findleyr Hello, What is the status of this support programme? We had a similar problem when we implemented a packagedriver ourselves and he would dynamically generate code to return package information. but because of caching issues, there is no way to get the latest generated code. Is there a recommended solution? Apart from rebooting

I have a similar problem to him. After my local dependencies using gopackagesdriver are changed, I hope gopls can get the latest data in time. Is there any gopls command that can achieve this? Or is there any other better way?

Thanks, until then we can move forward with the programme of trying to restart gopls.  @findleyr

FWIW at Uber we did 2 things to fix this:

Support overlays on our internal driver. The overlay content contains the newly added import which fixes the initial issue (assuming you have some way of resolving said import without your dependency manager).
Added a "reload Imports" codelens above the imports section. Clicking this invalidates the target in our cache, and then slightly modifies the imports (adds a space at the front of the first import and removes it right after). The imports modification triggers gopls to request the imports from the packages driver.
@li-jin-gou @ViolaPioggia

FWIW at Uber we did 2 things to fix this:

Support overlays on our internal driver. The overlay content contains the newly added import which fixes the initial issue (assuming you have some way of resolving said import without your dependency manager).
Added a "reload Imports" codelens above the imports section. Clicking this invalidates the target in our cache, and then slightly modifies the imports (adds a space at the front of the first import and removes it right after). The imports modification triggers gopls to request the imports from the packages driver.

thanks

FWIW at Uber we did 2 things to fix this:

Support overlays on our internal driver. The overlay content contains the newly added import which fixes the initial issue (assuming you have some way of resolving said import without your dependency manager).
Added a "reload Imports" codelens above the imports section. Clicking this invalidates the target in our cache, and then slightly modifies the imports (adds a space at the front of the first import and removes it right after). The imports modification triggers gopls to request the imports from the packages driver.
@li-jin-gou @ViolaPioggia

sorry sir. In our case, the content of *packages.DriverResponse is unchanged, but the content of the file it maps to has changed.
So the IDE is not aware of the fact that the prompts are no longer correct due to a change in the file
  {
    "ID": "service1/hello",
    "Name": "hello",
    "PkgPath": "rgo/service1/kitex_gen/hello",
    "GoFiles": [
      "/root/cache/service1/hello/hello.go"
    ],
    "CompiledGoFiles": [
      "/root/cache/service1/hello/hello.go"
    ],
    "Imports": {
      "context": "context",
      "fmt": "fmt"
    }
  },

In fact it really doesn't describe whether or not the specifics of the file change. Have you ever had this problem? @JamyDev

Dependencies may have been added or the original dependency code may have changed.

I'm able to reproduce this. We use Bazel as our build system and this has been one of the more annoying bits. I've recorded what this looks like, and how you can get around it by deleting another import, saving, and then putting it back. That triggers packages.Load to be called again on the file with the updated metadata.
Video is too big to upload to GitHub: https://share.cleanshot.com/YSjRRv3D

I delved into this, and made some minor adjustments to gopls in order to have it reload the "state of the world" whenever a Bazel-related file was being touched. It's quite brute-force & dumb, but it seemingly works for us: https://github.com/devzero-inc/tools

authors: JamyDev Skyenought ViolaPioggia ellie-idb findleyr hyangah li-jin-gou


text:
Error loading workspace

Error loading workspace: You are outside of a module and outside of $GOPATH/src. If you are using modules, please open your editor to a directory in your module.
this warning appear when i reopen my folder. it has no problem before

please follow the bug report template

authors: DanielVostra seankhliao


text:
reflect: pass safe to packEface so we don't need to copy if safe==true is TODO

https://github.com/golang/go/pull/63446 Try to complete the above TODO.
But see https://github.com/golang/go/pull/63446/files#diff-fb7a84f457b2d4466b5d32940ffc6095d12b649f88bd3e5e762a87631e7a917aR1527 ,The first thing  is that safe==true for Value.Interface cannot be passed because it results in an error.
Then, I try to pass safe for deepValueEqual to try to complete TODO, but the benchmark shows that the number of memory allocations is always 0.
I see that this TODO ends with a question mark, maybe this TODO should be deleted directly, create an issue to investigate whether this TODO should be deleted.

cc @golang/runtime

@qiulaidongfeng In general you don't have to file an issue about resolving a TODO, especially if it's not fixing a known bug. (If it is, then feel free to file an issue for that bug.) AFAICT this isn't the case here, though please correct me if I'm wrong. You can just send a CL and the discussion can happen there. Thanks.

authors: cagedmantis mknyszek qiulaidongfeng


text:
runtime: "traceback: unexpected SPWRITE function runtime.systemstack"

https://go.dev/cl/525835 (backported to 1.21.2) introduced a regression causing a throw when panicking on the system stack:
traceback: unexpected SPWRITE function runtime.systemstack
runtime.systemstack(0x501fcc0)
    /Users/cherryyz/src/go/src/runtime/asm_amd64.s:509 +0x4a fp=0x7ff7bbfac760 sp=0x7ff7bbfac750 pc=0x4fa738a

This was fixed in https://go.dev/cl/531815 at tip, but needs a backport to 1.21.

@gopherbot please backport to 1.21. This fixes a regression in a previous backport (#62464).


text:
spec: document range-over-func

Tracking bug for adding range-over-func to spec. See #61405.

@griesemer this example is not great
// print hello world
f := func(yield func(string) bool) {
	if yield("hello") {
		yield("world")
	}
}
for word := range f {
	println(word)
}

its not clear when yield would return true or false, looking at the example alone

@3052 Agreed. And there's a TODO (html comment) in the spec to fix it. One step at a time.

one of the reasons I love Go is that it is very "readable", but the above example is not that at all. I will be patient and wait on updates to the example, but I have strong concerns about the impact of this new change on how easy it is to read Go code.

@griesemer https://github.com/golang/go/issues/65237#issuecomment-2147899109

there's a TODO (html comment) in the spec to fix it

Is there an opened issue about it ?

Change is in the works.

authors: 3052 Malix-off griesemer rsc


text:
database/sql: permit tagged struct in Scanner

Hi all,
First of all, thank you for Go. Its Awesome!
I like the idea how encoding/json Marshals and Unmarshals json objects into structs..
One could define the database model like so:
type UserModel struct {
    Id int `db:"id"`
    Name string `db:"user_name"`
}

And when scanning rows from the database:
for rows.Next() {
    user := UserModel{}
    if err := rows.Scan(&user); err != nil {
        panic(err)
    }
}

What are your thoughts?

3rd-party packages to make nicer scanners seem like the best route here. I don't see a compelling reason to try to standardize this in database/sql itself, and worse I don't see one obvious design. There are many possibilities. Let people use what works for them instead of forcing one.

I'm thinking, time.Time should have simple scanner. Because when driver can't recognize type of the field value, driver must return string or []byte.

authors: matejkramny mattn rsc


text:
net: tests doesn't pass on IPv6 only machines

I am trying to build go on IPv6 only machine and seeing following error:
--- FAIL: TestDialTimeout (0.01s)
dial_test.go:108: got error "dial tcp 127.0.0.1:61521: connection reset by peer"; not a timeout
--- FAIL: TestIPv4MulticastListener (0.00s)
multicast_test.go:55: First ListenMulticastUDP on  failed: listen udp 224.0.0.254: setsockopt: no such device
FAIL
FAIL    net     2.086s
Test should check if IPv4/IPv6 addresses assigned on the machine before starting test.

This is a duplicate of #5707.

authors: azhavnerchik mikioh


text:
net/http/httputil: improve compatibility with server sent events

According to https://html.spec.whatwg.org/multipage/server-sent-events.html#sse-processing-model
MIME type parameters should be ignored when Content-Typeheader value istext/event-stream`.
Related https://github.com/spring-projects/spring-framework/pull/24632

Gerrit isn't letting me comment on https://golang.org/cl/223118. ("Error 409: Change 223118 may not exceed 5000 updates.") I'm not sure why the change has 5000 updates on it, but I'm going to force abandon it since it's broken.
This change should use mime.ParseMediaType to parse the Content-Type header, rather than a prefix match.
I've created https://golang.org/cl/340529 with that change. If you'd like to make the change yourself, please feel free to create a new CL and send it to me for review and I'll abandon 340529.

source: gharchive/pull-request

authors: neild sadag


text:
use native bytes to/from int function where available

For significant speed gains where available.

A little bit of both.  The use case is real time RTP (webrtc client)

WebRTC in pure python? Wow... Can it handle VP8? Or just audio?
I did a custom client in C a while back, and can remember ICE was a challenge to get right across browsers. Good luck!

It's more of an experiment to research the protocol(s) and design of webrtc. With a vague goal of a gateway to ip-cameras in the end. So I won't be handling the media compression (Hopefully Google will come around and implement h264 :)).

That sounds interesting, is it published somewhere?

So I won't be handling the media compression (Hopefully Google will
come around and implement h264 :)).
Looks like they're working on it :)

That sounds interesting, is it published somewhere?

I hope it will be. Right now it's just a pile of vague ideas and experiments.

authors: goncalopp ttyridal

license: mit

license_source: bigquery