2de7f9bf82
In the following piece of code:
type T1 struct {
Shadowed string `json:"foo"`
}
type T2 struct {
T1
Shadowing int `json:"foo"`
}
encoding/json will encode T2 using T2.Shadowing, ignoring T2.Shadowed
entirely. This can be a useful feature to replace some of T1's fields
when encoding it. Moreover, this feature is already in use in the wild,
even though it's probably never been documented.
This started being a problem, as the structtag pass started walking
through embedded fields a few months ago. To keep it from complaining
about these useful shadowing cases, make it only see duplicate field tag
names if they are at the same embedding level, in which case no
shadowing is happening.
The old code indexed these tags by encoding key and name, using a
[2]string. The new code needs to add a level integer, so start declaring
named types for the map, and use methods to simplify the code further
below. We still use a map pointer, to avoid allocating on every single
struct definition.
Updates golang/go#30846.
Change-Id: Iae53228d4f8bd91584c59dcc982cb1300970bc8f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/179360
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
||
|---|---|---|
| .. | ||
| asmdecl | ||
| assign | ||
| atomic | ||
| atomicalign | ||
| bools | ||
| buildssa | ||
| buildtag | ||
| cgocall | ||
| composite | ||
| copylock | ||
| ctrlflow | ||
| deepequalerrors | ||
| errorsas | ||
| findcall | ||
| httpresponse | ||
| inspect | ||
| internal/analysisutil | ||
| loopclosure | ||
| lostcancel | ||
| nilfunc | ||
| nilness | ||
| pkgfact | ||
| printf | ||
| shadow | ||
| shift | ||
| stdmethods | ||
| structtag | ||
| tests | ||
| unmarshal | ||
| unreachable | ||
| unsafeptr | ||
| unusedresult | ||
| README | ||
README
This directory does not contain a Go package, but acts as a container for various analyses that implement the golang.org/x/tools/go/analysis API and may be imported into an analysis tool. By convention, each package foo provides the analysis, and each command foo/cmd/foo provides a standalone driver.