profile
viewpoint
Dmitri Shuralyov dmitshur Google, Go team NYC https://dmitri.shuralyov.com I pursue insight, then make things simpler and better. I enjoy writing correct, high-quality Go code. Minimalist.

avelino/awesome-go 58636

A curated list of awesome Go frameworks, libraries and software

gopherjs/gopherjs 9705

A compiler from Go to JavaScript for running Go code in a browser

google/go-github 6904

Go library for accessing the GitHub API

glfw/glfw 6843

A multi-platform library for OpenGL, OpenGL ES, Vulkan, window and input

dustin/go-humanize 2392

Go Humans! (formatters for units to human friendly sizes)

golang/tour 1212

[mirror] A Tour of Go

google/crfs 1017

CRFS: Container Registry Filesystem

go-interpreter/wagon 872

wagon, a WebAssembly-based Go interpreter, for Go.

gregjones/httpcache 549

A Transport for http.Client that will cache responses according to the HTTP RFC

mdempsky/unconvert 302

Remove unnecessary type conversions from Go source

issue commentgolang/go

cmd/go: go build fails with permission error inside a temporary directory on Windows

CC @jayconrod, @matloob, @bcmills.

zhaoyunxing92

comment created time in 4 hours

issue commentgolang/go

net/http: can't handle Onion domains

CC @odeke-em, @bradfitz, @empijei.

danger89

comment created time in 4 hours

issue commentgolang/go

Nil-ness of a pointer is lost when converted to an interface

This is unfortunate but old behavior and working as intended. Please see https://golang.org/doc/faq#nil_error.

If you search the issue tracker for that URL, you'll find many instances of past discussion. Also see #22729 for an open proposal for improving this.

adalton

comment created time in 4 hours

issue closedgolang/go

Nil-ness of a pointer is lost when converted to an interface

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

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

<pre> $ go version go version go1.15.3 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/username/.cache/go-build" GOENV="/home/username/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/username/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/username/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/lib/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="x86_64-pc-linux-gnu-gcc" CXX="x86_64-pc-linux-gnu-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-build221298389=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. --> I have a structure that implements the error interface, and an API whose return type is a pointer to that structure type. The API returns nil on success or a pointer to an instance of that structure on failure. I have caller of that API returns error, and returns the value received from the previously described API.

When the caller of the second function examines the error that it returns, the err != nil check always evaluates to true, even when the value is nil.

This example program illustrates the problem

package main

import (
    "fmt"
    "os"
)

type MyError struct {
    msg string
}
func (e *MyError) Error() string {
    return e.msg
}

func baz() *MyError {
    if len(os.Args) > 1 {
        return nil
    } else {
        return &MyError{msg: "badness"}
    }
}

func bar() error {
    return baz()
}

func foo() (string, error) {
    if err := bar(); err != nil {
        return "", err
    }

    return "hello", nil
}

func main() {
    if value, err := foo(); err != nil {
        fmt.Printf("error: %s\n", err.Error())
    } else {
        fmt.Printf("value: %s\n", value)
    }
}

What did you expect to see?

The sample program above uses the number of command line arguments to control its behavior. If there are no arguments, then baz() returns a pointer to a MyError structure; if there are arguments, then baz() returns nil.

I expect that when the program is run with no arguments, I see the error handled:

$ go run example.go
error: badness

I also expect that when the program is run with arguments, I should see the "no-error" path execute:

$ go run example.go xxx
value: hello

What did you see instead?

When I run the program with arguments --- the case where baz() returns nil --- the err != nil check in main() evaluates to true even though the err is nil, and a call to err.Error() results in e.msg triggering a nil pointer dereference panic:

$ go run example.go xxx
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x49a845]

goroutine 1 [running]:
main.(*MyError).Error(0x0, 0xc0000561d0, 0xc000074f48)
	/tmp/bar.go:12 +0x5
main.main()
	/tmp/bar.go:37 +0x58
exit status 2

I note that in this example, changing the return type of baz() from *MyError to error results in the expected behavior.

closed time in 4 hours

adalton

issue commentgolang/go

x/crypto/acme: CreateOrderCert returning Order's status ('valid') is not acceptable for finalization

CC @rolandshoemaker, @x1ddos, @FiloSottile per owners.

jameshartig

comment created time in 4 hours

issue commentgolang/go

runtime: panic on plan9_arm builders

This may be the same as or related to #42237.

millerresearch

comment created time in 4 hours

issue commentgolang/go

x/build/env/linux-arm64/packet: 8 Packet linux/arm64 machines missing (late-October 2020)

@cagedmantis That sounds great! Want to open an issue and send a CL to make us use that builder starting with Go 1.16 Beta 1? See #40563 and CL 246597 for precedent.

dmitshur

comment created time in 5 hours

issue closedgolang/go

x/build/env/linux-arm64/packet: 8 Packet linux/arm64 machines missing (late-October 2020)

https://farmer.golang.org/#health reports:

image

<details><br>

# "packet" status: Packet linux/arm64 machines
# Notes: https://github.com/golang/build/tree/master/env/linux-arm64/packet
Warn: packet01 missing, not seen for 1h14m46s
Warn: packet02 missing, not seen for 1h14m38s
Warn: packet03 missing, not seen for 1h14m37s
Warn: packet04 missing, not seen for 1h14m38s
Warn: packet05 missing, not seen for 1h14m42s
Warn: packet06 missing, not seen for 1h14m33s
Warn: packet07 missing, not seen for 1h14m43s
Warn: packet08 missing, not seen for 1h14m39s
Error: 8 machines missing, 100% of capacity

</details>

This has happened previously (where a restart was required to fix the issue):

  • #40261 (last occurrence, 106 days ago)
  • #37922
  • #37371
  • #35708
  • #35524
  • #32543
  • #31112
  • etc.

This builder is needed for making releases. Applying Soon label.

CC @golang/release.

closed time in 5 hours

dmitshur

issue commentgolang/go

x/build/env/linux-arm64/packet: 8 Packet linux/arm64 machines missing (late-October 2020)

The machine became unresponsive. As in previous occurrences, restarting via Packet UI fixed it.

dmitshur

comment created time in 5 hours

issue openedgolang/go

x/build/env/linux-arm64/packet: 8 Packet linux/arm64 machines missing (late-October 2020)

https://farmer.golang.org/#health reports:

image

<details><br>

# "packet" status: Packet linux/arm64 machines
# Notes: https://github.com/golang/build/tree/master/env/linux-arm64/packet
Warn: packet01 missing, not seen for 1h14m46s
Warn: packet02 missing, not seen for 1h14m38s
Warn: packet03 missing, not seen for 1h14m37s
Warn: packet04 missing, not seen for 1h14m38s
Warn: packet05 missing, not seen for 1h14m42s
Warn: packet06 missing, not seen for 1h14m33s
Warn: packet07 missing, not seen for 1h14m43s
Warn: packet08 missing, not seen for 1h14m39s
Error: 8 machines missing, 100% of capacity

</details>

This has happened previously (where a restart was required to fix the issue):

  • #40261 (last occurrence, 106 days ago)
  • #37922
  • #37371
  • #35708
  • #35524
  • #32543
  • #31112
  • etc.

This builder is needed for making releases. Applying Soon label.

CC @golang/release.

created time in 5 hours

issue commentgolang/go

x/blog, x/tour, x/talks: {blog,tour,talks}.golang.org are missing redirect from HTTP to HTTPS

I've checked and this applies to {blog,talks}.golang.org as well.

All 3 are hosted on App Engine. This is a matter of configuring their respective app.yaml to set "secure: true" for all paths. I'll send CLs for this.

CC @golang/release, @golang/security.

The-Compiler

comment created time in 6 hours

issue commentgolang/go

x/build: frequent timeouts running js-wasm TryBots

Is something preventing these buildlets from spawning?

It seems so. I don't have an idea about what it might be yet. It may be related to #42285. I'm going to look more later today.

bcmills

comment created time in 8 hours

issue closedgolang/go

x/net/http2: the first write error on a connection will cause all subsequent write requests to fail blindly [1.14 backport]

@bradfitz requested issue #39337 to be considered for backport to the next 1.14 minor release.

@gopherbot, please backport. I think this is pretty bad. (It bit us and there's no great workaround, short of disabling HTTP/2)

closed time in 9 hours

gopherbot

issue commentgolang/go

x/net/http2: the first write error on a connection will cause all subsequent write requests to fail blindly [1.14 backport]

Closed by merging 162b65e05cec843b1a6bee493362f2a3046dba7b to release-branch.go1.14.

gopherbot

comment created time in 9 hours

issue closedgolang/go

x/net/http2: the first write error on a connection will cause all subsequent write requests to fail blindly [1.15 backport]

@bradfitz requested issue #39337 to be considered for backport to the next 1.15 minor release.

@gopherbot, please backport. I think this is pretty bad. (It bit us and there's no great workaround, short of disabling HTTP/2)

closed time in 10 hours

gopherbot

issue commentgolang/go

x/net/http2: the first write error on a connection will cause all subsequent write requests to fail blindly [1.15 backport]

Closed by merging ef3039e99d3413735d863d84347561003d63340e to release-branch.go1.15.

gopherbot

comment created time in 10 hours

issue commentgolang/go

cmd/dist: show which GOOS/GOARCH combinations are first class ports

If we add it there right away, it'll be hard to change it.

I meant the API. If we add a field to cmd/go now, we can't easily change or remove it in the future. So it needs more thought before we commit to it.

I'm going to set the milestone to Go 1.17, we can revisit this issue then. I don't think this is important for Go 1.16.

mvdan

comment created time in 10 hours

issue commentgolang/go

cmd/dist: show which GOOS/GOARCH combinations are first class ports

I'm really not sure that cmd/go is the right place to put this information. If we add it there right away, it'll be hard to change it.

I'm okay with placing this information in x/build (which is v0 and can be modified anytime without time pressure of the freeze) though so it can be accessed programmatically, and not have to download many historic cmd/go binaries to get info about older releases. I suggest we start there, and consider promoting to cmd/go later on if we're happy with the experience in x/build and still think there's a need to also make it available from cmd/go.

For x/build, the API can perhaps be, inspired by golang.org/x/website/internal/history and golang.org/x/build/cmd/release, something like:

map[string][]string{
	">= go1.15": {
		"linux/amd64",
		"linux/386",
		"linux/arm",
		"linux/arm64",
		"darwin/amd64",
		"windows/amd64",
		"windows/386",
	},

	"< go1.15": {
		"linux/amd64",
		"linux/386",
		"linux/arm",
		"darwin/amd64",
		"windows/amd64",
		"windows/386",
	},

	// ...
}
mvdan

comment created time in 11 hours

issue commentgolang/go

cmd/compile, x/sync/errgroup: TestWithContext failing after devirtualization CL

Thanks. I can reproduce locally:

<details><br>

$ gotip version
go version devel +f7e26467b Fri Oct 30 01:31:10 2020 +0000 darwin/amd64
$ gotip test golang.org/x/sync/errgroup
--- FAIL: TestWithContext (0.00s)
panic: interface conversion: context.Context is *context.cancelCtx, not *context.emptyCtx [recovered]
	panic: interface conversion: context.Context is *context.cancelCtx, not *context.emptyCtx

goroutine 27 [running]:
testing.tRunner.func1.2(0x11eab60, 0xc000116e70)
	/Users/dmitshur/sdk/gotip/src/testing/testing.go:1123 +0x332
testing.tRunner.func1(0xc000106c00)
	/Users/dmitshur/sdk/gotip/src/testing/testing.go:1126 +0x4b6
panic(0x11eab60, 0xc000116e70)
	/Users/dmitshur/sdk/gotip/src/runtime/panic.go:965 +0x1b9
golang.org/x/sync/errgroup_test.TestWithContext(0xc000106c00)
	/Users/dmitshur/go/src/golang.org/x/sync/errgroup/errgroup_test.go:166 +0x652
testing.tRunner(0xc000106c00, 0x1233ba0)
	/Users/dmitshur/sdk/gotip/src/testing/testing.go:1173 +0xef
created by testing.(*T).Run
	/Users/dmitshur/sdk/gotip/src/testing/testing.go:1218 +0x2b3
FAIL	golang.org/x/sync/errgroup	0.121s
FAIL

</details>

zikaeroh

comment created time in a day

issue commentgolang/go

cmd/compile, x/sync/errgroup: TestWithContext failing after devirtualization CL

Now that #42279 is resolved, is this still an issue? I'm not sure I understand how this issue is different.

zikaeroh

comment created time in a day

issue commentgolang/go

cmd/compile: internal compiler error: devirtualization failed (x/text, x/build, protobuf)

Two more data points from x/build:

<details><br>

# golang.org/x/build/cmd/coordinator [golang.org/x/build/cmd/coordinator.test]
cmd/coordinator/builders.go:43:5: internal compiler error: devirtualization failed: tlsLn.(*tls.listener).Listener.Addr

goroutine 1 [running]:
runtime/debug.Stack(0x19adbc0, 0xc0000ba008, 0x0)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/runtime/debug/stack.go:24 +0x9f
cmd/compile/internal/gc.Fatalf(0x18a1cc4, 0x1b, 0xc0008f3618, 0x1, 0x1)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/subr.go:199 +0x1b0
cmd/compile/internal/gc.devirtualizeCall(0xc000077d80)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/inl.go:1454 +0x2ab
cmd/compile/internal/gc.devirtualize.func1(0xc000077d80, 0x0)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/inl.go:1428 +0x45
cmd/compile/internal/gc.inspect(0xc000077d80, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1072 +0x43
cmd/compile/internal/gc.inspect(0xc0014b9800, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1076 +0x85
cmd/compile/internal/gc.inspectList(0xc0000afda0, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1085 +0x58
cmd/compile/internal/gc.inspect(0xc000077c00, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1078 +0xc5
cmd/compile/internal/gc.inspectList(0xc0000afe30, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1085 +0x58
cmd/compile/internal/gc.devirtualize(0xc0001242c0)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/inl.go:1426 +0x4b
cmd/compile/internal/gc.Main(0x18b95d0)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/main.go:706 +0x324b
main.main()
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/main.go:52 +0xb1
# golang.org/x/build/devapp [golang.org/x/build/devapp.test]
devapp/data.go:12:2: internal compiler error: devirtualization failed: tlsLn.(*tls.listener).Listener.Addr

goroutine 1 [running]:
runtime/debug.Stack(0x19adbc0, 0xc0000c0008, 0x0)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/runtime/debug/stack.go:24 +0x9f
cmd/compile/internal/gc.Fatalf(0x18a1cc4, 0x1b, 0xc000a29618, 0x1, 0x1)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/subr.go:199 +0x1b0
cmd/compile/internal/gc.devirtualizeCall(0xc000399180)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/inl.go:1454 +0x2ab
cmd/compile/internal/gc.devirtualize.func1(0xc000399180, 0x0)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/inl.go:1428 +0x45
cmd/compile/internal/gc.inspect(0xc000399180, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1072 +0x43
cmd/compile/internal/gc.inspect(0xc000efcf00, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1076 +0x85
cmd/compile/internal/gc.inspectList(0xc00000ced0, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1085 +0x58
cmd/compile/internal/gc.inspect(0xc000399000, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1078 +0xc5
cmd/compile/internal/gc.inspectList(0xc00000cf18, 0x18b9740)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/syntax.go:1085 +0x58
cmd/compile/internal/gc.devirtualize(0xc00042d4a0)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/inl.go:1426 +0x4b
cmd/compile/internal/gc.Main(0x18b95d0)
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/internal/gc/main.go:706 +0x324b
main.main()
	/private/var/folders/kh/5zzynz152r94t18yzstnrwx80000gn/T/workdir-host-darwin-10_15/go/src/cmd/compile/main.go:52 +0xb1

</details>

From https://build.golang.org/?repo=golang.org%2fx%2fbuild for Go commit 5cc43c5. (Other Go commits look okay.)

zikaeroh

comment created time in a day

issue openedgolang/go

x/build/cmd/coordinator: excessively large number of pending builds

Opening https://farmer.golang.org/ in a browser takes a few seconds to load it at this time. This is largely because there are 16059 entries under the "Pending builds" section. The scrollbar is tiny:

image

I'm not sure if I've seen this many before. This may or may not be a problem.

CC @golang/release.

created time in a day

issue commentgolang/go

x/build/cmd/gitmirror: 10 minute timeout on git fetch is incorrectly implemented, so git fetch may still block forever

Again, today:

image

That's 5 months 17 days since last reported occurrence.

Fixed using same procedure as in https://github.com/golang/go/issues/38887#issuecomment-627571674.

CC @golang/release.

dmitshur

comment created time in a day

issue commentgolang/go

x/build: frequent timeouts running js-wasm TryBots

From CL 266374 where I recently started trybots:

image

In this instance, the js-wasm builder is in waiting_for_machine state for over 10 minutes. That is very unexpected—it's a GCP builder that we should be able to spin up without running out of physical machines. Perhaps we're running out of some quota. Not sure why only js-wasm and not other GCP builders. But this is a lead.

bcmills

comment created time in a day

issue commentgolang/go

x/build: frequent timeouts running js-wasm TryBots

Any advice about what to do when js-wasm looks like it is stuck/very slow and how to debug further would be greatly appreciated.

I suggest trying to determine if there is a specific place where the build progresses more slowly than others. I.e., is it perhaps that time to first test is delayed, then it's fast, or is one of the package tests very slow, while the rest is fast, or is slowness equally distributed across all packages?

I'll also try to look into logs for the two occurrences you've shared and see if I can determine it from that.

bcmills

comment created time in a day

IssuesEvent
IssuesEvent

issue commentgolang/go

x/net/http2: the first write error on a connection will cause all subsequent write requests to fail blindly [1.14 backport]

Reopening for updating bundled copy in the standard library.

gopherbot

comment created time in a day

issue commentgolang/go

x/build: gopherbot closing backport issue prematurely

When I reopened the issue, gopherbot closed it again.

This is a separate known gopherbot issue tracked by #21312. It is caused by a limitation of maintner tracked by #28226.

ianlancetaylor

comment created time in a day

IssuesEvent

issue commentgolang/go

x/build/cmd/gopherbot: when closing backport issues, ignores "Fixes" vs "For"/"Updates" verb before issue mention

See #42277 for another occurrence.

CC @golang/release, @ianlancetaylor.

katiehockman

comment created time in a day

issue closedgolang/go

x/build: gopherbot closing backport issue prematurely

For some reason gopherbot decided to close issue #42138 prematurely. It is a backport issue to 1.15. I submitted part of the fix in https://golang.org/cl/264301. That CL says "For #42138", not "Fixes". But gopherbot closed the issue anyhow: https://github.com/golang/go/issues/42138#issuecomment-718958745. When I reopened the issue, gopherbot closed it again.

CC @dmitshur @cagedmantis @toothrot

closed time in a day

ianlancetaylor

issue commentgolang/go

x/build: gopherbot closing backport issue prematurely

This is is a known gopherbot issue tracked by #29599, which unfortunately no one had the bandwidth to fix yet. Closing as duplicate.

ianlancetaylor

comment created time in a day

issue commentgolang/go

time: Location interprets wrong timezone (DST) with slim zoneinfo [1.14 backport]

Approving per discussion in a release meeting. This is a serious issue without a workaround. This backport applies to both 1.15 (#42138) and 1.14 (this issue).

gopherbot

comment created time in a day

issue commentgolang/go

time: Location interprets wrong timezone (DST) with slim zoneinfo [1.15 backport]

Approving per discussion in a release meeting. This is a serious issue without a workaround. This backport applies to both 1.15 (this issue) and 1.14 (#42155).

hlubek

comment created time in a day

issue commentgolang/go

x/build: SlowBot requests are sometimes not recognized (seemingly when re-requested on same patch set)

Some experimenting in CL 266202 suggests there's a good chance there is a problem with determining the "latest" TRY= request on the same patch set. So an (unpleasant) workaround until this issue is resolved is to make a new patch set when needing to make a different request.

bcmills

comment created time in a day

issue commentgolang/go

x/build: improve trybot aliases for ppc64

This appears to be issues #42084 and #38235. Please add a comment there so we have more data points.

laboger

comment created time in a day

issue commentgolang/go

x/build: frequent timeouts running js-wasm TryBots

I feel like I've seen some discussion about this still happening occasionally quite recently, more so than the comments in this issue would suggest. Perhaps it was in another thread. I'll keep an eye out on this.

bcmills

comment created time in 2 days

issue commentgolang/go

runtime,time: test timeouts / deadlocks after CL 232298

Given that it's happening significantly on OpenBSD 6.2 and not at all on OpenBSD 6.4, it may be a problem with the old OpenBSD version or the amount of resources it has.

An important difference between those two builders, beyond the OpenBSD version, is that the 6.4 builder was configured to significantly improve performance at the cost of disabling Spectre/Meltdown mitigations (see https://github.com/golang/build/commit/31ed75f74635bc739ba5a817b37317579192d506 and https://github.com/golang/build/commit/d3ddf67ac5c858c99152a37bce5bcf8bce820d06).

CC @golang/release.

bcmills

comment created time in 2 days

issue commentgolang/go

net/http/httputil: ReverseProxy forcibly cleans double forward slash in URLs

This is either necessary and correct per HTTP spec, or a bug/missing feature. This issue needs investigation to determine which.

CC @bradfitz, @empijei.

iiiusky

comment created time in 2 days

issue commentgolang/go

x/crypto/bcrypt: GenerateFromPassword returns nil error on empty password

As I understand, there are no restrictions on the password input to GenerateFromPassword, so a password of length 0 is considered valid input and this is working as intended. But maybe something else should be done.

CC @FiloSottile, @katiehockman, @rolandshoemaker.

ivanjaros

comment created time in 2 days

issue commentgolang/go

build: cgo with clang failures for windows

What version of clang is it?

In go env output it says CC=gcc—is that because you ran go env before setting those env vars as shown in "what did you do" section?

CC @ianlancetaylor, @alexbrainman.

tungmangtdh3

comment created time in 2 days

issue commentshurcooL/markdownfmt

renderer: Fenced Code Block info string should not trim to first word only.

That sounds like a bug, fixing which is in scope. I have little bandwidth to do code review or fix bugs in this project, so it's hard to promise anything.

In general, I'd recommend picking a more active fork to contribute to instead. This issue may even get fixed if using blackfriday v2 (#39) or goldmark (#56).

leave the info string unchanged

It should still trim the whitespace at the both ends.

bwplotka

comment created time in 3 days

issue commentrussross/blackfriday

v2: decide on import path and make a new release

Moving on to step 2, I've published a pre-release version v2.1.0-pre.1 at the tip of v2 branch:

$ go list -m -versions github.com/russross/blackfriday/v2
github.com/russross/blackfriday/v2 v2.0.0 v2.0.1 v2.1.0-pre.1

If you're following this issue and are able to, please test v2.1.0-pre.1 and comment (or report an issue) if you find a serious problem, before we promote the pre-release version to a final v2.1.0 release. You should be able to install it in your project with:

$ go get github.com/russross/blackfriday/v2@v2.1.0-pre.1

Thanks.

kolyshkin

comment created time in 3 days

created tagrussross/blackfriday

tagv2.1.0-pre.1

Blackfriday: a markdown processor for Go

created time in 3 days

issue commentgolang/go

Removed from pkg.go.dev: github.com/sid-agrawal/samplebankapi from

Hi @sid-agrawal, can you please confirm if this is a request to remove the github.com/sid-agrawal/samplebankapi module from https://pkg.go.dev?

CC @jamalc.

sid-agrawal

comment created time in 3 days

issue commentgolang/go

x/all: document release branches

Discussed this in a release meeting, moving to NeedsFix and taking. If there are newly found concerns or suggestions, we can still adjust the plan before Go 1.16 RC 1, when release branches in golang.org/x repos will be cut.

rittneje

comment created time in 3 days

issue closedshurcooL/githubv4

Does graphql API have rest API V3 / users

Does graphql API have rest API V3 / users

https://developer.github.com/v3/users/

Lists all users, in the order that they signed up on GitHub. This list includes personal user accounts and organization accounts.

Note: Pagination is powered exclusively by the since parameter. Use the Link header to get the URL for the next page of users.

GraphQL API

closed time in 3 days

JeffreyBool

issue commentshurcooL/githubv4

Does graphql API have rest API V3 / users

This is an issue tracker for a Go package that provides access to the GitHub GraphQL API V4.

Threre are better places to seek information and ask questions about the GitHub API:

  • https://docs.github.com
  • https://github.community/c/github-api-development-and-support/37

I'll close this since it's out of scope for this issue tracker. Thanks.

JeffreyBool

comment created time in 3 days

issue commentgolang/go

x/build: builders appear to use their own custom devel version string format

After looking more into this, I left a comment on CL 264938 suggesting that it should not expect there to be any requirements met if there exists a VERSION file, since that file is allowed to have arbitrary content. It would be a problem not only on builders, but for users who have a custom VERSION file.

We may still want to change the custom VERSION file that builders write in the future, but I don't think we need to do anything now to unblock #41116 specifically.

mvdan

comment created time in 3 days

issue commentgolang/go

syscall/js: ValueOf should not panic if the underlying type(kind) is supported

@neelance Have you also considered internal/reflectlite?

mihaiav

comment created time in 3 days

delete branch russross/blackfriday

delete branch : issue-587-README-v2

delete time in 4 days

push eventrussross/blackfriday

Dmitri Shuralyov

commit sha 4c9bf9512682b995722660a4196c0013228e2049

v2/README: make a definitive decision on v2 import path This change makes it clear that the v2 import path is github.com/russross/blackfriday/v2, and updates various links accordingly. See https://github.com/russross/blackfriday/issues/587#issuecomment-703393820 for details. This change also converges the README for v1 and v2 to be consistent, as they've started to drift apart. For #587. GitHub-Pull-Request: #675

view details

push time in 4 days

PR merged russross/blackfriday

Reviewers
v2/README: make a definitive decision on v2 import path documentation v2

This change makes it clear that the v2 import path is github.com/russross/blackfriday/v2, and updates various links accordingly.

See https://github.com/russross/blackfriday/issues/587#issuecomment-703393820 for details.

This change also converges the README for v1 and v2 to be consistent, as they've started to drift apart. (See PR #674 for the equivalent change to the README on master branch.)

For #587.

+51 -26

0 comment

1 changed file

dmitshur

pr closed time in 4 days

delete branch russross/blackfriday

delete branch : issue-587-README-v1

delete time in 4 days

push eventrussross/blackfriday

Dmitri Shuralyov

commit sha e96880f42b9343aea6cbfd99693adae0e5fe2b2a

README: make a definitive decision on v2 import path This change makes it clear that the v2 import path is github.com/russross/blackfriday/v2, and updates various links accordingly. See https://github.com/russross/blackfriday/issues/587#issuecomment-703393820 for details. This change also converges the README for v1 and v2 to be consistent, as they've started to drift apart. (See PR #675 for the equivalent change to the README on v2 branch.) For #587. GitHub-Pull-Request: #674

view details

push time in 4 days

PR merged russross/blackfriday

Reviewers
README: make a definitive decision on v2 import path documentation v1

This change makes it clear that the v2 import path is github.com/russross/blackfriday/v2, and updates various links accordingly.

See https://github.com/russross/blackfriday/issues/587#issuecomment-703393820 for details.

This change also converges the README for v1 and v2 to be consistent, as they've started to drift apart. (See PR #675 for the equivalent change to the README on v2 branch.)

For #587.

+37 -46

0 comment

1 changed file

dmitshur

pr closed time in 4 days

issue commentgolang/go

x/build: builders appear to use their own custom devel version string format

This issue should be about determining what needs to be done on the builder side to support changes for #41116, if anything, and doing it. CC @golang/release.

There's more than one place in x/build that constructs a custom VERSION file, mostly related to debugging via gomote. I think those can be dealt with later.

The one that's relevant to testing commits is in buildgo.VersionTgz. It's used by cmd/coordinator in the buildStatus.writeGoSourceTo method, which has a lot of relevant information. From a relatively quick look, I don't see that the major Go version is computed there though.

mvdan

comment created time in 4 days

issue commentgolang/go

cmd/link: unable to initialize decompress status for section .debug_info after Go 1.15.3

running gcc failed

What is the GCC version that was used?

xiekeyi98

comment created time in 4 days

issue commentgolang/go

unable to initialize decompress status for section .debug_info @ go 1.15.3

CC @ianlancetaylor, @cherrymui.

xiekeyi98

comment created time in 4 days

issue commentgolang/go

cmd/go: consider including Go's own version in 'go env'

To clarify, my comment was trying to answer your question of "Do we agree to do both changes at once for 1.16?" from 4 days ago, since I saw this issue was still in NeedsDecision state and I didn't see an answer to that here. I hadn't been aware of discussion outside of this issue, thanks for letting me know. It seems this issue should be moved to NeedsFix.

mvdan

comment created time in 4 days

issue commentgolang/go

cmd/go: consider including Go's own version in 'go env'

That seems reasonable to me.

I think any development version string changes are better to leave to another cycle, since there's more discussion to be had. If there are concerns that it might become harder to change its format in the future, then for Go 1.16 you can consider making go env VERSION output be the empty string if it's not a release (or pre-release) version. That won't break anyone, since it's a new feature and no one can be relying on it yet.

mvdan

comment created time in 4 days

issue commentgolang/go

cmd/go: consider including Go's own version in 'go env'

I'm okay with not expanding scope for this issue. I think it will help to clarify what is in scope.

In https://github.com/golang/go/issues/41116#issuecomment-713773353, Russ said:

One should be enough, it should be GOVERSION, which should record the output of go version (with the 'go version' prefix and the goos/goarch suffix removed I assume).

That suggests a hypothetical future Go 1.19.3 version would print:

$ go version
go version go1.19.3 linux/arm64

$ go env GOVERSION
go1.19.3

And a hypothetical future non-released version would print:

$ go version
go version {development version string} darwin/amd64

$ go env GOVERSION
{development version string}

And if the go version output for non-released versions changes in the future (something that is out of scope for this issue, if I understand correctly), then go env VERSION will print the new thing. Is that the plan you're suggesting @mvdan?

mvdan

comment created time in 4 days

issue commentgolang/go

cmd/go: consider including Go's own version in 'go env'

I see, so it's in scope of this issue to expose the major Go version but not minor.

I think that's fine as long as it leaves the door open to be able to also expose the minor version in the future. Those who are interested in just the Go language version can ignore the minor if it is added in the future (although code that just takes the whole string until the first - will break).

I can't remember what use case I had for exposing the minor version. I think it was about being exposing precise version information for informational purposes. But let me see if there are other good reasons for it.

@mvdan Are you okay with leaving the door open for exposing the minor (i.e., Go x.y.Z) version too in the future?

mvdan

comment created time in 4 days

issue commentgolang/go

cmd/go: consider including Go's own version in 'go env'

This is something that's been on my mind too, but I hadn't seen this issue.

@mvdan I wanted to ask if it's in scope of this issue to make it work for minor versions on release branches too?

For example, if Go is built at commit 8f14c1840d15233b7f3d08f0acf0b0559d465a56 (tip of release-branch.go1.15 as of this posting), go version will currently report go1.15.3, which is not true. Based on the pattern above, it could report:

go version devel go1.15.4+8f14c1840d15 Tue Oct 20 16:43:37 2020 -0400 darwin/amd64

Making that work may require doing something different, because unlike the main branch, release branches have a VERSION file committed. That's something that can be controlled on the side of release tooling, but need to consider people building from source. I wanted to ask since it may influence the overall direction.

mvdan

comment created time in 4 days

startedsiongui/paligo

started time in 5 days

issue commentgopherjs/gopherjs

Possible to reduce the size of the bloated js bundle?

There will be an update posted on #894 soon, but this project is not actively developed at this time, so binary size isn't going to change.

More active development is happening on Go's WebAssembly support, so I recommend looking at that (also see issues golang/go#29478 and golang/go#6853). There may also be forks that will take a different approach.

hiqsociety

comment created time in 6 days

issue commentshurcooL/vfsgen

Symlink & File Permission Support?

I couldn't find any issues or docs about either symlinks or file permissions.

Is this explicitly not a goal of the project? Or just an oversight?

This is a good question, thanks for asking.

I've never run into a need for preserving custom file permissions (beyond the directory vs file distinction), and so I didn't implement it.

I also prefer to keep this project as simple and portable as possible. Symlinks and file permissions are not the most portable concepts: some OSes support them one way, others in another way, and some not at all. A virtual filesystem generated on one OS should be usable by a program running on another OS.

I suspect preserving file mode is doable, as it's just an uint32. But it's worth thinking about carefully if it should be done, and if there should be any restrictions on allowed values.

I'm less sure about what it would mean to support symlinks. Go's upcoming support for embedded files won't support it either.

coolaj86

comment created time in 6 days

issue commentgo-gl/glfw

make GLFW C revision a part of input to Go build cache

Oh, I see you were referring to editing C files for debugging specifically.

Given how rarely that happens, and it's done by package developers, I'm okay with them having to be mindful of the build cache for now.

Let's fix this problem for users of the package first (what this issue is about), then we can see if there's a reasonable way to also fix it for developers. I don't think we should do it if it complicates things too much.

dmitshur

comment created time in 6 days

issue commentgo-gl/glfw

make GLFW C revision a part of input to Go build cache

@dmitshur do you have any other ideas? Do we have to live with the behaviour as it is?

@pwaller My suggestion is:

We have a GLFW_C_REVISION.txt file that tracks the revision of the GLFW C library being used.

We can rename the GLFW_C_REVISION.txt file to something like glfwcrev.go and include the GLFW C revision as a comment:

package glfw

// GLFW_C_REVISION = 0a49ef0a00baa3ab520ddc452f0e3b1e099c5580

Then changing the GLFW C revision will cause one of the .go files to become different, and the old build cache will no longer get in the way.

Maybe it should be an unexported constant instead of a comment. Both are probably fine.

dmitshur

comment created time in 6 days

issue openedgolang/go

x/build: add builder to test ios/amd64 port

If it is possible to create a builder for the ios/amd64 target (iOS Simulator) with a reasonable amount of effort, we should create it. This is the tracking issue for any investigation and work that goes into this.

CC @golang/release, @cherrymui, @eliasnaur.

created time in 7 days

issue commentgolang/go

release: look for CLs with +2 but no Trust+1

https://go-review.googlesource.com/q/label:Code-Review%253D%252B2+label:Untrusted%253Dreject+repo:go+branch:master narrows it down to just the main repository, main branch. There are 58 matching open CLs.

ianlancetaylor

comment created time in 7 days

issue commentgolang/go

release: look for CLs with +2 but no Trust+1

@toothrot has previously suggested this Gerrit search query:

https://go-review.googlesource.com/q/label:Code-Review%253D%252B2+label:Untrusted%253Dreject

There are 3.5~ pages of results (at 25 CL/page) at this time.

ianlancetaylor

comment created time in 7 days

issue commentrussross/blackfriday

v2: decide on import path and make a new release

@russross @rtfb Any objections if I proceed with the plan described above soon?

kolyshkin

comment created time in 8 days

issue commentrussross/blackfriday

Very serious issue

@isurzhenko It's a pun that refers to Black Friday, an event that involves markdown.

isurzhenko

comment created time in 8 days

issue commentgolang/go

sync: Once documentation doesn't say whether it's okay to copy

By chance (several days later after I had the original question), I spotted that the package comment contains the following relevant statement:

Values containing the types defined in this package should not be copied.

It seems all concrete types in the package (Cond, Map, Mutex, Pool, RWMutex, and WaitGroup) have a "must not be copied after first use." statement, and Once is the odd one out without it.

So I believe the fix is to add the same statement to the documentation of Once.

dmitshur

comment created time in 8 days

issue openedgolang/go

sync: Once documentation doesn't say whether it's okay to copy

What did you do?

I read the documentation for sync.Once to understand how it can be used.

What did you expect to see?

Documentation that answers whether it's okay to copy sync.Once, so that it's not necessary to read its internal code or experiment to find out the answer.

For example, the documentation for sync.Mutex is very clear about this:

A Mutex must not be copied after first use.

What did you see instead?

Documentation that explained how sync.Once operates but didn't answer the copying question.

From experimenting and reading the code, I found out that it's not okay because sync.Once contains sync.Mutex, which cannot be copied. vet catches and reports misuse:

prog.go:10: assignment copies lock value to b: sync.Once contains sync.Mutex

created time in 8 days

issue commentshurcooL/vfsgen

importPathToDir used by repos using this doesn't work in module mode

@segevfiner In module mode, build.Import can only be used to find Go packages, meaning the directory needs to contain at least one .go file. In your snippet:

var Assets http.FileSystem = http.Dir(importPathToDir("github.com/segevfiner/vfsgen-test2/assets/assets"))

That corresponds to a directory with hello.txt and nothing else. You'll want to change it to something like:

// Assets contains project assets.
var Assets http.FileSystem = http.Dir(filepath.Join(importPathToDir("github.com/segevfiner/vfsgen-test2/assets"), "assets"))

That seems to fix things.

You may also want to provide an absolute directory rather than empty string as the srcDir parameter to build.Import:

+wd, err := os.Getwd()
+if err != nil {
+	log.Fatalln(err)
+}
-p, err := build.Import(importPath, "", build.FindOnly)
+p, err := build.Import(importPath, wd, build.FindOnly)

Overall, I suspect it's not worth using build.Import in module mode anymore. It may be better to find the directory corresponding to the root of the module, and go from there. See https://github.com/golang/dl/commit/1b9ab2716afa62aa4383b03b9561f73ae643d1eb for an example of that.

I don't see mentions of importPathToDir in this repository, so I don't think there's anything more to do here.

segevfiner

comment created time in 8 days

issue closedgolang/go

x/build/cmd/coordinator: many repeating js-wasm builds running every 15 seconds

Over at https://farmer.golang.org/#completed, I'm seeing a large number of js-wasm builders start every 15 seconds for the exact same commit:

image

Each one completes within a second with the following output:

  builder: js-wasm
      rev: dea961ebd9f871b39b3bdaab32f952037f28cd71
 buildlet: (nil *buildlet.Client)
  started: 2018-08-15 21:48:11.498031687 +0000 UTC m=+521730.873199532
    ended: 2018-08-15 21:48:11.658471517 +0000 UTC m=+521731.033639405
  success: true

Events:
  2018-08-15T21:48:11Z ask_maintner_has_ancestor 
  2018-08-15T21:48:11Z finish_ask_maintner_has_ancestor after 24.5ms
  2018-08-15T21:48:11Z skipped_build_missing_dep 

Build log:
skipping build; commit dea961ebd9f871b39b3bdaab32f952037f28cd71 lacks ancestor 3dced519cbabc213df369d9112206986e62687fa

This seems unintentional and suboptimal, right? If so, I'd like to better understand why it happens and try to fix it.

/cc @bradfitz

closed time in 8 days

dmitshur

issue commentgolang/go

x/build/cmd/coordinator: many repeating js-wasm builds running every 15 seconds

It does not appear to be. I've checked now, things look good, and I have not observed other occurrences in a long time.

"we shouldn't be trying to do js-wasm builds for release-branch.go1.10 or many other old branches" is resolved.

I don't think "a global wasSkippedBuild cache" was implemented. But it doesn't seem to be very relevant now.

Let's close this as resolved. If we find a problem, we can file a new issue with with current and actionable information.

dmitshur

comment created time in 8 days

issue commentgolang/go

x/all: document release branches

I'm in favor of renaming our release branches in golang.org/x repos starting with Go 1.16. I think that solution has good properties. It will require some changes in testing/release infrastructure and access controls, but they should be small and easy to do.

I suggest starting with Go 1.16 we rename them to internal-vendor.go1.X.

We've had the occasional need to make additional release branches in golang.org/x repos. For example, in https://github.com/golang/go/issues/36851#issuecomment-580943393, we made release-branch.go1.14-std and release-branch.go1.14-cmd to account for a deviation in go.mod versions across modules. In https://github.com/golang/go/issues/41375#issuecomment-713766922, we made release-branch.go1.15-bundle to account for a deviation in bundle version and go.mod version. (With #36852, #41409 being marked as release blockers, I expect those exact needs will not re-occur, but we may still run a new reason for why another internal branch should be made.)

How about a minor adjustment to your suggestion for a more scaleable pattern:

internal-branch.go1.X-vendor
internal-branch.go1.X-{purpose}  # If another internal branch needs to be made for a new reason.

Then the access controls can be updated so that only release managers can submit CLs to branches matching the regexps ^refs/heads/internal-branch.+ (for Go 1.16 and newer) and ^refs/heads/release-branch.+ (for Go 1.15 and older).

(I initially considered internal.go1.X-vendor but figured a longer and more ugly name will only help deter the misuse of these internal branches for other reasons.)

@FiloSottile Does this minor adjustment to the naming pattern still have the properties you're looking for?

@toothrot, @cagedmantis, @ianlancetaylor Does the plan above sound good to you, so we can move this issue to NeedsFix state?

rittneje

comment created time in 8 days

issue closedgolang/go

x/net/http2: connection-level flow control not returned if stream errors, causes server hang [1.15 backport]

@ianlancetaylor requested issue #40423 to be considered for backport to the next 1.15 minor release.

@gopherbot Please open backport issues.

This problem can reportedly cause an HTTP/2 connection to hang. There doesn't seem to be any reasonable workaround.

closed time in 8 days

gopherbot

issue commentgolang/go

x/net/http2: connection-level flow control not returned if stream errors, causes server hang [1.15 backport]

Closed by merging f68af196a36e740a56121dc759d1f0f3ab7749c6 to release-branch.go1.15.

gopherbot

comment created time in 8 days

issue closedgolang/go

x/net/http2: connection-level flow control not returned if stream errors, causes server hang [1.14 backport]

@ianlancetaylor requested issue #40423 to be considered for backport to the next 1.14 minor release.

@gopherbot Please open backport issues.

This problem can reportedly cause an HTTP/2 connection to hang. There doesn't seem to be any reasonable workaround.

closed time in 8 days

gopherbot

issue commentgolang/go

x/net/http2: connection-level flow control not returned if stream errors, causes server hang [1.14 backport]

Closed by merging 7bc838165d362d27bb2481c37680bb32e986b2d9 to release-branch.go1.14.

gopherbot

comment created time in 8 days

issue commentgolang/go

x/build: consider pushing open backport issue milestones automatically at start of each month

I've considered this idea during the development and release of Go 1.15.3 and 1.10.14 releases recently.

Those releases were not made at the beginning of the month because there were release-blocking issues open that needed more time to be resolved. During that time, we had an opportunity to make progress on additional backports.

I think it was helpful that it could be done without needing to move the milestone back on the issues that were fixed (and avoiding the risk of forgetting to do that).

Based on that, it seems the benefit of implementing this change is reduced. I welcome other feedback; I wanted to share my observations so far.

dmitshur

comment created time in 8 days

issue commentgolang/go

std,cmd: add test to ensure that all bundled packages are in sync with go.mod version

Managing backports can become much more expensive if skew is introduced in a new major Go release. This has happened in Go 1.15 (see https://github.com/golang/go/issues/41375#issuecomment-713766922 and CL 258540), and I think it's important we have an automated measure so we can be confident it can't happen for future Go releases due to human error.

I'm going to make this a release-blocker for Go 1.16: we should either resolve this issue by adding a test, or if there isn't enough time, we must manually verify that there is no skew introduced in Go 1.16 release candidates and the final release.

CC @golang/release.

dmitshur

comment created time in 8 days

issue commentgolang/go

std,cmd: add test to ensure that go.mod and vendor are in sync

Managing backports can become much more expensive if skew is introduced in a new major Go release. We've been lucky that go.mod and vendor skew hasn't made it into any major Go release so far (although it did happen on tip, e.g., #36851), but I think it's important we have an automated measure so we can be confident it can't happen due to human error.

I'm going to make this a release-blocker for Go 1.16: we should either resolve this issue by adding a test, or if there isn't enough time, we must manually verify that there is no skew introduced in Go 1.16 release candidates and the final release.

CC @golang/release.

dmitshur

comment created time in 8 days

issue commentgolang/go

x/build/cmd/coordinator, x/build/maintner/maintnerd/maintapi: pick right Go version for custom release branches

The problem is on this line:

https://github.com/golang/build/blob/247680342f28bf27b68358c64c491da551864749/cmd/coordinator/coordinator.go#L1220

When a release branch has a suffix (like "-bundle"), the branch == work.Branch equality won't hold.

A fix to allow suffixes separated by a dash could be to change that to work.Branch == branch || strings.HasPrefix(work.Branch, branch+"-").

dmitshur

comment created time in 9 days

issue openedgolang/go

x/build/cmd/coordinator, x/build/maintner/maintnerd/maintapi: pick right Go version for custom release branches

When trybots are testing a CL in a golang.org/x to a release branch with a custom suffix (e.g., release-branch.go1.14-cmd), they should use Go 1.13 to test that CL, not tip.

See CL 264058 where Go tip (1.16) was used, despite the release branch having a "go1.15" in it.

This is somewhat related to issues #37512 and #38303. Custom release branches are somewhat unusual (now for #41375, last time for #36851) and hopefully won't come up much in the future.

CC @golang/release.

created time in 9 days

issue commentgolang/go

x/net/http2: http2 healthcheck not in h2_bundle.go

For the record, on release-branch.go1.15 at the time of this posting, the bundled version of x/net was last updated in CL 231457, and it is currently version v0.0.0-20200501053045-e0ff5e5a1de5.

So, as is, there is a non-zero diff after regenerating net/http:

$ go generate ./net/http
$ git status | grep bundle
	modified:   net/http/h2_bundle.go
$

Using the aforementioned x/net version with a module-aware bundle results in a zero diff on release-branch.go.1.15:

$ go mod edit -replace=golang.org/x/net=golang.org/x/net@v0.0.0-20200501053045-e0ff5e5a1de5
$ GOFLAGS='-mod=mod' go generate ./net/http
$ git status | grep bundle
$

In order to be able to backport individual fixes to it (as needed for #41387 at this time), I'll create a release-branch.go1.15-bundle branch in x/net that points to commit golang/net@e0ff5e5a1de5.

phiphi282

comment created time in 9 days

issue commentgolang/go

proposal: add ios/amd64 as a GOOS/GOARCH

@rsc GOOS=ios already implies "darwin", like GOOS=android implies "linux. This issue is about making it so that an iOS binary can be built for the iOS Simulator in AMD64 architecture using the GOOS=ios GOARCH=amd64 configuration, rather than what it was before (GOOS=darwin GOARCH=arm64 -tags=ios).

I posted a question in https://github.com/golang/go/issues/38485#issuecomment-713683254 which is relevant (and probably would've been better to post in this issue instead).

The "GOOS=darwin GOARCH=amd64 -tags=ios" configuration was added in 2015, before there was as much attention paid to the porting policy as there is today. It was done with a single commit (see CL 12301) that resolved issue #11736.

I understand this proposal is to offer the same level of support for GOOS=ios GOARCH=amd64 as we did for GOOS=darwin GOARCH=amd64 -tags=ios.

Also CC @golang/release.

aclements

comment created time in 9 days

issue commentgolang/go

runtime: tracking bug for ARM-based macOS and GOOS/GOARCH values

The internet seems to agree: https://stackoverflow.com/questions/23895492/can-ios-arm-code-ever-be-run-in-a-simulator.

I had seen similar questions, but given they're multiple years old, I wasn't sure how relevant the answer was.

To make sure, I built an arm64 .app and pushed it to the simulator. It failed to start.

Great, thanks for trying and confirming that it fails today.

That said, it's likely that an arm-based macOS machine needs arm iOS binaries for the simulator.

That makes sense.

bradfitz

comment created time in 9 days

issue commentgolang/go

runtime: pageBits test failure on 386-linux

@mknyszek You're right that test-only fixes are generally safer to backport, which makes it an easier decision. That said, while okay in small numbers, we don't want to do it too frequently. We do it occasionally when there is a specific need, usually in order to fix false-positive failures during pre-release testing and trybots that run on cherry-pick CLs. If there's a good reason to backport a test-only fix, we will certainly consider it. You can do a search for test-only packports we've approved with this query.

In this case, it seems like the most important aspect here was to understand that this issue was in the test itself, and not a problem in the real code. So as I understand there isn't a strong need to backport the test fix anymore, especially since it doesn't affect testing done by our current builders. But if I'm missing something, please request a backport and provide a rationale.

Also CC @golang/release FYI.

Whissi

comment created time in 9 days

issue commentgolang/go

runtime: tracking bug for ARM-based macOS and GOOS/GOARCH values

@eliasnaur In the context of running the iOS Simulator on an AMD64-powered macOS device, do you know if it is still a requirement that the .app bundle contains a binary compiled to amd64 architecture in order to run on the simulator, or is the modern iOS Simulator capable of running arm64-only binaries too, just at a performance cost?

This question occurred to me because the last time I tried to use cmd/gomobile to build an app and run on the simulator, it seemed not to make a difference when I selected a subset of instruction sets (i.e., -target=ios/arm64 vs -target=ios/arm64,ios/amd64). As far as I remember (which could be mistaken; I'd have to double check now to be sure), the .app bundle seemed to run even without an amd64 binary.

So far, I wasn't able to find documentation that specifies the capabilities of the modern iOS Simulator. So I wanted to ask in case you already know the answer. I'm asking this question to understand the situation better, especially in the context of a potential builder that tests the ios/amd64 port. Thanks.

bradfitz

comment created time in 9 days

issue commentgolang/go

x/build: no SlowBot for "linux-amd64-nocgo"

I've looked over relevant code and wasn't able to spot a problem that would explain this. The linux-amd64-nocgo builder should be available as a SlowBot, like all other builders. It's possible I missed something, or maybe the problem is something subtle and rare (for example, maybe maintner corpus was behind, and the code that handles that edge-case has a problem).

From looking over CL 263357's more recent history, I see that the linux-amd64-nocgo slowbot was eventually picked up, which confirms this was an intermittent problem.

We can keep this issue open to track similar occurrences, should they happen again, and investigate further.

Adding a nocgo → linux-amd64-nocgo alias sounds reasonable. I've broken it out into #42105.

bcmills

comment created time in 10 days

issue openedgolang/go

x/build/dashboard: add nocgo slowbot alias to linux-amd64-nocgo builder

We can add a "nocgo" SlowBot alias, mapped to the linux-amd64-nocgo builder, so it's easier/shorter to test a CL with Cgo disabled. See #42084 for context. It should be a small CL.

CC @golang/release, @bcmills.

created time in 10 days

issue commentgolang/go

x/website:

What is the URL of the page where you're seeing this? Can you please include a screenshot?

archonsd

comment created time in 10 days

issue commentgolang/go

x/build/cmd/updatestd: investigate (at an appropriate time) a package-first update strategy, instead of module-first

Here is a strategy I am currently imagining if such a hypothetical flag is supported:

  1. Determine an import path pattern that matches packages contained in the current module. For the cmd module, it can be cmd/....
  2. Run go list -f '{{with .Module}}{{.Path}}{{end}}' -deps -test -ignore-build-constraints {pattern} to get a list of all module paths that are relevant (i.e., they contribute a direct or indirect dependent package to a package in the current module, considering all build contexts).
  3. Determine available updates for all modules. (If #40676 is resolved, maybe this can be done as part of the previous step.)
  4. Invoke a single go get command that updates all relevant packages (and none of the irrelevant ones) to the desired versions.

The outcome of this strategy seems good, but it is looks quite complicated to implement and maintain.

I'm not sure how lazy module loading (#36460) intersects with this. Maybe it will make it possible to implement this more simply after that's done?

dmitshur

comment created time in 10 days

more