Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: update standard-library dependencies at the start and end of each development cycle #36905

Open
bcmills opened this issue Jan 30, 2020 · 31 comments

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Jan 30, 2020

The x dependencies vendored into the standard library (via src/go.mod and src/cmd/go.mod) should be updated for each code freeze, so that we can apply any needed fixes to those dependencies without also pulling in unnecessary changes or requiring significant backporting work (see, for example, #36851).

This task, like #11811, #12042, and the API audit (#36167, #32813), should occur regularly in each development cycle. Probably we should update the dependencies at the beginning of each code freeze, and again when we reopen the tree at the end of each code freeze.

CC @golang/osp-team

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 3, 2020

Change https://golang.org/cl/217517 mentions this issue: all: update module dependencies

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Feb 19, 2020

This issue is currently labeled as early-in-cycle for Go 1.15. That time is now, so friendly ping.

gopherbot pushed a commit that referenced this issue Feb 19, 2020
Updates #36905
Updates #36907

Change-Id: I293dcef67800d5c81ff3a254bbd49309c5880710
Reviewed-on: https://go-review.googlesource.com/c/go/+/217517
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
@bcmills
Copy link
Member Author

@bcmills bcmills commented Feb 19, 2020

Completed the early-in-cycle update for the 1.15 cycle. Removing the label so we remember to revisit at the close of the cycle.

@gopherbot
Copy link

@gopherbot gopherbot commented May 1, 2020

Change https://golang.org/cl/231657 mentions this issue: all: update module dependencies

gopherbot pushed a commit that referenced this issue May 4, 2020
The Go 1.15 code freeze has just started. This is the time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.

Those versions have already gone through code review, and now they
will undergo additional testing during the freeze period.
If there are new issues in these dependencies discovered, we have
the freeze period to deal with that. By the end of the freeze period,
we will have confidence that the Go 1.15 release and the dependency
versions it has selected are robust.

If one of the Go 1.15.x minor releases requires changing code in one of
the vendored packages, we'll be able to do so on top of the versions
that are selected here, and not be forced to use versions that came
from different time periods, or try to jump across multiple untested
versions in a minor release.

The dependency versions that are selected in this commit are:

	github.com/google/pprof v0.0.0-20200229191704-1ebb73c60ed3
	github.com/ianlancetaylor/demangle v0.0.0-20200414190113-039b1ae3a340
	golang.org/x/arch v0.0.0-20200312215426-ff8b605520f4
	golang.org/x/crypto v0.0.0-20200429183012-4b2356b1ed79
	golang.org/x/mod v0.2.1-0.20200429172858-859b3ef565e2
	golang.org/x/net v0.0.0-20200501053045-e0ff5e5a1de5
	golang.org/x/sys v0.0.0-20200501145240-bc7a7d42d5c3
	golang.org/x/text v0.3.3-0.20200430171850-afb9336c4530
	golang.org/x/tools v0.0.0-20200504152539-33427f1b0364
	golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543

github.com/ianlancetaylor/demangle is considered in scope and updated.
github.com/google/pprof is out of scope and was not updated.

For #36905.

Change-Id: Icb6996eb0df11f16edd9a42e04434012c0336354
Reviewed-on: https://go-review.googlesource.com/c/go/+/231657
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented May 4, 2020

Completed the start-of-freeze update for the 1.15 cycle in CL 231657. Moving to 1.16 milestone and adding early-in-cycle.

@dmitshur dmitshur modified the milestones: Go1.15, Go1.16 May 4, 2020
@dmitshur dmitshur removed their assignment May 4, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented May 14, 2020

Change https://golang.org/cl/234002 mentions this issue: cmd: update golang.org/x/mod to v0.3.0 (same commit)

gopherbot pushed a commit that referenced this issue May 18, 2020
v0.3.0 is a tag on 859b3ef565e2, the version that was already being
used. This change is a no-op, except for letting us use a release
version instead of a pseudo-version.

For #36905

Change-Id: I70b8ce2a3f1451f5602c469501362d7a6a673b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/234002
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
xujianhai666 added a commit to xujianhai666/go-1 that referenced this issue May 21, 2020
The Go 1.15 code freeze has just started. This is the time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.

Those versions have already gone through code review, and now they
will undergo additional testing during the freeze period.
If there are new issues in these dependencies discovered, we have
the freeze period to deal with that. By the end of the freeze period,
we will have confidence that the Go 1.15 release and the dependency
versions it has selected are robust.

If one of the Go 1.15.x minor releases requires changing code in one of
the vendored packages, we'll be able to do so on top of the versions
that are selected here, and not be forced to use versions that came
from different time periods, or try to jump across multiple untested
versions in a minor release.

The dependency versions that are selected in this commit are:

	github.com/google/pprof v0.0.0-20200229191704-1ebb73c60ed3
	github.com/ianlancetaylor/demangle v0.0.0-20200414190113-039b1ae3a340
	golang.org/x/arch v0.0.0-20200312215426-ff8b605520f4
	golang.org/x/crypto v0.0.0-20200429183012-4b2356b1ed79
	golang.org/x/mod v0.2.1-0.20200429172858-859b3ef565e2
	golang.org/x/net v0.0.0-20200501053045-e0ff5e5a1de5
	golang.org/x/sys v0.0.0-20200501145240-bc7a7d42d5c3
	golang.org/x/text v0.3.3-0.20200430171850-afb9336c4530
	golang.org/x/tools v0.0.0-20200504152539-33427f1b0364
	golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543

github.com/ianlancetaylor/demangle is considered in scope and updated.
github.com/google/pprof is out of scope and was not updated.

For golang#36905.

Change-Id: Icb6996eb0df11f16edd9a42e04434012c0336354
Reviewed-on: https://go-review.googlesource.com/c/go/+/231657
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Aug 12, 2020

This issue is currently labeled as early-in-cycle for Go 1.16.
That time is now, so this is a friendly ping so the issue is looked at again.

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Sep 17, 2020

I'm creating a short program that performs this task. Using a program makes it easier to precisely define our update policy, and adjust it over time as needed. It also makes this task less error prone and easier to review. Finally, this can help with #41409 and #36852.

The policy I'm implementing right now is informed by the strategy we used in past manual CLs (e.g., CL 231657), with small adjustments. The policy is for all modules in the GOROOT/src directory (currently, std and cmd), update all direct (not indirect) modules with the import path prefix "golang.org/x/" to their latest tip pseudo-version (which can later become tagged as a release version).

The small adjustment is that the github.com/ianlancetaylor/demangle module won't be automatically updated as part of this process. My rationale is that it's different enough that it probably warrants being updated on its own schedule, when there is an explicit need. /cc @ianlancetaylor

Indirect golang.org/x dependencies are not updated, although they could be. I'm going with the more conservative choice for now. I'm open to feedback on this, and can see pros/cons to both strategies.

I've also considered but left out other modules in the GOROOT tree (e.g., GOROOT/misc) for now.

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Sep 17, 2020

Indirect golang.org/x dependencies are not updated, although they could be. I'm going with the more conservative choice for now. I'm open to feedback on this, and can see pros/cons to both strategies.

Looks like we did update indirect dependencies last time. If we don't, it leaves much fewer dependencies to update, because the go.mod files of golang.org/x modules aren't being updated very often.

Will think more about it and likely go with what we did last time as the next step here.

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 18, 2020

Change https://golang.org/cl/255859 mentions this issue: misc/update: add program to update golang.org/x dependencies

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 18, 2020

Change https://golang.org/cl/255860 mentions this issue: all: update vendored dependencies during Go 1.15 development

@dmitshur dmitshur changed the title all: update standard-library dependencies at the start and end of each code freeze all: update standard-library dependencies at the start and end of each development cycle Sep 18, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Sep 21, 2020

Change https://golang.org/cl/256357 mentions this issue: cmd/updatestd: add program to maintain standard library modules

@dmitshur dmitshur removed their assignment Sep 23, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 7, 2020

Change https://golang.org/cl/248499 mentions this issue: cmd/vendor,cmd/pprof: sync pprof@1a94d8640e99

gopherbot pushed a commit that referenced this issue Oct 7, 2020
Updated cmd/pprof.objTool.Disasm to accept
an additional bool param introduced in
google/pprof#520 to support
intel syntax in the assembly report.

Returns an error if the intelSyntax param is set. We use
src/cmd/internal/objfile to disassemble and print assembly
so I am not sure if it is relevant, and if so, how.

Fixes #38802
Updates #36905

Change-Id: Iae2b4322404f232196705f05210f00e2495588d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/248499
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 7, 2020

Change https://golang.org/cl/260538 mentions this issue: cmd/vendor: sync pprof@v0.0.0-20201007051231-1066cbb265c7

gopherbot pushed a commit that referenced this issue Oct 22, 2020
This is a belated early sync for 1.16 dev cycle

For #36905

Change-Id: I387528ae897794841c0c78b0f0910fc5ce8599ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/260538
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 31, 2020

Change https://golang.org/cl/266898 mentions this issue: all: update vendored dependencies for Go 1.16 release

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 2, 2020

Change https://golang.org/cl/267103 mentions this issue: all: update dependency on golang.org/x/sys and regenrate Windows syscalls

gopherbot pushed a commit that referenced this issue Nov 2, 2020
…calls

Steps run:

	$ cd $(go env GOROOT)/src
	$ go get -d golang.org/x/sys
	$ go mod tidy
	$ go mod vendor
	$ go generate syscall/... internal/syscall/...
	$ cd cmd
	$ go get -d golang.org/x/sys
	$ go mod tidy
	$ go mod vendor
	$ cd ..
	$ git add .

This change subsumes CL 260860.

For #36905

Change-Id: I7c677c6aa1ad61b9cbd8cf9ed208ed5a30f29c87
Reviewed-on: https://go-review.googlesource.com/c/go/+/267103
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 11, 2020

Change https://golang.org/cl/269118 mentions this issue: all: update vendored dependencies for Go 1.16 release (alt)

gopherbot pushed a commit that referenced this issue Nov 11, 2020
The Go 1.16 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.

Those versions have already gone through code review, and now they
will undergo additional testing during the upcoming freeze period.
If new issues in these dependencies are discovered, we have the freeze
period to address them. By the end of the freeze period, we will have
confidence that the Go 1.16 release and the dependency versions it has
selected are robust.

The dependency module versions that are selected in this commit are:

	github.com/google/pprof v0.0.0-20201007051231-1066cbb265c7
	github.com/ianlancetaylor/demangle v0.0.0-20200414190113-039b1ae3a340
	golang.org/x/arch v0.0.0-20201008161808-52c3e6f60cff
	golang.org/x/crypto v0.0.0-20201016220609-9e8e0b390897
	golang.org/x/mod v0.3.1-0.20200828183125-ce943fd02449
	golang.org/x/net v0.0.0-20201029221708-28c70e62bb1d
	golang.org/x/sys v0.0.0-20201110211018-35f3e6cf4a65
	golang.org/x/text v0.3.4
	golang.org/x/tools v0.0.0-20201110201400-7099162a900a
	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1

This change was created with a program from CL 256357 patch set 3
(which updates golang.org/x modules only) and the latest bundle tool,
but replacing golang.org/x/net version with a slightly older commit
golang/net@28c70e6 due to #42498:

	$ updatestd -goroot=$HOME/gotip -branch=master
	> go version
	go version devel +ecc3f5112e Thu Nov 5 23:21:33 2020 +0000 darwin/amd64
	> go env GOROOT
	/Users/dmitshur/gotip
	> go version -m /Users/dmitshur/go/bin/bundle
	/Users/dmitshur/go/bin/bundle: go1.15.4
		path	golang.org/x/tools/cmd/bundle
		mod	golang.org/x/tools	v0.0.0-20201110201400-7099162a900a	h1:5E6TPwSBG74zT8xSrVc8W59K4ch4NFobVTnh2BYzHyU=
		dep	golang.org/x/mod	v0.3.0	h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
		dep	golang.org/x/xerrors	v0.0.0-20200804184101-5ec99f83aff1	h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=

	updating module cmd in /Users/dmitshur/gotip/src/cmd
	skipping github.com/chzyer/logex (out of scope, it's not a golang.org/x dependency)
	skipping github.com/chzyer/readline (out of scope, it's not a golang.org/x dependency)
	skipping github.com/chzyer/test (out of scope, it's not a golang.org/x dependency)
	skipping github.com/google/pprof (out of scope, it's not a golang.org/x dependency)
	skipping github.com/ianlancetaylor/demangle (out of scope, it's not a golang.org/x dependency)
	skipping github.com/yuin/goldmark (out of scope, it's not a golang.org/x dependency)
	skipping rsc.io/pdf (out of scope, it's not a golang.org/x dependency)
	> go mod edit -go=1.16
	> go get -d golang.org/x/arch@52c3e6f60cffa0133a3f9b2fc7f6862504a6cba0 golang.org/x/crypto@9e8e0b390897c84cad53ebe9ed2d1d331a5394d9 golang.org/x/mod@ce943fd02449f621243c9ea6e64098e84752b92b golang.org/x/net@28c70e62bb1d140c3f2579fb7bb5095134d9cb1e golang.org/x/sync@67f06af15bc961c363a7260195bcd53487529a21 golang.org/x/sys@35f3e6cf4a65a85bc280e5fe63faed8ac8b25721 golang.org/x/text@22f1617af38ed4cd65b3b96e02bab267e560155c golang.org/x/tools@7099162a900ae8260c5b97cfaf5f374243dfa742 golang.org/x/xerrors@5ec99f83aff198f5fbd629d6c8d8eb38a04218ca
	> go mod tidy
	> go mod vendor

	updating module std in /Users/dmitshur/gotip/src
	> go mod edit -go=1.16
	> go get -d golang.org/x/crypto@9e8e0b390897c84cad53ebe9ed2d1d331a5394d9 golang.org/x/net@28c70e62bb1d140c3f2579fb7bb5095134d9cb1e golang.org/x/sys@35f3e6cf4a65a85bc280e5fe63faed8ac8b25721 golang.org/x/text@22f1617af38ed4cd65b3b96e02bab267e560155c golang.org/x/tools@7099162a900ae8260c5b97cfaf5f374243dfa742
	> go mod tidy
	> go mod vendor

	updating bundles in /Users/dmitshur/gotip/src
	> go generate -run=bundle std cmd

golang.org/x/net will be updated further later, after #42498 is fixed.

github.com/google/pprof and github.com/ianlancetaylor/demangle
contribute packages but are out of scope for this generated CL.

Also rename http2configureTransport in net/http to follow the internal
rename that happened in CL 264017 to fix the build.

For #36905.
Updates #41721.
Updates #42498.

Change-Id: Ifcd2e76f0406e389b6db88041ca51cd0a2115152
Reviewed-on: https://go-review.googlesource.com/c/go/+/266898
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Dec 4, 2020

Change https://golang.org/cl/275446 mentions this issue: all: update dependencies with changes in scope for Go 1.16 freeze

@zikaeroh
Copy link
Contributor

@zikaeroh zikaeroh commented Dec 4, 2020

@dmitshur Not sure this is the right place to ask, but do you know why pprof is getting skipped over in all of these dependency updates? I submitted a PR there before the freeze and was exited to see my fix show up in the next Go release, but the most recent update pulled an older version before my submission (and it's been skipped since).

@bcmills
Copy link
Member Author

@bcmills bcmills commented Dec 4, 2020

@zikaeroh, our automated scripts only pull in changes to the golang.org/x repos, since those are the only packages that are subject to the Go release cycle.

More generally, though: if you make a change that you want to have incorporated in a Go release (in an x/ repo or otherwise), you should also send a CL to update the go.mod file in the main repo as soon as the fix lands (or is released) upstream.

@zikaeroh
Copy link
Contributor

@zikaeroh zikaeroh commented Dec 4, 2020

I see. Is it too late now to update the vendored copy of pprof? I'm happy to submit a CL to do this (if that's easiest).

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Dec 4, 2020

@zikaeroh pprof was updated mostly recently for the Go 1.16 release in CL 248499 CL 260538. Are the changes which you'd like to pull in since then in scope of the Go 1.16 code freeze? It's too late for new features and risky changes, but if it's bug fixes then it may be in scope (depending on how risky they are).

@zikaeroh
Copy link
Contributor

@zikaeroh zikaeroh commented Dec 4, 2020

It was a fix for google/pprof#515, but I don't know if that qualifies as a bugfix or an enhancement. I can live with building pprof directly and not using go tool pprof if it's too risky.

I was just personally disappointed to see the update CL merged with a version a couple of weeks older than the submission date. I didn't comment at the time as I assumed that CL was a belated pull for the beginning of the cycle, and that there would be another pull for the end of the cycle (which didn't happen).

Note that the most recent pull was actually CL 260538 (which is why I assumed what I did via its commit message). CL 248499 came a few weeks before that.

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Dec 4, 2020

@zikaeroh That bug fix looks reasonable. Please feel free to send a CL updating it (similar to CL 260538), and make me and @hyangah its reviewers. We're still before beta 1, so if the changes look safe to land now, we'll do so (we can revert by beta 2 or RC 1 if it causes significant problems). If the changes look too invasive, it will need to wait for Go 1.17, unfortunately. This is a cost of having a 6 month release cycle—there will be changes that just don't quite make the cut and need to wait.

@gopherbot
Copy link

@gopherbot gopherbot commented Dec 4, 2020

Change https://golang.org/cl/275513 mentions this issue: cmd/vendor: sync pprof@v0.0.0-20201203190320-1bf35d6f28c2

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Dec 4, 2020

By now, the minimum required updates have been done at the end of the Go 1.16 development cycle (via CL 266898 and CL 260538). There are some more updates we need to pull in in order to fix known issues (e.g., issue #31192), but that's tracked by other issues.

Moving this recurring task to the next milestone (Go 1.17) and adding early-in-cycle label.

@dmitshur dmitshur modified the milestones: Go1.16, Go1.17 Dec 4, 2020
gopherbot pushed a commit that referenced this issue Dec 4, 2020
Pulls in a fix to make versioned import paths more readable in pprof's
graph view.

Updated via the instructions in README.vendor.

Updates #36905

Change-Id: I6a91de0f4ca1be3fc69d8e1a39ccf4f5bd0387ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/275513
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
gopherbot pushed a commit to golang/build that referenced this issue Jan 9, 2021
We need to update dependencies vendored into the standard library at
least two times during each major Go release cycle, which is tracked
by the recurring release-blocker issue golang.org/issue/36905.

Once we find agreement on the overall strategy to do this, it will be
easier, more reliable, and more scalable to do with a program than by
hand. This experimental program serves as a starting point to get there.
It has been used to generate CL 255860 and CL 266898 so far, and more
to explore the state of changes to vendored golang.org/x packages at
tip. Code review has identified opportunities for improvement, which
was filed as an issue. Upon further investigation, it was found that
those improvements are not viable to use in the short term (see
https://golang.org/issue/41589#issuecomment-712965746), but perhaps
will be worth revisiting in the future.

The scope of update performed at this time is to update golang.org/x
modules dependencies inside the standard library, re-run go generate
-run=bundle task, and update the Go language version in go.mod files.
It's expected this will evolve over time based on experience and new
findings.

For golang/go#36905.
For golang/go#41409.

Change-Id: I0e9d42675f1d8300f661545625f3b20e3704cdca
Reviewed-on: https://go-review.googlesource.com/c/build/+/256357
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Feb 24, 2021

This issue is currently labeled as early-in-cycle for Go 1.17.
That time is now, so a friendly reminder to look at it again.

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 5, 2021

Change https://golang.org/cl/298854 mentions this issue: all: update vendored dependencies for Go 1.17

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 13, 2021

Change https://golang.org/cl/296789 mentions this issue: all: update golang.org/x/* dependencies

gopherbot pushed a commit that referenced this issue Mar 15, 2021
Updates src/ and src/cmd/* dependencies, using

    go mod vendor

as well as

    updatestd -branch=master -goroot=$GOROOT

This change was ran in anticipation of bringing in x/net/http2 CL 237957.

For #32112.
For #36905.

Change-Id: If8cefc348463b6d82d85020b57db411213720ef8
Reviewed-on: https://go-review.googlesource.com/c/go/+/296789
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants