runtime/debug: allow JSON encoding of `BuildInfo`

[hyangah]

go1.18 added MarshalText and UnmarshalText methods for BuildInfo.
https://pkg.go.dev/runtime/debug@go1.18beta2#BuildInfo

This addition changed the behavior of this program.

package main

import (
	"encoding/json"
	"fmt"
	"runtime/debug"
)

func main() {
	info, _ := debug.ReadBuildInfo()
	b, _ := json.MarshalIndent(info, " ", " ")
	fmt.Printf("%s\n", b)
}

With go1.17

{
  "Path": "example",
  "Main": {
   "Path": "example",
   "Version": "(devel)",
   "Sum": "",
   "Replace": null
  },
  "Deps": null
 }

With go1.18

"go\tgo1.18beta2\npath\texample\nmod\texample\t(devel)\t\nbuild\t-compiler=gc\nbuild\t-gcflags=all=-N -l\nbuild\tCGO_ENABLED=1\nbuild\tCGO_CFLAGS=-O0 -g\nbuild\tCGO_CPPFLAGS=\nbuild\tCGO_CXXFLAGS=\nbuild\tCGO_LDFLAGS=\nbuild\tGOARCH=amd64\nbuild\tGOOS=darwin\nbuild\tGOAMD64=v1\n"

My proposal is either drop MarshalText/UnmarshalText (instead String/Parse, Encode/Decode?), or provide MarshalJSON/UnmarshalJSON so JSON encoding can encode in a form that tools written in other languages can access the info easily.

[gopherbot]

Change https://golang.org/cl/382274 mentions this issue: internal/lsp/debug: add go version to gopls version output

[ericlagergren]

At work we print this information as part of a diagnostics file.

type Diagnostics struct {
    BuildInfo *debug.BuildInfo
    [...]
}

func Write(w io.Writer) error {
    d := Diagnostics{ ... }
    buf, err := json.Marshal(d)
    [...]
}

We use JSON because it's easy for both humans and machines to parse. The new format makes the JSON output inscrutable for humans and breaks machine parsing. While there wasn't any guarantee that BuildInfo would always be representable as JSON, it doesn't seem an unreasonable request.

It would be nice if the fix could make it into 1.18.

cc: @jayconrod

[rsc]

Agree - we can't let the MarshalText break MarshalJSON. Probably we should just rename that method something else and let people call it as they need it. Will discuss with @bcmills and @matloob.

[bcmills]

It's unfortunate that MarshalText and UnmarshalText break JSON embedding, because semantically they're a perfect fit: these methods really are marshaling and unmarshaling the object into “a textual form”, and the signatures are more appropriate than String / Parse because the marshaling operation can fail (because field values that could collide with separators do not have escaping).

But maybe it would be better to add some form of escaping and switch to func (*BuildInfo) String() and debug.ParseBuildInfo.

[seankhliao]

BuildInfo could also implement MarshalJSON and UnmarshalJSON to get the json back, something like:

func (b BuildInfo) MarshalJSON() ([]byte, error) {
    type buildInfo BuildInfo // Mask out the methods
    return json.Marshal(buildInfo(b))
}

[bcmills]

It could, if it were in an ordinary package. Unfortunately, it is in runtime/debug, which cannot import encoding/json. 😞

So if we provided a MarshalJSON method it would probably have to be a bespoke implementation — and UnmarshalJSON in particular seems more complex than it's worth.

[Cyberax]

Perhaps a targeted hack in JSON marshaler will help?

[gopherbot]

Change https://go.dev/cl/384154 mentions this issue: runtime/debug: replace (*BuildInfo).Marshal methods with Parse and String

[gopherbot]

Change https://go.dev/cl/384161 mentions this issue: runtime/debug: expand fuzz corpus for FuzzParseBuildInfoRoundTrip