cmd/go: go build -json #62067

aclements · 2023-08-16T13:34:21Z

(Edited 2024-01-18: Changed PackageID to ImportPath.)

I propose we add structured JSON output to go build, similar to and compatible with the structured JSON output of go test -json. This JSON output will be enabled by a new go build -json flag, and also implicitly enabled for all builds done on behalf of go test -json. This proposal aims to address #23037 and #35169, as well as improve structured all.bash output (#37486).

The main motivation for this proposal is to enable build output that is consistent and compatible with go test -json output. Currently, if a test or imported package fails to build during go test -json, the build error text will be interleaved with the JSON output of tests. Furthermore, there’s currently no way to reliably associate a build error with the test package or packages it affected. This creates unnecessary friction and complexity in tools that consume the go test -json output.

For reference, the go test -json format is as follow:

type TestEvent struct {
	Time    time.Time // encodes as an RFC3339-format string
	Action  string
	Package string
	Test    string
	Elapsed float64 // seconds
	Output  string
}

A detailed description can be found in go doc test2json.

Proposal

There are two related parts to this proposal.

I propose we add a -json flag to go build that suppresses the text build errors written to stderr and instead writes a JSON-encoded stream to stdout described by the following type:

type BuildEvent struct {
	ImportPath string
	Action     string
	Output     string `json:",omitempty"` // Non-empty if Action == “build-output”
}

The ImportPath field gives the package ID of the package being built. This matches the somewhat misnamed Package.ImportPath field of go list -json and what golang.org/x/tools/go/packages calls the “ID”. This differs from the TestEvent.Package field, which is a plain import path, but using the full package ID is important for disambiguating errors from different builds and for consistency with the rest of the build process.

The Action field is one of the following:

build-output - The toolchain printed output
build-fail - The build failed

The Output field is set for Action == "build-output" and is defined exactly the same way as the TestEvent.Output field. A single event may contain one or more lines of output and there may be more than one output event for a given package ID.

This struct is designed so that parsers can distinguish interleaved TestEvents and BuildEvents by inspecting the Action field. Furthermore, as with TestEvent, parsers can simply concatenate the Output fields of all events to reconstruct the text format output, as it would have appeared from go build without the -json flag. (As a consequence, this means the output includes all post-processing done by the go tool, including path rewriting and adding the “# package” header before each package.)

Environmental errors (e.g., bad GOOS values, file system errors) and module-level errors (e.g., syntax errors in go.mod) will still be printed in plain text to stderr by the go command. These errors cause an immediate exit and happen very early, so they should never appear with JSON output.

I propose we add an optional FailedBuild field to TestEvent to connect tests that fail because of build errors back to the build error. When a test fails due to a build error, the go command would emit the usual "start" event for the test package, then an "output" event giving the "FAIL package name [build failed]" or equivalent message, followed by a "fail" event with the new FailedBuild field set to the package ID of the package that failed to build.

This same approach can be used for setup failures as well, which print a "FAIL package name [setup failed]" message. Setup failures reflect errors that prevent the go command from even invoking the compiler, such as errors in imports, but they are still logically build failures.

This approach to reporting build failures that affect tests tries to balance several considerations:

A test may fail because of a build failure in an imported package. Thus, we can’t assume that the build failure is in the test package itself.
A view that narrows down a large test log to "why did this particular test fail?" (a common feature of CI systems) should be able to report the text of the build failure, even if it wasn't in the test package itself. Thus, we need some way to connect each failing test package back to the root build failure.
Multiple test packages may fail because of a build failure in one common imported package. Preferably, the details of the build failure would appear only once in the log, regardless of how many tests fail because of it.
Consumers must be able to concatenate the Output fields to recover the original text output. Hence, the current "FAIL" line has to appear in some output event. This also forces us to report the details of each build failure only once, since that’s how it appears in the text output.
CI systems should be able to correlate the same test package across test logs from different commits, even if the test package runs in some logs and doesn’t run because of build failures in others. Since TestEvents use package paths and BuildEvents use package IDs, that means the CI system needs some way to get the package path of the failing test. Preferably this can be done without parsing the package ID.
Sequential test order should still be recoverable from the log with build failures. Hence, the "start" TestEvents should still appear and be in order.

Example

Given a test package with a simple build error, currently go test -json emits the following:

# github.com/aclements/gotest/testdata/builderror [github.com/aclements/gotest/testdata/builderror.test]
./main_test.go:6:2: undefined: x
FAIL	github.com/aclements/gotest/testdata/builderror [build failed]

This is, in fact, identical to the output without the -json flag.

With the proposal, go test -json would instead print:

{"ImportPath":"github.com/aclements/gotest/testdata/builderror [github.com/aclements/gotest/testdata/builderror.test]","Action":"build-output","Output":"./main_test.go:6:2: undefined: x\n"}
{"ImportPath":"github.com/aclements/gotest/testdata/builderror [github.com/aclements/gotest/testdata/builderror.test]","Action":"build-fail"}
{"Time":"...","Action":"start","Package":"github.com/aclements/gotest/testdata/builderror"}
{"Time":"...","Action":"output","Package":"github.com/aclements/gotest/testdata/builderror","Output":"FAIL\tgithub.com/aclements/gotest/testdata/builderror [build failed]\n"}
{"Time":"...","Action":"fail","Package":"github.com/aclements/gotest/testdata/builderror","FailedBuild":"github.com/aclements/gotest/testdata/builderror [github.com/aclements/gotest/testdata/builderror.test]"}

Open issues and questions

Should we emit BuildEvents for successful package builds, like we emit TestEvents for passing tests? Those could include useful information like timing. If we think of this as akin to verbose output, do we emit start events, too? I did not include these in the proposal because they aren’t necessary to solve the immediate problems of processing go test -json output, but we could add these events in the future.

We could emit environmental and module-level errors in JSON. Above I proposed that these continue to be printed in text to stderr because they are fatal and happen before any build errors that would be printed in JSON, making them easy for tooling to process as text. From an implementation standpoint, there are also simply a huge number of possible causes for early, fatal errors, not all of which are even under the control of the go command, making it difficult to capture all of them. If we wanted to capture more errors, we would have to complicate BuildEvent to specify their sources, probably by making the Package field optional and adding an optional Module field. Module-level errors would populate the Module field and environmental errors would omit both fields. This all seems like unnecessary complexity.

BuildEvent.ImportPath and TestEvent.Package are defined slightly differently. There are good reasons for this (given above), and I chose different field names to help make this clear, but it may be confusing for consumers.

Finally, we could make the JSON build output much more structured, for example by encoding path and line information of errors as JSON fields. We chose to simply wrap the text output of the compiler because of the degree of variation in compiler output, including sub-errors and optional debug output.

The text was updated successfully, but these errors were encountered:

dmitshur · 2023-08-23T14:43:43Z

Thanks for the detailed proposal.

I noticed currently there's no discussion of exit codes here. It's a small detail, but still fairly important in that each future consumer of the JSON will need to process the exit code before they can begin to process JSON events. Perhaps the proposal is to inherit the same exit codes as go build currently emits when there's no -json flag, or for a custom exit code mapping when -json is on: possibly always 0 when valid JSON is successfully emitted, or non-zero in specific cases even when JSON is written successfully, or something else.

To use the existing go mod download -json behavior as an example: its CLI requires the caller to parse JSON both if exit code is 0 and 1. go mod download -json returns exit code 0 if there were no download errors in any modules, and exit code 1 if at least one module had a non-zero error. In both cases, it writes JSON to stdout. (See #35380 in general and #35380 (comment) in particular.)

(This is a comparatively minor detail, I hope not to distract too much from the more important aspects of the proposal.)

aclements · 2023-08-23T17:38:03Z

I noticed currently there's no discussion of exit codes here.

I wasn't planning on differing from the go command's current exit codes. And there could be JSON output even if it exits with 0. Certainly if there are build failures, there will be JSON output and a non-zero exit code. But, for example, if you pass certain debug flags to the compiler, it will emit output that should appear in JSON even on a successful build. Also, if we do decide to emit events on "successful" builds, as I mentioned in the "Open issues" section, that would also potentially emit JSON and then exit with a 0 status, so I certainly wouldn't want to lock us in to some rule about the relationship between the exit status and emitting JSON.

gopherbot · 2023-09-18T20:16:09Z

Change https://go.dev/cl/529120 mentions this issue: cmd/go: avoid writing non-JSON "build failed" errors from 'go test -json'

…son' In 'go test -json' we expect stdout to contain only JSON events, not unstructured text. Unstructured text should either go to stderr or be wrapped in a JSON event. (If we add structured build output in #62067, we can emit this output as a build event instead of a test event.) Fixes #35169. For #54378. Change-Id: Ibedd28e79b5adf8d6ae56165b9f0393b14ece9aa Reviewed-on: https://go-review.googlesource.com/c/go/+/529120 Reviewed-by: Austin Clements <austin@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

gopherbot · 2023-09-18T21:02:21Z

Change https://go.dev/cl/529220 mentions this issue: cmd/go: delete showOutput, formatOutput, and processOutput.

gopherbot · 2023-09-18T21:02:22Z

Change https://go.dev/cl/529218 mentions this issue: cmd/go: consolidate showOutput, formatOutput, and processOutput into reportCmd

gopherbot · 2023-09-18T21:02:23Z

Change https://go.dev/cl/529219 mentions this issue: cmd/go: replace formatOutput/showOutput with reportCmd

rsc · 2023-10-03T00:51:18Z

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

gopherbot · 2023-10-12T21:09:50Z

Change https://go.dev/cl/534857 mentions this issue: cmd/go: move fmtcmd's side effect to Showcmd

gopherbot · 2023-10-12T21:15:02Z

Change https://go.dev/cl/535016 mentions this issue: cmd/go: introduce Shell abstraction

gopherbot · 2023-10-17T20:04:30Z

Change https://go.dev/cl/536096 mentions this issue: cmd/go: drop unnecessary Package argument to reportCmd

gopherbot · 2023-10-17T20:04:31Z

Change https://go.dev/cl/536097 mentions this issue: cmd/go: replace mkdirCache with os.Stat

gopherbot · 2023-10-17T20:04:32Z

Change https://go.dev/cl/536098 mentions this issue: cmd/go: pass Action to showStdout

gopherbot · 2023-10-17T20:04:33Z

Change https://go.dev/cl/536095 mentions this issue: cmd/go: drop unnecessary Package arguments

…reportCmd Many uses of showOutput, formatOutput, and processOutput follow a very similar (somewhat complex) pattern. Places that diverge from this pattern are often minor bugs. Furthermore, the roles of formatOutput and processOutput have somewhat blurred over time; e.g., formatOutput performs directory shortening, while processOutput performs cgo demangling. This CL consolidates all of this logic into a single, new function: Builder.reportCmd. In the following CL, we'll replace all calls of the three original functions with reportCmd. In addition to being a nice cleanup, this puts us in a much better position to change how build output is formatted in order to support `go build -json`. For #62067. Change-Id: I733162825377d82d0015c8aae2820e56a1b32958 Reviewed-on: https://go-review.googlesource.com/c/go/+/529218 Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

The general pattern is to replace if len(cmdOut) > 0 { output := b.processOutput(cmdOut) if err != nil { err = formatOutput(b.WorkDir, dir, p.ImportPath, desc, output) } else { b.showOutput(a, dir, desc, output) } } if err != nil { return err } with if err := b.reportCmd(a, p, desc, dir, cmdOut, err); err != nil { return err } However, there is a fair amount of variation between call sites. The most common non-trivial variation is sites where errors are an expected outcome. In this case, often we simply pass "nil" for the error to trigger only the printing behavior of reportCmd. For #62067, but also a nice cleanup on its own. Change-Id: Ie5f918017c02d8558f23ad4c38261077c0fa4ea3 Reviewed-on: https://go-review.googlesource.com/c/go/+/529219 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com>

This functions have been replaced with Builder.reportCmd. For #62067. Change-Id: Ifeccee720b3da3dc44c49fe11da1eca7b5f46551 Reviewed-on: https://go-review.googlesource.com/c/go/+/529220 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com>

Currently, fmtcmd may have the side effect of updating Builder.scriptDir, the logical working directory of the printed script. If it does so, it also returns a two line command consisting of both a "cd" into the new scriptDir and the original command. When fmtcmd is used as part of Showcmd, that's fine, but fmtcmd is also used in a handful of places to construct command descriptions that are ultimately passed to Builder.reportCmd. In these cases, it's surprising that fmtcmd has any side effects, but the bigger problem is that reportCmd isn't expecting a two-line description and will print it wrong in the output. One option is to fix printing multi-line descriptions in reportCmd, but we can fix the surprise side effect too by instead moving the working directory update to Showcmd. With this CL, fmtcmd merely consults the working directory to shorten it in the output and does not update it. For #62067. Change-Id: I7808b279a430551f4ba51545417adf0bb132f931 Reviewed-on: https://go-review.googlesource.com/c/go/+/534857 Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Austin Clements <austin@google.com>

There are several functions that take both an Action argument and a Package argument. It takes a decent amount of work to determine that in all cases the value of the Package argument is just Action.Package. This makes these Package arguments both redundant and potentially confusing because it makes these APIs look like they have more flexibility than they actually do. Drop these unnecessary Package arguments. For #62067. Change-Id: Ibd3295cf6a79d95ceb421d60671f87e023517f8d Reviewed-on: https://go-review.googlesource.com/c/go/+/536095 Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Austin Clements <austin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

Now that we've dropped the redundant Package arguments to many functions, we can see that the Package argument to reportCmd is always nil. That means we can drop it and always use a.Package. For #62067. Change-Id: I2e11e770f495d6f770047993358c76b08204e923 Reviewed-on: https://go-review.googlesource.com/c/go/+/536096 Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

gopherbot · 2023-10-18T21:38:23Z

Change https://go.dev/cl/536397 mentions this issue: cmd/go: implement "go build -json"

gopherbot · 2023-10-18T21:38:25Z

Change https://go.dev/cl/536395 mentions this issue: cmd/go: add "-json" flag for go build

gopherbot · 2023-10-18T21:38:26Z

Change https://go.dev/cl/536399 mentions this issue: cmd/go: print build errors during go test -json in JSON

gopherbot · 2023-10-18T21:38:29Z

Change https://go.dev/cl/536398 mentions this issue: cmd/go: track root failing Action

gopherbot · 2023-10-18T21:38:30Z

Change https://go.dev/cl/536396 mentions this issue: cmd/go: add Printer interface

This CL separates running shell commands and doing shell-like operations out of the Builder type and into their own, new Shell type. Shell is responsible for tracking output streams and the Action that's running commands. Shells form a tree somewhat like Context, where new Shells can be derived from a root shell to adjust their state. The primary intent is to support "go build -json", where we need to flow the current package ID down to the lowest level of command output printing. Shell gives us a way to easily flow that context down. However, this also puts a clear boundary around how we run commands, removing this from the rather large Builder abstraction. For #62067. Change-Id: Ia9ab2a2d7cac0269ca627bbb316dbd9610bcda44 Reviewed-on: https://go-review.googlesource.com/c/go/+/535016 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Austin Clements <austin@google.com>

…reportCmd Many uses of showOutput, formatOutput, and processOutput follow a very similar (somewhat complex) pattern. Places that diverge from this pattern are often minor bugs. Furthermore, the roles of formatOutput and processOutput have somewhat blurred over time; e.g., formatOutput performs directory shortening, while processOutput performs cgo demangling. This CL consolidates all of this logic into a single, new function: Builder.reportCmd. In the following CL, we'll replace all calls of the three original functions with reportCmd. In addition to being a nice cleanup, this puts us in a much better position to change how build output is formatted in order to support `go build -json`. For golang#62067. Change-Id: I733162825377d82d0015c8aae2820e56a1b32958 Reviewed-on: https://go-review.googlesource.com/c/go/+/529218 Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

The general pattern is to replace if len(cmdOut) > 0 { output := b.processOutput(cmdOut) if err != nil { err = formatOutput(b.WorkDir, dir, p.ImportPath, desc, output) } else { b.showOutput(a, dir, desc, output) } } if err != nil { return err } with if err := b.reportCmd(a, p, desc, dir, cmdOut, err); err != nil { return err } However, there is a fair amount of variation between call sites. The most common non-trivial variation is sites where errors are an expected outcome. In this case, often we simply pass "nil" for the error to trigger only the printing behavior of reportCmd. For golang#62067, but also a nice cleanup on its own. Change-Id: Ie5f918017c02d8558f23ad4c38261077c0fa4ea3 Reviewed-on: https://go-review.googlesource.com/c/go/+/529219 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com>

This functions have been replaced with Builder.reportCmd. For golang#62067. Change-Id: Ifeccee720b3da3dc44c49fe11da1eca7b5f46551 Reviewed-on: https://go-review.googlesource.com/c/go/+/529220 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com>

Currently, fmtcmd may have the side effect of updating Builder.scriptDir, the logical working directory of the printed script. If it does so, it also returns a two line command consisting of both a "cd" into the new scriptDir and the original command. When fmtcmd is used as part of Showcmd, that's fine, but fmtcmd is also used in a handful of places to construct command descriptions that are ultimately passed to Builder.reportCmd. In these cases, it's surprising that fmtcmd has any side effects, but the bigger problem is that reportCmd isn't expecting a two-line description and will print it wrong in the output. One option is to fix printing multi-line descriptions in reportCmd, but we can fix the surprise side effect too by instead moving the working directory update to Showcmd. With this CL, fmtcmd merely consults the working directory to shorten it in the output and does not update it. For golang#62067. Change-Id: I7808b279a430551f4ba51545417adf0bb132f931 Reviewed-on: https://go-review.googlesource.com/c/go/+/534857 Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Austin Clements <austin@google.com>

There are several functions that take both an Action argument and a Package argument. It takes a decent amount of work to determine that in all cases the value of the Package argument is just Action.Package. This makes these Package arguments both redundant and potentially confusing because it makes these APIs look like they have more flexibility than they actually do. Drop these unnecessary Package arguments. For golang#62067. Change-Id: Ibd3295cf6a79d95ceb421d60671f87e023517f8d Reviewed-on: https://go-review.googlesource.com/c/go/+/536095 Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Austin Clements <austin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

Now that we've dropped the redundant Package arguments to many functions, we can see that the Package argument to reportCmd is always nil. That means we can drop it and always use a.Package. For golang#62067. Change-Id: I2e11e770f495d6f770047993358c76b08204e923 Reviewed-on: https://go-review.googlesource.com/c/go/+/536096 Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

This CL separates running shell commands and doing shell-like operations out of the Builder type and into their own, new Shell type. Shell is responsible for tracking output streams and the Action that's running commands. Shells form a tree somewhat like Context, where new Shells can be derived from a root shell to adjust their state. The primary intent is to support "go build -json", where we need to flow the current package ID down to the lowest level of command output printing. Shell gives us a way to easily flow that context down. However, this also puts a clear boundary around how we run commands, removing this from the rather large Builder abstraction. For golang#62067. Change-Id: Ia9ab2a2d7cac0269ca627bbb316dbd9610bcda44 Reviewed-on: https://go-review.googlesource.com/c/go/+/535016 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Austin Clements <austin@google.com>

rsc · 2023-10-24T15:54:28Z

Austin has prepared a stack of CLs and is now on leave. To move forward with the proposal I think we need someone to summarize the new JSON form.

aclements · 2023-12-29T00:30:37Z

To move forward with the proposal I think we need someone to summarize the new JSON form.

I'm slowly resurfacing from my leave and catching up. @rsc, what do you mean by "summarize the new JSON form"? I gave the types in the original proposal and a description of their meaning. Do you mean CLs that update the go command documentation? (If I recall correctly, that was the one thing I hadn't gotten to on the implementation side.)

rsc · 2024-01-10T18:04:37Z

It sounds like what is sketched in #62067 (comment) is what we ended up with.

PackageID should probably be renamed to ImportPath to match go list, even though it is unfortunate. Better to have one name for the thing than two. Otherwise it looks fine.

rsc · 2024-01-19T00:11:59Z

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

Proposal details in #62067 (comment)

rsc · 2024-01-26T02:51:02Z

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Proposal details in #62067 (comment)

gopherbot · 2024-01-29T00:41:41Z

Change https://go.dev/cl/558637 mentions this issue: cmd/go: report all loading errors in tests as "setup failed"

bcmills · 2024-02-08T20:58:12Z

PackageID should probably be renamed to ImportPath to match go list, even though it is unfortunate.

Compare:

proposal: cmd/go: include the raw import path in the output of go list -json #64193.

(But I don't think that changes this decision at all.)

aclements added the Proposal label Aug 16, 2023

gopherbot added this to the Proposal milestone Aug 16, 2023

seankhliao added the GoCommand cmd/go label Sep 10, 2023

aclements mentioned this issue Sep 20, 2023

cmd/go: add build -json, to report build failures in JSON #23037

Closed

rsc added the Proposal-FinalCommentPeriod label Jan 19, 2024

rsc changed the title ~~proposal: cmd/go: go build -json~~ cmd/go: go build -json Jan 26, 2024

rsc modified the milestones: Proposal, Backlog Jan 26, 2024

rsc added Proposal-Accepted and removed Proposal-FinalCommentPeriod labels Jan 26, 2024

aclements modified the milestones: Backlog, Go1.23 Jan 29, 2024

aclements self-assigned this Jan 29, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: go build -json #62067

cmd/go: go build -json #62067

aclements commented Aug 16, 2023 •

edited

dmitshur commented Aug 23, 2023 •

edited

aclements commented Aug 23, 2023

gopherbot commented Sep 18, 2023

gopherbot commented Sep 18, 2023

gopherbot commented Sep 18, 2023

gopherbot commented Sep 18, 2023

rsc commented Oct 3, 2023

gopherbot commented Oct 12, 2023

gopherbot commented Oct 12, 2023

gopherbot commented Oct 17, 2023

gopherbot commented Oct 17, 2023

gopherbot commented Oct 17, 2023

gopherbot commented Oct 17, 2023

gopherbot commented Oct 18, 2023

gopherbot commented Oct 18, 2023

gopherbot commented Oct 18, 2023

gopherbot commented Oct 18, 2023

gopherbot commented Oct 18, 2023

rsc commented Oct 24, 2023

aclements commented Dec 29, 2023

rsc commented Jan 10, 2024

rsc commented Jan 19, 2024

rsc commented Jan 26, 2024

gopherbot commented Jan 29, 2024

bcmills commented Feb 8, 2024

cmd/go: go build -json #62067

cmd/go: go build -json #62067

Comments

aclements commented Aug 16, 2023 • edited

Proposal

Example

Open issues and questions

dmitshur commented Aug 23, 2023 • edited

aclements commented Aug 23, 2023

gopherbot commented Sep 18, 2023

gopherbot commented Sep 18, 2023

gopherbot commented Sep 18, 2023

gopherbot commented Sep 18, 2023

rsc commented Oct 3, 2023

gopherbot commented Oct 12, 2023

gopherbot commented Oct 12, 2023

gopherbot commented Oct 17, 2023

gopherbot commented Oct 17, 2023

gopherbot commented Oct 17, 2023

gopherbot commented Oct 17, 2023

gopherbot commented Oct 18, 2023

gopherbot commented Oct 18, 2023

gopherbot commented Oct 18, 2023

gopherbot commented Oct 18, 2023

gopherbot commented Oct 18, 2023

rsc commented Oct 24, 2023

aclements commented Dec 29, 2023

rsc commented Jan 10, 2024

rsc commented Jan 19, 2024

rsc commented Jan 26, 2024

gopherbot commented Jan 29, 2024

bcmills commented Feb 8, 2024

aclements commented Aug 16, 2023 •

edited

dmitshur commented Aug 23, 2023 •

edited