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

cmd/compile: failed to build github.com/hashicorp/cap/oidc due to internal compiler error: unexpected Defn: #45743

Closed
johejo opened this issue Apr 24, 2021 · 13 comments

Comments

@johejo
Copy link

@johejo johejo commented Apr 24, 2021

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

$ go version
go version devel go1.17-e7db792fc5 Fri Apr 23 22:31:20 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?

No, gotip only.

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/johejo/.cache/go-build"
GOENV="/home/johejo/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/johejo/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/johejo/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/johejo/ghq/github.com/golang/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/johejo/ghq/github.com/golang/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.17-e7db792fc5 Fri Apr 23 22:31:20 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/johejo/ghq/github.com/hashicorp/cap/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1677903244=/tmp/go-build -gno-record-gcc-switches"

What did you do?

git clone https://github.com/hashicorp/cap.git
cd cap/
gotip build ./...

What did you expect to see?

Build succeds

What did you see instead?

# github.com/hashicorp/cap/oidc
oidc/options.go:35:9: internal compiler error: unexpected Defn:
.   TYPESW Used # options.go:34
.   TYPESW-Tag
.   .   NONAME-oidc.v # options.go:34
.   .   NAME-oidc.o tc(1) Class:PPARAM Offset:0 OnStack Used INTER-interface {} # options.go:30

goroutine 1 [running]:
runtime/debug.Stack()
        /home/johejo/ghq/github.com/golang/go/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0x44c754, 0x0}, {0xd2be1a, 0xd136e0}, {0xc0007de650, 0xc0007de660, 0x1})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/base/print.go:227 +0x157
cmd/compile/internal/inline.(*inlsubst).clovar(0xc000115860, 0x0)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1198 +0x3c8
cmd/compile/internal/inline.(*inlsubst).closure(0xc000115860, 0xc00066afa0)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1257 +0x465
cmd/compile/internal/inline.(*inlsubst).node(0xc000115860, {0xe87a90, 0xc00066afa0})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1417 +0x3e5
cmd/compile/internal/ir.(*ConvExpr).editChildren(0xc000744000, 0xc00078c5b0)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:445 +0x58
cmd/compile/internal/ir.EditChildren(...)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/visit.go:185
cmd/compile/internal/inline.(*inlsubst).node(0xc000115860, {0xe87db0, 0xc00066af00})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1423 +0xacc
cmd/compile/internal/inline.(*inlsubst).list(0xc00066ae60, {0xc000683260, 0x1, 0xc0007dee50})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1133 +0xbe
cmd/compile/internal/inline.(*inlsubst).node(0xc000115860, {0xe89138, 0xc00066ae60})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1379 +0xdd0
cmd/compile/internal/inline.(*inlsubst).list(0xc00010f440, {0xc0006831d0, 0x1, 0xc0001466e0})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1133 +0xbe
cmd/compile/internal/inline.mkinlcall(0xe88c88, 0xc0003ac680, 0x5adaca, 0xc0006f54a0, 0x5c0e69)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1012 +0x21e8
cmd/compile/internal/inline.inlnode({0xe87838, 0xc00062fef0}, 0xe87450, 0xc0006361e0, 0x0)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:654 +0x586
cmd/compile/internal/inline.InlineCalls.func1({0xe87838, 0xc00062fef0})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:541 +0x31
cmd/compile/internal/ir.editNodes({0xc000449a40, 0x3, 0xc00063a000}, 0xc000498540)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:1449 +0x74
cmd/compile/internal/ir.(*CallExpr).editChildren(0xc00063a000, 0xc000498540)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:276 +0xb4
cmd/compile/internal/ir.EditChildren(...)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/visit.go:185
cmd/compile/internal/inline.inlnode({0xe87838, 0xc00063a000}, 0x6325a0, 0xc000636be0, 0xc000406d00)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:620 +0x2ac
cmd/compile/internal/inline.InlineCalls.func1({0xe87838, 0xc00063a000})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:541 +0x31
cmd/compile/internal/ir.editNodes({0xc000060f60, 0x1, 0xc000633020}, 0xc000498540)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:1449 +0x74
cmd/compile/internal/ir.(*AssignListStmt).editChildren(0xc000633020, 0xc000633020)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:108 +0x6e
cmd/compile/internal/ir.EditChildren(...)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/visit.go:185
cmd/compile/internal/inline.inlnode({0xe872c0, 0xc000633020}, 0x30, 0x7ffacd6e8c10, 0x20)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:620 +0x2ac
cmd/compile/internal/inline.InlineCalls.func1({0xe872c0, 0xc000633020})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:541 +0x31
cmd/compile/internal/ir.editNodes({0xc0000aae00, 0x1f, 0xcc6a40}, 0xc000498540)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:1449 +0x74
cmd/compile/internal/ir.(*Func).editChildren(0xe89138, 0xc000636c30)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/func.go:152 +0x2e
cmd/compile/internal/ir.EditChildren(...)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/visit.go:185
cmd/compile/internal/inline.InlineCalls(0xc000490e60)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:543 +0xf2
cmd/compile/internal/inline.InlinePackage.func1({0xc000490e60, 0x1, 0xc000147e40}, 0x0)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:71 +0x46
cmd/compile/internal/ir.(*bottomUpVisitor).visit(0xc0005ac3f0, 0xc0005b0c60)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/scc.go:128 +0x2e8
cmd/compile/internal/ir.VisitFuncsBottomUp({0xc000790000, 0x122, 0xb}, 0xd4e478)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/scc.go:60 +0x105
cmd/compile/internal/inline.InlinePackage()
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:58 +0x33
cmd/compile/internal/gc.Main(0xd4e348)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/gc/main.go:229 +0xc1b
main.main()
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/main.go:55 +0xdd
@johejo
Copy link
Author

@johejo johejo commented Apr 24, 2021

Small reproduction

package main

type opt func(interface{})

type a struct {
	s0 []string
	s1 []string
	f  func() t
}

type b struct {
	s0 []string
	s1 []string
	f  func() t
}

type t struct {
	wall uint64
	ext  int64
	t    *t
}

func fn(f func() t) opt {
	return func(o interface{}) {
		switch v := o.(type) {
		case *a:
			v.f = f
		case *b:
			v.f = f
		}
	}
}

func test(opt) {}

func main() {
	test(fn(func() t { return t{} }))
}
$ gotip tool compile ./main.go
./main.go:26:9: internal compiler error: unexpected Defn:
.   TYPESW Used # main.go:25
.   TYPESW-Tag
.   .   NONAME-main.v # main.go:25
.   .   NAME-main.o tc(1) Class:PPARAM Offset:0 OnStack Used INTER-interface {} # main.go:24

goroutine 1 [running]:
runtime/debug.Stack()
        /home/johejo/ghq/github.com/golang/go/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0x44c754, 0x0}, {0xd2be1a, 0xd136e0}, {0xc0000c4828, 0xc0000c4838, 0x1})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/base/print.go:227 +0x157
cmd/compile/internal/inline.(*inlsubst).clovar(0xc0000bca00, 0x0)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1198 +0x3c8
cmd/compile/internal/inline.(*inlsubst).closure(0xc0000bca00, 0xc000383c70)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1257 +0x465
cmd/compile/internal/inline.(*inlsubst).node(0xc0000bca00, {0xe87a90, 0xc000383c70})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1417 +0x3e5
cmd/compile/internal/ir.(*ConvExpr).editChildren(0xc000383f90, 0xc000096e10)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:445 +0x58
cmd/compile/internal/ir.EditChildren(...)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/visit.go:185
cmd/compile/internal/inline.(*inlsubst).node(0xc0000bca00, {0xe87db0, 0xc000383c20})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1423 +0xacc
cmd/compile/internal/inline.(*inlsubst).list(0xc000383bd0, {0xc000096b70, 0x1, 0xc0000c5028})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1133 +0xbe
cmd/compile/internal/inline.(*inlsubst).node(0xc0000bca00, {0xe89138, 0xc000383bd0})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1379 +0xdd0
cmd/compile/internal/inline.(*inlsubst).list(0xc0000b14c0, {0xc000096b50, 0x1, 0xc0000f02c0})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1133 +0xbe
cmd/compile/internal/inline.mkinlcall(0xe88c88, 0xc00037e8f0, 0x5adaca, 0xc00038a3f0, 0x5c0e69)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:1012 +0x21e8
cmd/compile/internal/inline.inlnode({0xe87838, 0xc0003143f0}, 0x5bd2e9, 0xc000382870, 0xc0000a48b8)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:654 +0x586
cmd/compile/internal/inline.InlineCalls.func1({0xe87838, 0xc0003143f0})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:541 +0x31
cmd/compile/internal/ir.editNodes({0xc0000969e0, 0x1, 0xc000314480}, 0xc0000b3480)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:1449 +0x74
cmd/compile/internal/ir.(*CallExpr).editChildren(0xc000314480, 0xc0000b3480)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:276 +0xb4
cmd/compile/internal/ir.EditChildren(...)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/visit.go:185
cmd/compile/internal/inline.inlnode({0xe87838, 0xc000314480}, 0x30, 0x7feefe68c4d0, 0x20)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:620 +0x2ac
cmd/compile/internal/inline.InlineCalls.func1({0xe87838, 0xc000314480})
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:541 +0x31
cmd/compile/internal/ir.editNodes({0xc000096a20, 0x1, 0xcc6a40}, 0xc0000b3480)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/node_gen.go:1449 +0x74
cmd/compile/internal/ir.(*Func).editChildren(0xe87838, 0xc000314480)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/func.go:152 +0x2e
cmd/compile/internal/ir.EditChildren(...)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/visit.go:185
cmd/compile/internal/inline.InlineCalls(0xc000096b10)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:543 +0xf2
cmd/compile/internal/inline.InlinePackage.func1({0xc000096b10, 0x2, 0xc0000f06e0}, 0x0)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:71 +0x46
cmd/compile/internal/ir.(*bottomUpVisitor).visit(0xc00038a180, 0xc0000c5c88)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/scc.go:128 +0x2e8
cmd/compile/internal/ir.VisitFuncsBottomUp({0xc00038c000, 0x9, 0xb}, 0xd4e478)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/ir/scc.go:60 +0x105
cmd/compile/internal/inline.InlinePackage()
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/inline/inl.go:58 +0x33
cmd/compile/internal/gc.Main(0xd4e348)
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/internal/gc/main.go:229 +0xc1b
main.main()
        /home/johejo/ghq/github.com/golang/go/src/cmd/compile/main.go:55 +0xdd

Loading

@ALTree
Copy link
Member

@ALTree ALTree commented Apr 24, 2021

Thanks for reporting this, and for the minimized reproducer.

I've bisected this to d310b2a.

cc @cuonglm @mdempsky

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 24, 2021

Change https://golang.org/cl/313289 mentions this issue: cmd/compile: fix inlining of closures with type switches

Loading

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Apr 24, 2021

Thanks for the test case and bisection. This was already incorrectly handled before d310b21, but that commit added additional internal checks which are failing on this test case.

It looks like we need to extend the AssignStmt/AssignListStmt rewriting to also handle SwitchStmt+TypeSwitchGuard. I uploaded a partial fix for this at golang.org/cl/313289, but I'm suspicious because it's finding switch variables with Defn == nil. That makes me suspect there are still more cases where variables within closures aren't being cloned correctly.

/cc @danscales

Loading

@danscales
Copy link

@danscales danscales commented Apr 26, 2021

@mdempsky I think that the non-setting of Defn is unrelated to closures. The nil value for Defn is happening for functions without any closures (for example, when inlining os.underlyingError). I debugged it a bit, and see that Defn is not being set at all in inlvar(), even if the input node var_ has var_.Defn set. So, when the name nodes for the per-case variables (named 'err' in the example of os.underlyingError) in the Dcl list are copied during inlining via inlvar, they are not getting their Defn set. Not quite sure why this isn't causing problems, or whether this glitch was a result of the big re-factoring.

Loading

@cuonglm
Copy link
Member

@cuonglm cuonglm commented Apr 26, 2021

@danscales is that also the reason we have the case nil: // ok for Defn in clovar?

Loading

@danscales
Copy link

@danscales danscales commented Apr 26, 2021

@cuonglm, Besides the possible bug in inlvar(), I think nameNode.Defn can be legitimately nil for param name nodes.

Loading

@cuonglm
Copy link
Member

@cuonglm cuonglm commented Apr 26, 2021

@danscales Hmm, I see for param name nodes, we always set its Defn in inlParam, what did I miss?

I see inlvar behavior seems correct, we don't want new node Defn point to the same Defn with old node, we want it point to the right node in inlined form (that's d310b2a for).

Loading

@danscales
Copy link

@danscales danscales commented Apr 26, 2021

Yes, but for parameters of normal functions (i.e. not in the process of being inlined), nameNode.Defn is not set (because there is no assignment to refer back to for a function input parameter).

Loading

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Apr 26, 2021

Defn can be legitimately nil for some variables, but it should always be set for variables declared in a type switch. It looks like this may be a preexisting issue with inlining, that inlvar just leaves Defn nil and it doesn't always get filled in later. That's really iffy to me, but it hasn't caused obvious problems, and it's probably too late to try to fix for this dev cycle.

Probably it's enough for now to just change clovar to recognize that *ir.TypeSwitchGuard is a valid type that n.Defn might have and leave m.Defn nil like we were doing before.

Loading

@gopherbot gopherbot closed this in 9f60169 Apr 26, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented May 13, 2021

Change https://golang.org/cl/319192 mentions this issue: cmd/compile: set correct Defn for type switch variable inside closure

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented May 13, 2021

Change https://golang.org/cl/319191 mentions this issue: cmd/compile: fill Defn for variable declared in type switch

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Jun 5, 2021

Change https://golang.org/cl/324573 mentions this issue: [dev.typeparams] cmd/compile: unified IR construction

Loading

gopherbot pushed a commit that referenced this issue Jun 15, 2021
This CL adds a new unified IR construction mode to the frontend.  It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.

See below for more details, but some highlights:

1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);

2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);

3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);

4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);

5. It supports lazy loading of types and objects for types2 type
checking;

6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;

7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;

8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.

--

The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:

1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.

2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.

3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").

4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.

These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.

For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.

By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:

1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.

2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.

Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@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
6 participants