profile
viewpoint
Dmitri Shuralyov dmitshur Google, Go team NYC https://dmitri.shuralyov.com I seek a better understanding of the world, so I can help make it simpler and better. I enjoy writing correct, high-quality Go code. Minimalist.

avelino/awesome-go 52279

A curated list of awesome Go frameworks, libraries and software

gopherjs/gopherjs 9186

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

glfw/glfw 6003

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

google/go-github 5551

Go library for accessing the GitHub API

dustin/go-humanize 2111

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

golang/tour 1070

[mirror] A Tour of Go

google/crfs 945

CRFS: Container Registry Filesystem

go-interpreter/wagon 837

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

gregjones/httpcache 496

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

mdempsky/unconvert 280

Remove unnecessary type conversions from Go source

issue commentgolang/go

go/format: normalize number prefixes and exponents, like cmd/gofmt does

I've investigated this briefly, and want to share my early findings. I looked into how it'd look if the responsibility of formatting numbers was moved from cmd/go into the go/printer package.

The go/printer package has a small amount of precedent for modifying the AST it is about to print. It happens when printing *ast.ImportSpec nodes:

func (p *printer) spec(spec ast.Spec, n int, doIndent bool) {
	switch s := spec.(type) {
	case *ast.ImportSpec:
		// ...
		p.expr(sanitizeImportPath(s.Path))
		// ...
}

func sanitizeImportPath(lit *ast.BasicLit) *ast.BasicLit { ... }

I realize that printing import paths (especially ones that need to be sanitized) happens much less frequently that numbers may need to be formatted, so it's very possible the same approach would not work for this. But I wanted to try it as a first step, and see if it would at least produce correct results or not.

It was easy to perform a simple code transformation and move normalizeNumbers from cmd/gofmt into go/printer, and start using it in the printer.expr1 method as follows:

 func (p *printer) expr1(expr ast.Expr, prec1, depth int) {
 	p.print(expr.Pos())
 
 	switch x := expr.(type) {
 	case *ast.BasicLit:
-		p.print(x)
+		switch x.Kind {
+		case token.INT, token.FLOAT, token.IMAG:
+			p.print(normalizeNumber(x))
+		default:
+			p.print(x)
+		}
 }
// normalizeNumber rewrites base prefixes and exponents to
// use lower-case letters, and removes leading 0's from
// integer imaginary literals. It leaves hexadecimal digits
// alone.
func normalizeNumber(lit *ast.BasicLit) *ast.BasicLit {
	if len(lit.Value) < 2 {
		return lit // only one digit (common case) - nothing to do
	}
	// len(lit.Value) >= 2

	// ... handle all the cases, return lit if there's no change, or a new &ast.BasicLit if there is
}

What I found so far:

  1. The aforementioned code transformation seems to produce correct results. All cmd/gofmt and go/... tests are passing (after adjusting one test case in go/printer to accommodate the new formatting behavior). I have not spotted any correctness problems yet.

  2. I am concerned that one of the tasks that normalizeNumbers does: removing leading 0's from integer imaginary literals. This operation modifies the length of the basic literal value by shortening it. I worry this may cause problems because the positions of all AST nodes after the modified one may become incorrect. I don't know if this is safe or will cause problems, and whether this may invalidate the approach of performing this formatting task as part of printing the AST in go/printer. Needs more investigation.

  3. If the above concern is resolved, the next step will be to run some benchmarks and see how much of a performance difference this implementation would incur (including whether allocating more *ast.BasicLit values is a significant problem).

dmitshur

comment created time in 2 hours

issue commentgolang/go

SIGILL: illegal instruction on any go tool under macOS [1.14 backport]

Approving per discussion in a release meeting because this is a serious issue without a workaround.

/cc @cagedmantis @toothrot

gopherbot

comment created time in 4 hours

issue commentgolang/go

runtime: "fatal error: unexpected signal" 0xC0000005 on Windows for a small program with a large allocation

@aclements You've asked for this issue to be backported to Go 1.14 and 1.13. This seems like a serious issue, do you think there is a workaround that can be used?

ulikunitz

comment created time in 4 hours

issue commentgolang/go

time: racy Timer access should either work or throw, not panic [1.14 backport]

Approving because it is a serious issue without a workaround.

gopherbot

comment created time in 4 hours

issue openedgolang/go

x/build/cmd/coordinator: doesn't support trybots on custom branches in golang.org/x repos

There appears to be no support for running trybots on branches other than master and release-branch.goX.Y in golang.org/x repos. It may be a matter of configuring more than 0 builders to run for such branches, or it may require more work in coordinator; this needs investigation.

This happened in https://golang.org/cl/221378, which was a CL into the gopls-release-branch.0.3 branch of golang.org/x/tools repo.

/cc @toothrot @cagedmantis @stamblerre @heschik

created time in 6 hours

issue closedgolang/go

x/build: GitHub rate limit exceeded for various tools

gopherbot can't make any calls to GitHub and gerritbot logs are showing that our quota is getting drained very quickly.

@bradfitz @dmitshur

closed time in 8 hours

andybons

issue commentgolang/go

x/build: GitHub rate limit exceeded for various tools

This specific outage has been resolved, and this issue isn't actionable, so I'll close it. We can open new issues if there is specific work that needs to be done.

andybons

comment created time in 8 hours

issue closedgolang/go

cmd/go: go get -u behaves as if -f is always provided (for non-custom import paths)

This is an issue since 2015. I discovered it on January 11, 2017, but I'm only getting around to reporting it now. I have a suggestion for resolution.

cmd/go documents the flag -f for use with go get -u at https://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies:

The -f flag, valid only when -u is set, forces get -u not to verify that each package has been checked out from the source control repository implied by its import path. This can be useful if the source is a local fork of the original.

However, for packages with a non-custom import path (custom import path being one that is defined by HTML meta tags, see isCustom), go get -u now behaves as if -f is always provided.

For custom import paths (e.g., rsc.io/pdf), there is no such issue.

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

$ go version
go version go1.8.1 darwin/amd64

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

<details>

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/tmp/fresh"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/go-build606008153=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

</details>

What did you do?

Everything works as expected for custom import paths:

$ export GOPATH=/tmp/fresh
$ go get -u rsc.io/pdf
$ cd $GOPATH/src/rsc.io/pdf
$ git remote -v
origin	https://github.com/rsc/pdf (fetch)
origin	https://github.com/rsc/pdf (push)
$ git remote set-url origin https://github.com/wrong/repo
$ go get -u rsc.io/pdf
package rsc.io/pdf: rsc.io/pdf is a custom import path for https://github.com/rsc/pdf,
but /tmp/fresh/src/rsc.io/pdf is checked out from https://github.com/wrong/repo
$ echo $?
1
$ go get -u -f rsc.io/pdf
$ echo $?
0

(For demonstration purposes, assume that https://github.com/wrong/repo contains arbitrary git history, such that it's git pull --ff-only-compatible with the repo I'm trying to update. I don't want to spend time creating GitHub repos that have this property, but it's possible.)

However, this is what happens for a non-custom import path:

$ go get -u github.com/gorilla/mux
$ cd $GOPATH/src/github.com/gorilla/mux
$ git remote -v
origin	https://github.com/gorilla/mux (fetch)
origin	https://github.com/gorilla/mux (push)
$ git remote set-url origin https://github.com/wrong/repo
$ go get -u github.com/gorilla/mux
$ echo $?
0
$ go get -u -f github.com/gorilla/mux
$ echo $?
0

What did you expect to see?

$ git remote set-url origin https://github.com/wrong/repo
$ go get -u github.com/gorilla/mux
package github.com/gorilla/mux: github.com/gorilla/mux is an import path for https://github.com/gorilla/mux,
but /tmp/fresh/src/github.com/gorilla/mux is checked out from https://github.com/wrong/repo
$ echo $?
1
$ go get -u -f github.com/gorilla/mux
$ echo $?
0

What did you see instead?

$ git remote set-url origin https://github.com/wrong/repo
$ go get -u github.com/gorilla/mux
$ echo $?
0
$ go get -u -f github.com/gorilla/mux
$ echo $?
0

Fix

This regression was introduced while resolving another issue. I have a suggestion for how to fix it so both things are fixed. Details will follow in next comment.

closed time in 8 hours

dmitshur

issue commentgolang/go

cmd/go: go get -u behaves as if -f is always provided (for non-custom import paths)

@rsc You were right in that https://github.com/golang/go/issues/20039#issuecomment-335637480 from 2017. I believe this issue has been addressed by the addition of module mode.

As you said, making a change to go get -u behavior in GOPATH mode at this point is not a good idea as it will help some people but make things worse for others, so I think the right course of action given this is not an issue in module mode is to not make any changes. I'll close this issue.

(This issue makes me think of the "The best way to predict the future is to create it." quote.)

/cc @jayconrod @matloob @bcmills

dmitshur

comment created time in 8 hours

push eventmdempsky/unconvert

Dmitri Shuralyov

commit sha 335fbbc52b320c3f7df0b6e7c925e1026a9c1971

unconvert: update Travis for Go 1.14 Go 1.14 has been released¹ by now. Start testing against it. Drop Go 1.12 to maintain coverage for just the last 2 Go releases. Use the "go1.x" form to refer to the latest stable Go release rather than the "go1.14.x" form, because this form requires less maintenance when new Go releases are made. ¹ https://groups.google.com/d/msg/golang-announce/AYd4cXYG8qk/FPTwU0jPCQAJ

view details

push time in 8 hours

issue closedgolang/go

go.dev: Examples title is not generated, anchor link to examples is not working

On https://pkg.go.dev/cloud.google.com/go, the "Examples" anchor link is not working because there is no "Examples" title in the page. I couldn't reproduce it in other pages.

closed time in a day

rakyll

issue commentgolang/go

go.dev: Examples title is not generated, anchor link to examples is not working

This issue is resolved at https://pkg.go.dev/cloud.google.com/go by now, so I'll close this. Please let me know if there's anything more.

rakyll

comment created time in a day

issue closedgolang/go

os/exec: environForSysProcAttr is never called as sysattr.Env is never nil [1.12 backport]

@ianlancetaylor requested issue #35314 to be considered for backport to the next 1.12 minor release.

I have no idea.

@gopherbot Please open backport issues

This may be security related on Windows systems.

closed time in a day

gopherbot

issue commentgolang/go

os/exec: environForSysProcAttr is never called as sysattr.Env is never nil [1.12 backport]

Go 1.14 has been released, so there will not be more Go 1.12.x releases per the release policy. I'll close this issue so that it doesn't get in the way when searching for other issues in CherryPickCandidate state.

gopherbot

comment created time in a day

issue closedgolang/go

crypto/cipher: NewGCMWithNonceSize allows zero-length nonce [1.12 backport]

@networkimprov requested issue #37118 to be considered for backport to the next 1.12 minor release.

@gopherbot ple​ase open backport, at suggestion of @FiloSottile.

closed time in a day

dmitshur

issue commentgolang/go

crypto/cipher: NewGCMWithNonceSize allows zero-length nonce [1.12 backport]

Go 1.14 has been released, so there will not be more Go 1.12.x releases per the release policy. I'll close this issue so that it doesn't get in the way when searching for other issues in CherryPickApproved state.

dmitshur

comment created time in a day

issue closedgolang/go

PowerRegisterSuspendResumeNotification error on Azure App Services with go 1.13.7 [1.12 backport]

@networkimprov requested issue #37149 to be considered for backport to the next 1.12 minor release.

@gopherbot please backport. It's another instance of this regression...

closed time in a day

gopherbot

issue commentgolang/go

PowerRegisterSuspendResumeNotification error on Azure App Services with go 1.13.7 [1.12 backport]

Go 1.14 has been released, so there will not be more Go 1.12.x releases per the release policy. I'll close this issue so that it doesn't get in the way when searching for other issues in CherryPickCandidate state.

gopherbot

comment created time in a day

issue closedgolang/go

go/types: data race in representableConst in Go 1.13 and earlier [1.12 backport]

@matloob requested issue #36687 to be considered for backport to the next 1.12 minor release.

@gopherbot backport please 1.12 1.13

closed time in a day

gopherbot

issue commentgolang/go

go/types: data race in representableConst in Go 1.13 and earlier [1.12 backport]

Go 1.14 has been released, so there will not be more Go 1.12.x releases per the release policy. I'll close this issue so that it doesn't get in the way when searching for other issues in CherryPickCandidate state.

gopherbot

comment created time in a day

issue commentgolang/go

runtime: "fatal error: unexpected signal" 0xC0000005 on Windows for a small program with a large allocation

Oops. @gopherbot, please open a backport to Go 1.13.

Manually opened #37483 for Go 1.13.

ulikunitz

comment created time in a day

issue openedgolang/go

runtime: "fatal error: unexpected signal" 0xC0000005 on Windows for a small program with a large allocation [1.13 backport]

@aclements requested issue #37470 to be considered for backport to the next 1.13 minor release.

@gopherbot, ple​ase open a backport to Go 1.14 and Go ~1.15~ 1.13.

created time in a day

issue commentgolang/go

SIGILL: illegal instruction on any go tool under macOS 10.14.6

@gopherbot Please open a backport for 1.14. This is a regression in 1.14, and it is a serious problem (program doesn't run on affected hardware) without a workaround.

carlca

comment created time in a day

issue closedgolang/go

runtime: dependency on AVX instruction set added in Go 1.14 on macOS

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

<pre> go version go1.14 darwin/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> GO111MODULE="on" GOARCH="amd64" GOBIN="" GOCACHE="/Users/jamesp/Library/Caches/go-build" GOENV="/Users/jamesp/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darwin" GOPATH="/Users/u1/go" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/15/1z0sxl6971s3m1_zbp9szwkc0000gp/T/go-build113341206=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

What did you do?

Run go with no parameters on a late 2009 iMac. Mac does not support AVX instructions until 2012 (so far as I can tell). So while the OS support is up to High Sierra, the chip won't support the new version of go due to the src/runtime/preempt_amd64.s using VZEROUPPER from the AVX instruction set. 1.14rc1 did not use it and work fine.

Also note the version and env subcommands don't work either, I had to doctor the above output from 1.14rc1.

What did you expect to see?

"Go is a tool for managing Go source code." ...

What did you see instead?

<pre> SIGILL: illegal instruction PC=0x1066040 m=0 sigcode=1

goroutine 1 [running, locked to thread]: runtime.asyncPreempt() /usr/local/go/src/runtime/preempt_amd64.s:8 fp=0xc00005ae30 sp=0xc00005ae28 pc=0x1066040 go/ast.NewIdent(0x163511b, 0x1, 0xc00011c300) /usr/local/go/src/go/ast/ast.go:522 fp=0xc00005ae38 sp=0xc00005ae30 pc=0x110fa60 go/doc.init() /usr/local/go/src/go/doc/exports.go:28 +0x1f8 fp=0xc00005ae98 sp=0xc00005ae38 pc=0x1170a68 runtime.doInit(0x1a81840) /usr/local/go/src/runtime/proc.go:5414 +0x8a fp=0xc00005aec8 sp=0xc00005ae98 pc=0x1043aca runtime.doInit(0x1a834a0) /usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc00005aef8 sp=0xc00005aec8 pc=0x1043a97 runtime.doInit(0x1a81140) /usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc00005af28 sp=0xc00005aef8 pc=0x1043a97 runtime.doInit(0x1a828a0) /usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc00005af58 sp=0xc00005af28 pc=0x1043a97 runtime.doInit(0x1a850c0) /usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc00005af88 sp=0xc00005af58 pc=0x1043a97 runtime.main() /usr/local/go/src/runtime/proc.go:190 +0x1ce fp=0xc00005afe0 sp=0xc00005af88 pc=0x103702e runtime.goexit() /usr/local/go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc00005afe8 sp=0xc00005afe0 pc=0x10647d1

rax 0x163511b rbx 0x0 rcx 0x1d12e98 rdx 0x9778 rdi 0xc00011c300 rsi 0x28 rbp 0xc00005ae88 rsp 0xc00005ae28 r8 0x9008e19 r9 0x203000 r10 0x2 r11 0x11 r12 0xf1 r13 0x0 r14 0x171acbc r15 0x0 rip 0x1066040 rflags 0x10246 cs 0x2b fs 0x0 gs 0x0

</pre>

closed time in a day

japettyjohn

issue commentgolang/go

runtime: dependency on AVX instruction set added in Go 1.14 on macOS

This does seem to be a duplicate of #37459, so I'll close it in favor of that issue.

japettyjohn

comment created time in a day

issue commentgolang/go

runtime: dependency on AVX instruction set added in Go 1.14 on macOS

VZEROUPPER was added in CL 219131 for issue #37174.

This issue may be the same as #37459, which was recently reported and resolved.

/cc @cherrymui @randall77 @aclements

japettyjohn

comment created time in a day

issue commentgolang/go

go/format: normalize number prefixes and exponents, like cmd/gofmt does

A flag to control this behavior is possible, but I don't think it would be helpful, and so I prefer it's not added without a good reason. We can never remove the flag and it'll adding some complexity.

If someone wants to "disable" this behavior, or produce Go code that is formatted in a way that is compatible with an older version of Go, a better way of accomplishing that is by using the cmd/gofmt binary or the go/format package from an older version of Go.

dmitshur

comment created time in a day

issue commentgolang/go

go/format: normalize number prefixes and exponents, like cmd/gofmt does

I suspect go/printer may be a good place for it. Whoever is working on this issue should investigate that possibility and compare it with others.

dmitshur

comment created time in a day

issue openedgolang/go

go/format: normalize number prefixes and exponents, like cmd/gofmt does

CL 160184 implemented a change to cmd/gofmt for Go 1.13 to normalize number prefixes and expontents.

The same change should be applied to the go/format package (or one of its dependencies, depending on where it's most appropriate to implement).

/cc @griesemer @cespare @heschik

created time in a day

issue closedgolang/go

go web server don't show html pages (show html code)

<!-- 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 1.14 </pre>

Does this issue reproduce with the latest release?

yes

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

xubuntu 18.04 <details><summary><code>go env</code> Output</summary><br><pre> $ go env export PATH=$PATH:/usr/local/go/bin

</pre></details>

What did you do?

I write a simple web server by golang. I use gorilla package and i have a problem to show html body of web page. I have an html code instead of web page/ I tried mozilla and chrome (same result) package main import ( "html/template" "net/http" "github.com/gorilla/mux" ) func main() { router := mux.NewRouter() router.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { tmpl, _ := template.ParseFiles("index.html") tmpl.Execute(w, nil) }) http.Handle("/", router) http.ListenAndServe(":8181", nil) }

What did you expect to see?

blabla bla bla bla bla bla bla bla bla bla bla

What did you see instead?

I see raw html code: .... <html> <head> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Title</title> </head> <body> <p>blabla bla bla bla bla bla bla bla bla bla bla</p> </body> </html>

closed time in a day

SergeyVlasov

issue commentgolang/go

go web server don't show html pages (show html code)

Setting the Content-Type header explicitly makes it so that browsers (and the HTTP server) don't have to guess what the content type is. Guessing is hard when the content is very short. Glad you figured this out.

Closing since this isn't a bug in the Go project.

SergeyVlasov

comment created time in a day

issue commentgolang/go

internal/go115: add package

The email said they were needed for all risky changes, and explicitly said that all compiler changes that changed generated code were deemed risky.

They're meant for changes that are both risky and potentially hard to diagnose. I think what @aclements wrote here is very good guidance. Sorry if the email was confusing, but I certainly didn't mean for all compiler changes to require a flag regardless of the cost of doing so. The flags should be added when they're helpful to humans.

josharian

comment created time in a day

issue commentgolang/go

internal/go115: add package

It may make sense to group many smaller individual risky changes together behind a single large flag, rather than having more small flags.

We don't have plans to actively test flag combinations during the Go 1.15 development cycle as part of the builders yet. They're for humans to use when we get closer to beta/RC in case we need to investigate hard-to-diagnose issues. Having fewer flags should be fine; it's meant to serve as a coarse debugging aid.

josharian

comment created time in a day

issue commentgolang/go

internal/go115: add package

@josharian How many flags do you anticipate needing? Remember that each flag needs its own tracking release-blocker issue. If we were to do this practice for Go 1.14, I'd expect it would've had 3-6 such flags.

josharian

comment created time in a day

issue commentgolang/go

internal/go115: add package

From the "Planning Go 1.15" mail, the rule that everyone must follow is simple:

The flag must be findable by a simple grep for the string "go115"

I think adding a internal/go115 package is fine. A go115.DoNewRiskyThing constant would satisfy the rule.

I suggest starting with a simple bool constant and go from there. I don't see the need to start using strings or build constraints; those should come later when the need for them is more clear.

If someone doesn't want to use the internal/go115 package for their constant, that's fine too. It just needs to findable via the string "go115" .

josharian

comment created time in a day

issue openedgolang/go

consider using GitHub Discussions Beta when it comes out

The Go project use the GitHub issue tracker for asking questions.

Proposal #23745 was about considering using it with a "question" label, which we tried, but it wasn't a great experience for everyone involved (an issue tracker is designed primarily for tracking bugs, not asking questions or having discussions), and so we didn't proceed with it.

As @mvdan mentioned in https://github.com/golang/go/issues/23745#issuecomment-591378648, GitHub is working on a new Discussions feature that is specifically for having discussions rather than tracking bugs. Once it becomes available for general use, we can consider using it for the Go project.

This is the tracking issue.

(Until something changes, please see https://golang.org/wiki/Questions for a list of places to ask questions and having discussions.)

/cc @golang/osp-team

created time in a day

issue commentgolang/go

x/build/cmd/releasebot: consider a third -mode=wrapup mode for wrapping up a release

CL 221097 deletes the following check from Work.checkDocs method, because it cannot be done as part of the prepare or release modes as it was done before (it's too soon):

// TODO: Delete this block after Go 1.14 is released (and Go 1.12 is no longer supported),
//       or consider moving it into a third -mode=wrapup. See golang.org/issue/36086.
if w.activeReleaseHistory() {
	// Check that the release is listed on the release history page.
	data, err := ioutil.ReadFile(filepath.Join(w.Dir, "gitwork", "doc/devel/release.html"))
	if err != nil {
		w.log.Panic(err)
	}
	if !strings.Contains(string(data), w.Version+" (released ") {
		w.logError("doc/devel/release.html does not document %s", w.Version)
	}
}

If a third wrapup mode is added, it can be re-added as part of that mode.

dmitshur

comment created time in a day

pull request commentmdempsky/unconvert

unconvert: update Travis for Go 1.14

CI is failing on Go 1.14. It will be fixed by #49.

dmitshur

comment created time in a day

PR opened mdempsky/unconvert

unconvert: update dependency versions

A newer version of golang.org/x/tools is needed to be compatible with Go 1.14. Update golang.org/x/text to the latest release too.

Fixes #48.

+16 -6

0 comment

2 changed files

pr created time in a day

create barnchmdempsky/unconvert

branch : update-deps

created branch time in a day

issue openedmdempsky/unconvert

internal error importing packages when built with Go 1.14

To reproduce:

$ go version
go version go1.14 darwin/amd64
$ export GO111MODULE=on
$ export GOPATH=$(mktemp -d)
$ go get github.com/mdempsky/unconvert
go: downloading github.com/mdempsky/unconvert v0.0.0-20190921185256-3ecd357795af
go: github.com/mdempsky/unconvert upgrade => v0.0.0-20190921185256-3ecd357795af
go: downloading golang.org/x/text v0.3.0
go: downloading golang.org/x/tools v0.0.0-20190325161752-5a8dccf5b48a
$ $(go env GOPATH)/bin/unconvert fmt
2020/02/26 08:52:23 internal error: nil Pkg importing "errors" from "fmt [fmt.test]"
2020/02/26 08:52:23 internal error: nil Pkg importing "errors" from "fmt"

The problem seems to be an old version of x/tools module. Updating it fixes it. I'll send a PR.

created time in a day

PR opened mdempsky/unconvert

unconvert: update Travis for Go 1.14

Go 1.14 has been released¹ by now.

¹ https://groups.google.com/d/msg/golang-announce/AYd4cXYG8qk/FPTwU0jPCQAJ

+1 -1

0 comment

1 changed file

pr created time in a day

create barnchmdempsky/unconvert

branch : travis-go114

created branch time in a day

issue commentgolang/go

cmd/go: go mod vendor in empty new project produces confusing error message in 1.14

/cc @bcmills @matloob @jayconrod

cocorambo

comment created time in a day

issue commentgolang/go

doc: restructure module documentation

@AlphaHot Can you please file a new issue and fill in the answers to “what did you do”, “what did you expect to see”, and “what happened instead”? It will be easier to investigate with more information. Thanks.

jayconrod

comment created time in a day

issue closedgolang/go

all: Go 1.14 release status

Issue tracking the go1.14 release by releasebot.

closed time in 2 days

cagedmantis

issue commentgolang/go

all: Go 1.14 release status

I believe this release is done, so I'll close this.

@cagedmantis Let me know if there's anything left to do and if it should be re-opened.

cagedmantis

comment created time in 2 days

issue commentgolang/go

x/text/unicode/norm: TestLinking consistently failing on multiple builders

No problem, and thank you Jeremy. I just wanted to update our list of Soon issues.

bcmills

comment created time in 2 days

issue commentgolang/go

x/text/unicode/norm: TestLinking consistently failing on multiple builders

Friendly ping.

This issue currently has the label Soon, which is for regressions, serious bugs, and outages. This doesn't seem to qualify for that, so I'll remove the Soon label.

bcmills

comment created time in 2 days

issue commentgolang/go

x/tools/internal/imports: test frequently times out on `dragonfly-amd64` builder

Dragonfly isn't one of the first-class ports according to the checkbox on https://build.golang.org. It seems no one is actively working on this. As a result, I don't think it's appropriate for this issue to have the Soon label, which is meant for regressions, serious bugs, and outages.

This issue still needs investigation and resolution, but unless I'm missing something, it doesn't meet the bar for Soon.

bcmills

comment created time in 2 days

issue commentgolang/go

cmd/go/internal/modfetch: TestCodeRepo failures due to external repo changes

This is neither a regressions, serious bug, nor an outage, so removing Soon. It should be fixed, but that label is meant for things that are done in the order of days.

ALTree

comment created time in 2 days

issue commentgolang/go

x/image: Go fonts not representative of OpenType state of the art

/cc @nigeltao @robpike

nim-nim

comment created time in 2 days

issue commentgolang/go

time: Timer sequences newly panic with "racy use of timers"

This issue is blocking the Go 1.14 release, which is currently underway (but has not been cut yet, so we can still safely abort it or make changes if necessary). See https://github.com/golang/go/issues/37445#issuecomment-590983882.

bcmills

comment created time in 2 days

issue commentgolang/go

time: Timer sequences newly panic with "racy use of timers"

This program crashes very quickly

I can reproduce this with go1.14rc1, go1.14beta1, but also with go1.13.7 on darwin/amd64:

<details><br>

$ go run .
panic: runtime error: racy use of timers

goroutine 195 [running]:
time.stopTimer(0xc00005af08, 0x1)
	/usr/local/go/src/runtime/time.go:224 +0x2b
time.(*Timer).Stop(0xc00005af00, 0x3b9aca00)
	/usr/local/go/src/time/sleep.go:78 +0x36
created by main.main
	/var/folders/zb/5p8cwfhj29gf_m8vdy8ylmlr00jwcj/T/tmp.5VGZN9cY/main.go:10 +0xb5
exit status 2
$ go1.14beta1 run .
panic: runtime error: racy use of timers

goroutine 177 [running]:
time.stopTimer(0xc000060c88, 0x1)
	/Users/dmitshur/sdk/go1.14beta1/src/runtime/time.go:219 +0x2b
time.(*Timer).Stop(0xc000060c80, 0x3b9aca00)
	/Users/dmitshur/sdk/go1.14beta1/src/time/sleep.go:78 +0x36
created by main.main
	/var/folders/zb/5p8cwfhj29gf_m8vdy8ylmlr00jwcj/T/tmp.5VGZN9cY/main.go:10 +0xb5
panic: runtime error: racy use of timers

goroutine 198 [running]:
time.resetTimer(0xc000060e18, 0xb9845fda967c)
	/Users/dmitshur/sdk/go1.14beta1/src/runtime/time.go:228 +0x35
time.(*Timer).Reset(0xc000060e10, 0x3b9aca00, 0x0)
	/Users/dmitshur/sdk/go1.14beta1/src/time/sleep.go:126 +0x7d
created by main.main
	/var/folders/zb/5p8cwfhj29gf_m8vdy8ylmlr00jwcj/T/tmp.5VGZN9cY/main.go:11 +0xe0
exit status 2
$ go1.13.7 run .   
panic: runtime error: racy use of timers

goroutine 355 [running]:
time.startTimer(0xc000087548)
	/Users/dmitshur/sdk/go1.13.7/src/runtime/time.go:114 +0x2b
time.(*Timer).Reset(0xc000087540, 0x3b9aca00, 0x0)
	/Users/dmitshur/sdk/go1.13.7/src/time/sleep.go:126 +0x81
created by main.main
	/var/folders/zb/5p8cwfhj29gf_m8vdy8ylmlr00jwcj/T/tmp.5VGZN9cY/main.go:9 +0x93
exit status 2

</details>

bcmills

comment created time in 2 days

issue commentgolang/go

crypto/cipher: NewGCMWithNonceSize allows zero-length nonce

/cc @dunhamsteve FYI.

katiehockman

comment created time in 2 days

create barnchshurcooL/home

branch : dev

created branch time in 3 days

issue commentgolang/go

testing: when using a custom TestMain, m.Run does not return if one of the tests it runs panics

Thank you for explaining the current situation and trade-offs in https://github.com/golang/go/issues/37206#issuecomment-590441512, @ianlancetaylor.

My opinion is that we should hold off on complicating the testing package until a time when all panics can be handled (since doing it for only some goroutines isn't very worthwhile), and document the rationale for m.Run not returning in the case of a panic so we can look it up in the future. If it's viable to document it publicly without locking in the current behavior, that would be better, but otherwise it can be documented internally in the testing package.

orlangure

comment created time in 3 days

issue commentgolang/go

cmd/compile: Investigate regression in vs 1.13

/cc @aclements @randall77

dr2chase

comment created time in 3 days

issue openedgolang/go

x/build: disable darwin-amd64-10_11 builder on master branch

Go 1.15 will require macOS 10.12 and newer, so the macOS 10.11 builder should be disabled on the master branch now.

See https://github.com/golang/go/issues/37406#issuecomment-590549295 for additional context.

/cc @golang/osp-team

created time in 3 days

issue commentgolang/go

cmd/compile: "internal compiler error: … unhandled expr" on darwin-amd64-10_11 builder

Ah, I missed the "for the main branch" bit. Yes, we should do that, since Go 1.15 won't support macOS 10.11.

bcmills

comment created time in 3 days

issue commentgolang/go

cmd/compile: "internal compiler error: … unhandled expr" on darwin-amd64-10_11 builder

@bcmills I'm not sure I understand the suggestion. Both Go 1.14 and 1.13 still support macOS 10.11, so it'll be another 12 months before we no longer support macOS 10.11 at all (when Go 1.15 becomes the oldest supported Go release).

bcmills

comment created time in 3 days

issue openedgolang/go

doc: write Go 1.15 release notes

Tracking bug for writing the Go 1.15 Release Notes.

The latest state on tip can be viewed at https://tip.golang.org/doc/go1.15.

Previously #36878, #17929, #15810, #5929, etc.

created time in 3 days

issue commentgolang/go

crypto/cipher: NewGCMWithNonceSize allows zero-length nonce [1.12 backport]

Approving this backport. It's a small security hardening fix.

dmitshur

comment created time in 3 days

issue commentgolang/go

crypto/cipher: NewGCMWithNonceSize allows zero-length nonce [1.13 backport]

Approving this backport. It's a small security hardening fix.

gopherbot

comment created time in 3 days

issue commentgolang/go

crypto/cipher: NewGCMWithNonceSize allows zero-length nonce [1.14 backport]

Approving this backport. It's a small security hardening fix.

gopherbot

comment created time in 3 days

issue commentgolang/go

crypto/cipher: NewGCMWithNonceSize allows zero-length nonce [1.14 backport]

Ok, let's not take shortcuts. Opened #37418 for the 1.12 backport.

gopherbot

comment created time in 3 days

issue openedgolang/go

crypto/cipher: NewGCMWithNonceSize allows zero-length nonce [1.12 backport]

@networkimprov requested issue #37118 to be considered for backport to the next 1.12 minor release.

@gopherbot ple​ase open backport, at suggestion of @FiloSottile.

created time in 3 days

issue commentgolang/go

crypto/cipher: NewGCMWithNonceSize allows zero-length nonce

I'll repurpose the 1.12 one. It won't be getting this backport.

katiehockman

comment created time in 3 days

issue commentshurcooL/githubv4

Parse 502 status code response as a GraphQL response.

Another use case is for detecting when a rate limit is hit. According to https://github.com/shurcooL/githubv4/issues/57#issue-569538004, GitHub returns HTTP 429 status code in those cases.

dmitshur

comment created time in 4 days

issue commentshurcooL/githubv4

rate limiting: how to ?

As far as I can tell, this package doesn't have any specific code path to handle the Github rate limiting.

That is true. However, note that you can always query the current rate limit by adding a rateLimit field to your query. See https://developer.github.com/v4/query/#ratelimit.

It'd be nice to at least return a specific error on HTTP 429 so that retry/back-of could be implemented outside of this package.

Yes, this should be done. It's being tracked by issue #38.

Ideally this would be implemented within githubv4.

Maybe, in the long term. First step is to implement some solution. Then see if it can be generalized well enough. If so, we can consider factoring it into githubv4.

GitHub API v3 package automatically detects when the returned GitHub error was due to rate limit being depleted, and computes how long until the rate limit will be reset. It's also smart enough not to talk to GitHub as long as the rate limit reset time hasn't passed yet. Hopefully it'll be possible to do similar things here with v4.

MichaelMure

comment created time in 4 days

issue commentgo-gl/glfw

v3.3/glfw: PostEmptyEvent crashes if called first on non-main thread on macOS

Note that the crash can be worked around by calling glfw.PostEmptyEvent on main thread first, before it has a chance to be called on non-main thread.

The following does not crash:

func main() {
	err := glfw.Init()
	if err != nil {
		log.Fatalln(err)
	}
	defer glfw.Terminate()

	glfw.PostEmptyEvent()    // call PostEmptyEvent in main thread first
	go glfw.PostEmptyEvent() // call PostEmptyEvent in non-main thread second

	select {}
}
dmitshur

comment created time in 4 days

issue openedgo-gl/glfw

v3.3/glfw: PostEmptyEvent crashes if called first on non-main thread on macOS

This is the golang.org/go-gl/glfw/v3.3/glfw tracking bug for upstream GLFW issue glfw/glfw#1649. It can be reproduced with the following Go program:

package main

import (
	"log"
	"runtime"

	"github.com/go-gl/glfw/v3.3/glfw"
)

func init() { runtime.LockOSThread() }

func main() {
	err := glfw.Init()
	if err != nil {
		log.Fatalln(err)
	}
	defer glfw.Terminate()

	go glfw.PostEmptyEvent() // call PostEmptyEvent in non-main thread

	select {}
}

Running it on macOS 10.15.3 with Xcode 11.3.1 produces the following crash:

<details><br>

$ go run .                                     
2020-02-22 13:50:10.100 m[22196:92162] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /BuildRoot/Library/Caches/com.apple.xbs/Sources/Foundation/Foundation-1674.114/Foundation/Misc.subproj/NSUndoManager.m:363
2020-02-22 13:50:10.100 m[22196:92162] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '+[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff394778ab __exceptionPreprocess + 250
	1   libobjc.A.dylib                     0x00007fff6f731805 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff394a0d10 +[NSException raise:format:arguments:] + 88
	3   Foundation                          0x00007fff3bb99241 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191
	4   Foundation                          0x00007fff3bad7d5e +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 440
	5   AppKit                              0x00007fff365b016c -[NSApplication run] + 864
	6   m                                   0x00000000040b0046 _glfwPlatformPostEmptyEvent + 54
	7   m                                   0x000000000405cc90 runtime.asmcgocall + 112
)
libc++abi.dylib: terminating with uncaught exception of type NSException
SIGABRT: abort
PC=0x7fff70be67fa m=3 sigcode=0

</details>

To make progress here, we need to resolve glfw/glfw#1649 first, wait for a new GLFW version with the fix included to be released, and then pull in the fixed GLFW version into golang.org/go-gl/glfw/v3.3/glfw.

created time in 4 days

issue openedglfw/glfw

Cocoa pre-window-creation event processing fix causes glfwPostEmptyEvent to crash program when called from non-main thread

Issue #1543 was resolved by commit 6e6805000ac7ddf39c8c5f6be3e877770cba5083.

Commit 6e6805000ac7ddf39c8c5f6be3e877770cba5083 adds the following code to _glfwPlatformPostEmptyEvent:

+    if (!_glfw.ns.finishedLaunching)
+        [NSApp run];

I'm not sure if this is safe to do.

glfwPostEmptyEvent is documented to be safe to call from any thread. Documentation for NSApp.run itself doesn't say anything about what thread it may be run on, but in practice, it seems to call another method, which is not safe to call on non-main thread, and throws NSInternalInconsistencyException.

Consider the following trivial Go program (sorry, I don't remember how to write threaded code in C by now) that uses GLFW 3.3.2 and calls glfwPostEmptyEvent on non-main thread:

package main

import (
	"log"
	"runtime"

	"github.com/go-gl/glfw/v3.3/glfw"
)

func init() { runtime.LockOSThread() }

func main() {
	err := glfw.Init()
	if err != nil {
		log.Fatalln(err)
	}
	defer glfw.Terminate()

	go glfw.PostEmptyEvent() // call PostEmptyEvent in non-main thread

	select {} // wait forever
}

Before commit 6e6805000ac7ddf39c8c5f6be3e877770cba5083, it works fine.

After commit 6e6805000ac7ddf39c8c5f6be3e877770cba5083, it crashes with:

$ go run .                                     
2020-02-22 13:50:10.100 m[22196:92162] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /BuildRoot/Library/Caches/com.apple.xbs/Sources/Foundation/Foundation-1674.114/Foundation/Misc.subproj/NSUndoManager.m:363
2020-02-22 13:50:10.100 m[22196:92162] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '+[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff394778ab __exceptionPreprocess + 250
	1   libobjc.A.dylib                     0x00007fff6f731805 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff394a0d10 +[NSException raise:format:arguments:] + 88
	3   Foundation                          0x00007fff3bb99241 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191
	4   Foundation                          0x00007fff3bad7d5e +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 440
	5   AppKit                              0x00007fff365b016c -[NSApplication run] + 864
	6   m                                   0x00000000040b0046 _glfwPlatformPostEmptyEvent + 54
	7   m                                   0x000000000405cc90 runtime.asmcgocall + 112
)
libc++abi.dylib: terminating with uncaught exception of type NSException
SIGABRT: abort
PC=0x7fff70be67fa m=3 sigcode=0

This may be somewhat related to #1588.

/cc @elmindreda

created time in 5 days

pull request commentgraphql/graphql.github.io

move machinebox/graphql from server to client section

Friendly ping @orta.

dmitshur

comment created time in 5 days

delete branch dmitshur/indieauth

delete branch : terminology-consistency

delete time in 5 days

PR closed golang/go

hash/maphash: don't discard data on random seed init cla: yes

Hash initializes seed on the first usage of seed or state with initSeed. initSeed uses SetSeed which discards accumulated data. This causes hash to return different sums for the same data in the first use and after reset. This CL fixes this issue by separating the seed set from data discard.

Fixes #37315

+30 -2

12 comments

2 changed files

vovapi

pr closed time in 5 days

pull request commentgolang/go

hash/maphash: don't discard data on random seed init

Closing because this PR has been merged via CL 220617 as commit 638df87fa4f927763f99ebf0c6bc9c4a5380d1f9.

gerritbot should've done this; we need to investigate why it didn't. See https://github.com/golang/go/issues/35867#issuecomment-589971216.

vovapi

comment created time in 5 days

issue commentgolang/go

x/build/cmd/gerritbot: running into letsencrypt authorization rate limit

For now, I've just redeployed gerritbot. Let's see if this continues to happen.

dmitshur

comment created time in 5 days

issue commentgolang/go

x/build/cmd/gerritbot: didn't close a PR that was submitted

This seems to be happening again with PR #37328. It has been submitted on Gerrit 30 minutes ago, yet gerritbot isn't closing it.

From its logs:

2020/02/22 15:49:57 Retrieving PR golang/go#37328 from GitHub using Etag "W/\"54eea6bb1cf5f438654ec4e769f55b80\"" ...
2020/02/22 15:49:57 GitHub: 3852/5000 calls remaining; Reset in 23m32.142630856s
2020/02/22 15:49:57 Returning cached version of golang/go#37328
2020/02/22 15:49:57 Processing PR https://github.com/golang/go/pull/37328 ...
2020/02/22 15:49:57 Changes for PR golang/go#37328 have yet to be mirrored in the maintner corpus. Skipping for now.

So gerritbot thinks that the PR hasn't yet been mirrored in the maintner corpus.

But querying maintner directly, I can see that it has latest data. That PR description was never edited.

There's likely some sort of logic problem in gerritbot.

dmitshur

comment created time in 5 days

issue openedgolang/go

x/build/cmd/gerritbot: running into letsencrypt authorization rate limit

From gerritbot logs:

2020/02/22 15:50:23 Updating data from log *maintner.netMutSource ...
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: 429 urn:acme:error:rateLimited: Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:55:39 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate
2020/02/22 15:56:21 http: TLS handshake error from x.y.z.u:w: acme/autocert: missing certificate

That seems like something that shouldn't happen.

I don't know what the effect of this is. It may be harmless, or it may not be.

created time in 5 days

delete branch go-gl/glfw

delete branch : fix-travis

delete time in 6 days

push eventgo-gl/glfw

Dmitri Shuralyov

commit sha 6f7a984d4dc470c3f197229ad1991ae9e211bba2

.travis.yml: remove default travis_install_go_dependencies install step We have a custom implementation that we want to run instead of the default install step, so just run "true" which exits with 0 exit code. Having a command in addition to a comment wasn't needed to disable the default install step in the past, but for some reason, it is needed now. Reference: https://docs.travis-ci.com/user/languages/go/#dependency-management

view details

push time in 6 days

create barnchgo-gl/glfw

branch : fix-travis

created branch time in 6 days

pull request commentgo-gl/glfw

.travis.yml: use latest stable Go (1.13.8 and 1.12.17 at this time)

Hmm, Travis was passing in this PR, but now that it's merged to master, it's failing there.

For some reason, it's running travis_install_go_dependencies, which it's not supposed to be doing because of this line:

install:
  - # Do nothing. This is needed to prevent default install action "go get -t -v ./..." from happening here (we want it to happen inside script step).
dmitshur

comment created time in 6 days

delete branch go-gl/glfw

delete branch : update-travis

delete time in 6 days

push eventgo-gl/glfw

Dmitri Shuralyov

commit sha a998e75b09a89ddc3a83e8b6d7ab212570098965

.travis.yml: use latest stable Go (1.13.8 and 1.12.17 at this time) Go 1.11.x and 1.10.x are very old by now; update to current versions. Also resume testing v3.2/glfw package. It will be supported until it becomes too hard to support, then we'll say "please use v3.3 or newer". As of Go 1.12, go tool vet is no longer supported.¹ Start using the go vet command instead. Use RCS format for gofmt diff. It results in cleaner, easier to read gofmt diffs. ¹ https://golang.org/doc/go1.12#vet GitHub-Pull-Request: #270

view details

push time in 6 days

PR merged go-gl/glfw

.travis.yml: use latest stable Go (1.13.8 and 1.12.17 at this time)

Go 1.11.x and 1.10.x are very old by now; update to current versions.

Also resume testing v3.2/glfw package. It will be supported until it becomes too hard to support, then we'll say "please use v3.3 or newer".

As of Go 1.12, go tool vet is no longer supported.¹ Start using the go vet command instead.

Use RCS format for gofmt diff. It results in cleaner, easier to read gofmt diffs.

¹ https://golang.org/doc/go1.12#vet

+8 -8

6 comments

1 changed file

dmitshur

pr closed time in 6 days

Pull request review commentgo-gl/glfw

.travis.yml: use latest stable Go (1.13.8 and 1.12.17 at this time)

 addons:     - xorg-dev language: go go:-  - 1.11.x-  - 1.10.x-  - tip+  - 1.x+  - 1.12.x+  - master matrix:   allow_failures:-    - go: tip+    - go: master   fast_finish: true install:   - # Do nothing. This is needed to prevent default install action "go get -t -v ./..." from happening here (we want it to happen inside script step). script:-  - go get -t -v ./v3.3/...-  - diff -u <(echo -n) <(gofmt -d -s .)-  - go tool vet .-  - go test -v -race ./v3.3/...+  - go get -t -v ./v3.3/... ./v3.2/...+  - diff -n <(echo -n) <(gofmt -d -s .)+  - go vet ./v3.3/... ./v3.2/...+  - go test -v -race ./v3.3/... ./v3.2/...

Yes, it is still testing that the package builds successfully.

We don't have any tests, hence "[no test files]". If we add some, they'll be run.

dmitshur

comment created time in 6 days

issue commentshurcooL/githubv4

go get fails '...but does not contain package github.com/shurcooL/go/ctxhttp'

What's your go env GOPROXY value? Are you using a private proxy?

v0.0.0-20180223021221-8d3d310716de is an old version of module github.com/shurcooL/graphql. The latest version no longer imports package github.com/shurcooL/go/ctxhttp, see https://github.com/shurcooL/graphql/commit/16b88644589aaa174a21ae55cac72a9f60d5d837 from 2018.

klauern

comment created time in 6 days

issue closedgolang/go

x/build/env/linux-arm64/packet: 8 Packet linux/arm64 machines missing

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

Previously:

  • #35708
  • #35524
  • #32543
  • #31112
  • etc.

closed time in 6 days

dmitshur

issue commentgolang/go

x/build/env/linux-arm64/packet: 8 Packet linux/arm64 machines missing

sshing into the server timed out, but pinging it was fine.

I restarted it via Packet UI, that fixed it.

Similar to https://github.com/golang/go/issues/35708#issuecomment-555834390.

Another +1 to #32372.

dmitshur

comment created time in 6 days

issue openedgolang/go

x/build/env/linux-arm64/packet: 8 Packet linux/arm64 machines missing

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

Previously:

  • #35708
  • #35524
  • #32543
  • #31112
  • etc.

created time in 6 days

issue commentgolang/go

x/mobile: build failing when using go modules

@axet Please do. You can refer to this issue if any of the information here is relevant.

axet

comment created time in 6 days

delete branch go-gl/glfw

delete branch : update-to-3.3.2

delete time in 6 days

issue commentgolang/go

x/build: add check to trybot to catch src/go.mod and src/vendor divergence

That said, the test in CL 217218 seems to check for this issue too, does it not?

dmitshur

comment created time in 6 days

issue commentgolang/go

x/build: add check to trybot to catch src/go.mod and src/vendor divergence

Oh, I misread, this is about divergence between go.mod and vendor. That issue was about divergence between two different go.mods.

dmitshur

comment created time in 6 days

issue commentgolang/go

x/build: add check to trybot to catch src/go.mod and src/vendor divergence

@bcmills I think this issue is the same as issue #36907 (which was created slightly later), and can be considered resolved via CL 217218. Do you agree?

dmitshur

comment created time in 6 days

issue commentgolang/go

all: refresh contributor and authors files before releases

I've sent CL 220363 with the second, and final, round of updates for Go 1.14.

Moving this issue to the Go 1.15 milestone.

rsc

comment created time in 6 days

issue commentgolang/go

all: subrepos need to be green

This task has been completed for the Go 1.14 cycle at the time of cutting the go1.14rc1 release, see above comments for details.

Moving this issue to the Go 1.15 milestone.

rsc

comment created time in 6 days

issue commentgolang/go

x/blog: builds failing on release-branch.go1.12 due to missing dependencies

How does the builder set up the workspace?

Answered in person, but for posterity, the code is in buildStatus.runSubrepoTests of cmd/coordinator.

bcmills

comment created time in 7 days

more