For a type definition like `type I interface{ M() }`, the go/types API
traditionally sets `M`'s receiver parameter type to `I`, whereas
Unified IR was (intentionally) leaving it as `interface{ M() }`.
I still think `interface{ M() }` is the more consistent and
semantically correct type to use in this scenario, but I concede that
users want `I` instead, as evidenced by existing tooling and tests.
Updates #49906.
Change-Id: I74ba5e8b08e4e98ed9dc49f72b7834d5b552058b
Reviewed-on: https://go-review.googlesource.com/c/go/+/421355
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Merge List:
+ 2022-08-04 85d87b9c75 all: update vendored golang.org/x dependencies for Go 1.20 development
+ 2022-08-04 fb1bfd4d37 all: remove pre-Go 1.17 workarounds
+ 2022-08-04 44ff9bff0c runtime: clean up panic and deadlock lock ranks
+ 2022-08-04 f42dc0de74 runtime: make the lock rank DAG make more sense
+ 2022-08-04 d29a0282e9 runtime: add mayAcquire annotation for finlock
+ 2022-08-04 c5be4ed7df runtime: add missing trace lock edges
+ 2022-08-04 2b8a9a484f runtime: generate the lock ranking from a DAG description
+ 2022-08-04 ddfd639408 runtime: delete unused lock ranks
+ 2022-08-04 426ea5702b internal/dag: add a Graph type and make node order deterministic
+ 2022-08-04 d37cc9a8cd go/build, internal/dag: lift DAG parser into an internal package
+ 2022-08-04 ab0a94c6d3 cmd/dist: require Go 1.17 for building Go
+ 2022-08-04 1e3c19f3fe runtime: support riscv64 SV57 mode
+ 2022-08-03 f28fa952b5 make.bat, make.rc: show bootstrap toolchain version
+ 2022-08-03 87384801dc cmd/asm: update package doc to describe "-p" option
+ 2022-08-03 c6a2dada0d net: disable TestIPv6WriteMsgUDPAddrPortTargetAddrIPVersion [sic] on DragonflyBSD
+ 2022-08-02 29b9a328d2 runtime: trivial replacements of g in remaining files
+ 2022-08-02 c647264619 runtime: trivial replacements of g in signal_unix.go
+ 2022-08-02 399f50c9d7 runtime: tricky replacements of g in traceback.go
+ 2022-08-02 4509e951ec runtime: tricky replacements of g in proc.go
+ 2022-08-02 4400238ec8 runtime: trivial replacements of _g_ in remaining files
+ 2022-08-02 5999a28de8 runtime: trivial replacements of _g_ in os files
+ 2022-08-02 0e18cf6d09 runtime: trivial replacements of _g_ in GC files
+ 2022-08-02 4358a53a97 runtime: trivial replacements of _g_ in proc.go
+ 2022-08-02 b486518964 runtime: tricky replacements of _g_ in os3_solaris.go
+ 2022-08-02 54a0ab3f7b runtime: tricky replacements of _g_ in os3_plan9.go
+ 2022-08-02 4240ff764b runtime: tricky replacements of _g_ in signal_windows.go
+ 2022-08-02 8666d89ca8 runtime: tricky replacements of _g_ in signal_unix.go
+ 2022-08-02 74cee276fe runtime: tricky replacements of _g_ in trace.go
+ 2022-08-02 222799fde6 runtime: tricky replacements of _g_ in mgc.go
+ 2022-08-02 e9d7f54a1a runtime: tricky replacements of _g_ in proc.go
+ 2022-08-02 5e8d261918 runtime: rename _p_ to pp
+ 2022-08-02 0ad2ec6596 runtime: clean up dopanic_m
+ 2022-08-02 7e952962df runtime: clean up canpanic
+ 2022-08-02 9dbc0f3556 runtime: fix outdated g.m comment in traceback.go
+ 2022-08-02 d723df76da internal/goversion: update Version to 1.20
+ 2022-08-02 1b7e71e8ae all: disable tests that fail on Alpine
+ 2022-08-01 f2a9f3e2e0 test: improve generic type assertion test
+ 2022-08-01 27038b70f8 cmd/compile: fix wrong dict pass condition for type assertions
+ 2022-08-01 e99f53fed9 doc: move Go 1.19 release notes to x/website
+ 2022-08-01 8b13a073a1 doc: mention removal of cmd/compile's -importmap and -installsuffix flags
+ 2022-08-01 e95fd4c238 doc/go1.19: fix typo: EM_LONGARCH -> EM_LOONGARCH
+ 2022-08-01 dee3efd9f8 doc/go1.19: fix a few links that were missing trailing slashes
+ 2022-07-30 f32519e5fb runtime: fix typos
+ 2022-07-29 9a2001a8cc cmd/dist: always pass -short=true with -quick
+ 2022-07-28 5c8ec89cb5 doc/go1.19: minor adjustments and links
+ 2022-07-28 417be37048 doc/go1.19: improve the loong64 release notes
+ 2022-07-28 027855e8d8 os/exec: add GODEBUG setting to opt out of ErrDot changes
Change-Id: Idc0fbe93978c0dff7600b90a2c3ecc067fd9f5f2
Go 1.20 development is just beginning. 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.
This CL holds back some of the available updates to the x/net module
due to go.dev/issue/54259. It'll be updated in a later separate pass.
x/tools is also held back a bit to avoid pulling in too new of x/net.
For #36905.
For #53812.
Updates #54259.
Change-Id: Iaefe6a343a02cc5ceb85c15125882d64dd372627
Reviewed-on: https://go-review.googlesource.com/c/go/+/421334
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
The Go bootstrap toolchain requirement is now Go 1.17.
We can finally delete all these pre-Go 1.17 workarounds.
For #44505.
Change-Id: I59d4dff1cde23da022892b5b6a116eb3dbad9ce4
Reviewed-on: https://go-review.googlesource.com/c/go/+/420903
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
I'm not entirely sure why these locks are currently ranked "deadlock <
panic" since we drop panic before acquiring deadlock, and we actually
want deadlock to be below panic because panic is implicitly below
everything else and we want deadlock to be, too. My best guess is that
we had this edge because we intentionally acquire deadlock twice to
deadlock, and that causes the lock rank checking to panic on the
second acquire.
Fix this in a more sensible way by capturing that deadlock can be
acquired in a self-cycle and flipping the rank to "panic < deadlock"
to express that deadlock needs to be under all other locks, just like
panic.
For #53789.
Change-Id: I8809e5d102ce473bd3ace0ba07bf2200ef60263f
Reviewed-on: https://go-review.googlesource.com/c/go/+/418719
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
This groups, comments, and generally reorganizes the lock rank graph
description by subsystem. It also introduces several pseudo-nodes that
more cleanly describe the inherent layering of lock ranks by
subsystem.
I believe this doesn't actually change the graph, but haven't verified
this.
For #53789.
Change-Id: I72f332f5a23b8217c7dc1b21411631ad48cee4b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/418718
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
We're missing lock edges to finlock that happen only rarely. Anything
that calls mallocgc can potentially trigger sweeping, which can
potentially queue a finalizer, which acquires finlock. While this can
happen on any malloc, it happens relatively rarely, so we simply
haven't seen some of the lock edges that could happen.
Add a mayAcquire annotation to mallocgc to capture the possibility of
acquiring finlock.
With this change, we add "fin" to the set of "malloc" locks. Several
of these edges were already there, but not quite all of them.
This was found by inspecting the rank graph for things that didn't
make sense.
For #53789.
Change-Id: Idc10ce6f250596b0c07ba07ac93f2198fb38c22b
Reviewed-on: https://go-review.googlesource.com/c/go/+/418717
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're missing lock edges to trace.lock that happen only rarely. Any
trace event can potentially fill up a trace buffer and acquire
trace.lock in order to flush the buffer, but this happens relatively
rarely, so we simply haven't seen some of these lock edges that could
happen.
With this change, we promote "fin, notifyList < traceStackTab" to
"fin, notifyList < trace" and now everything that emits trace events
with a P enters the tracer lock ranks via "trace", rather than some
things entering at "trace" and others at "traceStackTab".
This was found by inspecting the rank graph for things that didn't
make sense.
Ideally we would add a mayAcquire annotation that any trace event can
potentially acquire trace.lock, but there are actually cases that
violate this ranking right now. This is #53979. The chance of a lock
cycle is extremely low given the number of conditions that have to
happen simultaneously.
For #53789.
Change-Id: Ic65947d27dee88d2daf639b21b2c9d37552f0ac0
Reviewed-on: https://go-review.googlesource.com/c/go/+/418716
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, the runtime lock rank graph is maintained manually in a
large set of arrays that give the partial order and a manual
topological sort of this partial order. Any changes to the rank graph
are difficult to reason about and hard to review, as well as likely to
cause merge conflicts. Furthermore, because the partial order is
manually maintained, it's not actually transitively closed (though
it's close), meaning there are many cases where rank a can be acquired
before b and b before c, but a cannot be acquired before c. While this
isn't technically wrong, it's very strange in the context of lock
ordering.
Replace all of this with a much more compact, readable, and
maintainable description of the rank graph written in the internal/dag
graph language. We statically generate the runtime structures from
this description, which has the advantage that the parser doesn't have
to run during runtime initialization and the structures can live in
static data where they can be accessed from any point during runtime
init.
The current description was automatically generated from the existing
partial order, combined with a transitive reduction. This ensures it's
correct, but it could use some manual messaging to call out the
logical layers and add some structure.
We do lose the ad hoc string names of the lock ranks in this
translation, which could mostly be derived from the rank constant
names, but not always. I may bring those back but in a more uniform
way.
We no longer need the tests in lockrank_test.go because they were
checking that we manually maintained the structures correctly.
Fixes#53789.
Change-Id: I54451d561b22e61150aff7e9b8602ba9737e1b9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/418715
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The go/types package doesn't care about node ordering because it's
just querying paths in the graph, but we're about to use this for the
runtime lock graph, and there we want determinism.
For #53789.
Change-Id: Ic41329bf2eb9a3a202f97c21c761ea588ca551c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/418593
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
This lifts the DAG parser from the go/build dependencies test into its
own package that can be reused elsewhere.
I tried to keep the code as close as possible. I changed some names to
reflect the more general purpose of internal/dag. Most of the changes
are related to error handling, since internal/dag doesn't take a
testing.T on which to report errors. Notably, parseRules now returns a
slice of parsed rules rather than calling a callback because this made
it easier to separate fatal parsing errors from non-fatal graph
checking errors.
For #53789.
Change-Id: I170b84fd85f971cfc1a50972156d48e78b45fce3
Reviewed-on: https://go-review.googlesource.com/c/go/+/418592
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This makes builds using earlier Go bootstrap versions fail pretty clearly:
% GOROOT_BOOTSTRAP=$HOME/sdk/go1.16 ./make.bash
Building Go cmd/dist using /Users/rsc/sdk/go1.16. (go1.16 darwin/amd64)
found packages main (build.go) and building_Go_requires_Go_1_17_or_later (notgo117.go) in /Users/rsc/go/src/cmd/dist
%
All the builders have Go 1.17 or later for bootstrap now except
for the android corellium builders, which still need updating (#54246).
We are accepting breakage on those for now.
Fixes#44505.
Change-Id: I12a67f42f61dba43a331cee0a150194d3e42c044
Reviewed-on: https://go-review.googlesource.com/c/go/+/420902
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
riscv64 has SV57 mode when user-space VA is 56 bits.
Linux kernel recently got support for this mode and Go binaries started crashing as:
runtime: lfstack.push invalid packing: node=0xffffff5908a940 cnt=0x1
packed=0xffff5908a9400001 -> node=0xffff5908a940
Adjust lfstack code to use only 8 top bits of pointers on riscv64.
For context see:
https://groups.google.com/g/syzkaller-bugs/c/lU0GQTZoNQQ/m/O_c3vmE3AAAJ
Update #54104
Change-Id: Ib5d3d6a79c0c6eddf11618d73fcc8bc1832a9c25
Reviewed-on: https://go-review.googlesource.com/c/go/+/409055
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Print the bootstrap toolchain version on Plan 9 and Windows,
same as on all Unix systems since CL 204757 (Nov 2019).
This makes it easier to see what is going on in a build.
For #44505.
Change-Id: I50cdd5e15a7c8b908e33e92780f8a3bca65c91ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/419452
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Include a description of the assembler's "-p" command line option
in the package doc.
Fixes#54215.
Change-Id: I641abad573c37aa9447af6e8b84716093c2a2b70
Reviewed-on: https://go-review.googlesource.com/c/go/+/420900
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
This CL switches unified IR to start using runtime dictionaries,
rather than pure stenciling. In particular, for each instantiated
function `F[T]`, it now:
1. Generates a global variable `F[T]-dict` of type `[N]uintptr`, with
all of the `*runtime._type` values needed by `F[T]`.
2. Generates a function `F[T]-shaped`, with an extra
`.dict *[N]uintptr` parameter and indexing into that parameter for
derived types. (N.B., this function is not yet actually using shape
types.)
3. Changes `F[T]` to instead be a wrapper function that calls
`F[T]-shaped` passing `&F[T]-dict` as the `.dict` parameter.
This is done in one pass to make sure the overall wiring is all
working (especially, function literals and inlining).
Subsequent CLs will write more information into `F[T]-dict` and update
`F[T]-shaped` to use it instead of relying on `T`-derived information
itself. Once that's done, `F[T]-shaped` can be changed to
`F[shapify(T)]` (e.g., `F[go.shape.int]`) and deduplicated.
Change-Id: I0e802a4d9934794e01a6bfc367820af893335155
Reviewed-on: https://go-review.googlesource.com/c/go/+/420416
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Like OpenBSD, DragonflyBSD does not do IPv4-in-IPv6 mapping.
For #52264.
Change-Id: Id41606e75652e684f2e0e98c6459156641aec9b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/420775
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rename g variables to gp for consistency.
Change-Id: I09ecdc7e8439637bc0e32f9c5f96f515e6436362
Reviewed-on: https://go-review.googlesource.com/c/go/+/418591
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
sighandler has gp, the goroutine running when the signal arrived, and
gsignal, the goroutine executing the signal handler. The latter is
usually mp.gsignal, except in the case noted by the delayedSignal check.
Like previous CLs, cases where the getg() G is used only to access the M
are replaced with direct uses of mp.
Change-Id: I2dc7894da7004af17682712e07a0be5f9a235d81
Reviewed-on: https://go-review.googlesource.com/c/go/+/418580
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Like previous CLs, cases where the getg() G is used only to access the M
are replaced with direct uses of mp.
Change-Id: I4740c80d6b4997d051a52afcfa8c087e0317dab3
Reviewed-on: https://go-review.googlesource.com/c/go/+/418579
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
getg() is used primarily for gp.m, so use mp. gp.m.curg is also used,
name that curgp.
Change-Id: I9db2dc4adce2b17d6b41c60d4f2dfbc9aa41fac1
Reviewed-on: https://go-review.googlesource.com/c/go/+/418578
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This manually replaces uses of _g_ that cannot be trivially switched to
gp since there is another gp variable in scope.
Most of these functions only use the current g to reach the m, so this
helps with clarity by switching all accesses directly to an mp variable.
Change-Id: I96a4fc1c32470a7f3d12ddec9f147c2743210e71
Reviewed-on: https://go-review.googlesource.com/c/go/+/418577
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
_g_, _p_, and _m_ are primarily vestiges of the C version of the
runtime, while today we prefer Go-style variable names (generally gp,
pp, and mp).
This change replaces all remaining uses of _p_ with pp. These are all
trivial replacements (i.e., no conflicts). That said, there are several
functions that refer to two different Ps at once. There the naming
convention is generally that pp refers to the local P, and p2 refers to
the other P we are accessing.
Change-Id: I205b801be839216972e7644b1fbeacdbf2612859
Reviewed-on: https://go-review.googlesource.com/c/go/+/306674
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gp is a user G running on the same M as getg(), so it is a fine proxy
for gp.m.
Change-Id: I9aa1dd283ecf28878eeedd7da4ded5c901809832
Reviewed-on: https://go-review.googlesource.com/c/go/+/418576
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
* The gp argument to canpanic is always equivalent to getg(), so no need
to pass it at all.
* gp must not be nil or _g_.m would have crashed, so no need to check
for nil.
* Use acquirem to better reason about preemption.
Change-Id: Ic7dc8dc1e56ab4c1644965f6aeba16807cdb2df4
Reviewed-on: https://go-review.googlesource.com/c/go/+/418575
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
This is the start of the Go 1.20 development cycle, so update the
Version value accordingly. It represents the Go 1.x version that
will soon open up for development (and eventually become released).
For #40705.
For #53812.
Change-Id: Ic8919a61c9b2f3139717434b9c776d1597175448
Reviewed-on: https://go-review.googlesource.com/c/go/+/420816
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
These changes are enough to pass all.bash using the
disabled linux-amd64-alpine builder via debugnewvm.
For #19938.
For #39857.
Change-Id: I7d160612259c77764b70d429ad94f0864689cdce
Reviewed-on: https://go-review.googlesource.com/c/go/+/419995
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The test added in CL 420394 only tested that the type assertions
compiled at all. This CL changes it into a run test to make sure the
type assertions compile and also run correctly.
Updates #54135.
Change-Id: Id17469faad1bb55ff79b0bb4163ef50179330033
Reviewed-on: https://go-review.googlesource.com/c/go/+/420421
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Fixes#54135
Change-Id: I2b27af8124014b2699ea44bdc765e1fb8f6c8028
Reviewed-on: https://go-review.googlesource.com/c/go/+/420394
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Now that the development of the Go 1.19 release is almost done, its
release notes are moved to their eventual long-term home in x/website
in CL 420417. Delete the initial development copy here.
For golang/go#51400.
Change-Id: I741285555af28ce9a64e7f8d2b9fe2a0f3e13c26
Reviewed-on: https://go-review.googlesource.com/c/go/+/420418
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Another last-minute fix. The whole repo is checked case-insensitively
against "longarch" and this is the only occurrence.
Change-Id: If13c123c1e44001a346f1df1df9d839c699703b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/420494
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
They were part of a chain of three redirects. Now it's only two,
but that's #54081.
Change-Id: Ibfe6a17a372df61df40124892951b48577e4ced9
Reviewed-on: https://go-review.googlesource.com/c/go/+/419634
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I30c125be6cb321aa03ea827bd11c3169087e3d4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/420314
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
This problem appeared in google-internal testing.
If the run-later functions are run in the wrong order,
type definitions won't resolve properly.
Change-Id: I9da0775976282e92ca036d20fd9fd6650900daf9
Reviewed-on: https://go-review.googlesource.com/c/go/+/419996
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Fixes#53818
Change-Id: I190a8bcf50d92b9c10e9980e630ebb362d8b19ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/417918
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
