The check for duplicate struct field tags introduced in CL 16704
triggers a panic when an anonymous struct field with a duplicate name
is encountered. For such a field, the names slice of the ast.Field is
nil but accessed regardless to generate the warning message.
Additionally, the check produces false positives for XML tags in some
cases:
- When fields are encoded as XML attributes, a warning is produced when
an attribute reuses a name previously used for an element.
Example:
type Foo struct {
First int `xml:"a"`
NoDup int `xml:"a,attr"` // warning about reuse of "a"
}
- When XMLName is used to set the name of the enclosing struct element,
it is treated as a regular struct field.
Example:
type Bar struct {
XMLName xml.Name `xml:"a"`
NoDup int `xml:"a"` // warning about reuse of "a"
}
This commit addresses all three issues. The panic is avoided by using
the type name instead of the field name for anonymous struct fields when
generating the warning message. An additional namespace for checking XML
attribute names separately from element names is introduced. Lastly,
fields named XMLName are excluded from the check for duplicate tags.
Updates #18256
Change-Id: Ida48ea8584b56bd4d12ae3ebd588a66ced2594cc
Reviewed-on: https://go-review.googlesource.com/34070
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The test for the race detector itself had a race of a sort not
detected by the race detector.
Fixes#18286.
Change-Id: I3265eae275aaa2869a6b6d3e8675b0d88b25831b
Reviewed-on: https://go-review.googlesource.com/34287
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
And move some code to make control flow more obvious.
No functional change.
Change-Id: Iefaa96f664070ab2accade1857e1946e56df6902
Reviewed-on: https://go-review.googlesource.com/34285
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For the 1.8 release, go back to invoking the assembler once per .s
file, to avoid the problem in #18225. When the assembler is fixed, the
change to cmd/go/build.go can be rolled back, but the test in
cmd/go/go_test.go should remain.
Fixes#18225.
Update #15680.
Change-Id: Ibff8d0c638536efb50a2b2c280b41399332f4fe4
Reviewed-on: https://go-review.googlesource.com/34284
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is the simplest CL that I can make for Go 1.8. For Go 1.9, we can revisit it
and optimize the redundant address generation instructions or just fix#599 instead.
Fixes#18140.
Change-Id: Ie4804ab0e00dc6bb318da2bece8035c7c71caac3
Reviewed-on: https://go-review.googlesource.com/34193
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Also, if we changed the gsignal stack to match the stack we are
executing on, restore it when returning from the signal handler, for
safety.
Fixes#18255.
Change-Id: Ic289b36e4e38a56f8a6d4b5d74f68121c242e81a
Reviewed-on: https://go-review.googlesource.com/34239
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Change the openbsd runtime to use the current sys_kill and sys_thrkill
system calls.
Prior to OpenBSD 5.9 the sys_kill system call could be used with both
processes and threads. In OpenBSD 5.9 this functionality was split into
a sys_kill system call for processes (with a new syscall number) and a
sys_thrkill system call for threads. The original/legacy system call was
retained in OpenBSD 5.9 and OpenBSD 6.0, however has been removed and
will not exist in the upcoming OpenBSD 6.1 release.
Note: This change is needed to make Go work on OpenBSD 6.1 (to be
released in May 2017) and should be included in the Go 1.8 release.
This change also drops support for OpenBSD 5.8, which is already an
unsupported OpenBSD release.
Change-Id: I525ed9b57c66c0c6f438dfa32feb29c7eefc72b0
Reviewed-on: https://go-review.googlesource.com/34093
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The pclntable contains pointers to functions. If the function symbol
is exported in a plugin, and there is a matching symbol in the host
binary, then the pclntable of a plugin ends up pointing at the
function in the host module.
This doesn't work because the traceback code expects the pointer to
be in the same module space as the PC value.
So don't export functions that might overlap with the host binary.
This way the pointer stays in its module.
Updates #18190
Change-Id: Ifb77605b35fb0a1e7edeecfd22b1e335ed4bb392
Reviewed-on: https://go-review.googlesource.com/34196
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Specify that that LimitedReader returns EOF when the underlying
R returns EOF even if bytes remaining, N > 0.
Fixes#18271
Change-Id: I990a7135f1d31488d535238ae061d42ee96bacb7
Reviewed-on: https://go-review.googlesource.com/34249
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: Icb842a80cab2b07b9ace1e8e14c4a19c48a92c43
Reviewed-on: https://go-review.googlesource.com/34247
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Made many minor changes so that the document is consistent with itself.
Some more noticeable changes:
* CL/34141: Revert "testing: add T.Context method"
* CL/33630: net/http: document restrictions on ETag as expected by ServeContent
Change-Id: I39ae5e55c56e374895c115e6852998c940beae35
Reviewed-on: https://go-review.googlesource.com/34243
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Must add locations to the profile when generating a profile.proto.
This fixes#18229
Change-Id: I49cd63a30759d3fe8960d7b7c8bd5a554907f8d1
Reviewed-on: https://go-review.googlesource.com/34028
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There is nothing notable to mention as far as users are concerned.
Fixes#17929 (another bug tracks the remaining TODO item)
Change-Id: Id39f787581ed9d2ecd493126bb7ca27836816d4b
Reviewed-on: https://go-review.googlesource.com/34145
Reviewed-by: Michael Matloob <matloob@golang.org>
This rolls back https://golang.org/cl/27117 partly, softening it so it
only retries POST/PUT/DELETE etc requests where there's no Body (nil
or NoBody). This is a little useless, since most idempotent requests
have a body (except maybe DELETE), but it's late in the Go 1.8 release
cycle and I want to do the proper fix.
The proper fix will look like what we did for http2 and only retrying
the request if Request.GetBody is defined, and then creating a new request
for the next attempt. See https://golang.org/cl/33971 for the http2 fix.
Updates #15723Fixes#18239
Updates #18241
Change-Id: I6ebaa1fd9b19b5ccb23c8d9e7b3b236e71cf57f3
Reviewed-on: https://go-review.googlesource.com/34134
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
The combination of two prior CLs can cause panics:
* CL/17873: make chained multiReader Read more efficient
* CL/28533: make MultiReader nil exhausted Readers for earlier GC
The first CL allows MultiReader to "inherit" another MultiReader's list of Readers
for efficiency reasons. This is problematic when combined with the
later CL since that can set prior Readers in that list to nil for GC reasons.
This causes panics when two MultiReaders are used together (even synchronously).
To fix this, rather than setting consumed Readers as nil, we set them with
a special eofReader that always returns EOF.
Fixes#18232
Change-Id: I2a9357ab217e3d54d38ea9022d18e4d14f4182d3
Reviewed-on: https://go-review.googlesource.com/34140
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This adds a counter for the number of times the application forced a
GC by, e.g., calling runtime.GC(). This is useful for detecting
applications that are overusing/abusing runtime.GC() or
debug.FreeOSMemory().
Fixes#18217.
Change-Id: I990ab7a313c1b3b7a50a3d44535c460d7c54f47d
Reviewed-on: https://go-review.googlesource.com/34067
Reviewed-by: Russ Cox <rsc@golang.org>
While processing a symbol for a function, if it is determined
that a function would make the text section too large then
a new text section is created and the address of the function
is in the new text section. But the symbol for the function
is marked as being in the previous text section, causing
incorrect codegen for the function and leading to a segv if
that function is called. This adds code to set the sym.Sect
field to the new section if a new one is created. Note that
this problem only happens at the point where a new section is
created.
Fixes#18218
Change-Id: Ic21ae11368d9d88ff6d5d3977f9ea72fe6477ed1
Reviewed-on: https://go-review.googlesource.com/34069
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
150 is too high for some people.
Reports of 132, 145, 149 on OS X.
Fixes#18203
Change-Id: I559639aba7e87e07d1a1249f8b212b3f34a078ab
Reviewed-on: https://go-review.googlesource.com/34019
Reviewed-by: Russ Cox <rsc@golang.org>
When we copy the stack, we need to adjust all BPs.
We correctly adjust the ones on the stack, but we also
need to adjust the one that is in g.sched.bp.
Like CL 33754, no test as only kernel-gathered profiles will notice.
Tests will come (in 1.9) with the implementation of #16638.
The invariant should hold that every frame pointer points to
somewhere within its stack. After this CL, it is mostly true, but
something about cgo breaks it. The runtime checks are disabled
until I figure that out.
Update #16638Fixes#18174
Change-Id: I6023ee64adc80574ee3e76491d4f0fa5ede3dbdb
Reviewed-on: https://go-review.googlesource.com/33895
Reviewed-by: Austin Clements <austin@google.com>
Previously it was possible to craft a DSA private key that would cause
Sign() to loop forever because no signature could be valid. This change
does some basic sanity checks and ensures that Sign will always
terminate.
Thanks to Yolan Romailler for highing this.
Be aware, however, that it's still possible for an attacker to simply
craft a private key with enormous values and thus cause Sign to take an
arbitrary amount of time.
Change-Id: Icd53939e511eef513a4977305dd9015d9436d0ce
Reviewed-on: https://go-review.googlesource.com/33725
Reviewed-by: Yolan Romailler <y@romailler.ch>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
It is reported as failing for two people (issues #18202 and #18212).
The failure mode is that the system gets overloaded and other programs
fail to run.
Fixes#18202.
Change-Id: I1f1ca1f5d8eed6cc3a9dffac3289851e09fa662b
Reviewed-on: https://go-review.googlesource.com/34017
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Mention that the best-effort race detector on maps
was upgraded to detect write/iterate races.
Fixes#18137
Change-Id: Ib6e0adde47e965126771ea712386031a2a55eba3
Reviewed-on: https://go-review.googlesource.com/33768
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL adds a simple example for StructOf.
The example shows how StructOf can be used in a JSON roundtrip.
Change-Id: I9ff1ea9cb8c0cf297c5fae74e68b89931076adfd
Reviewed-on: https://go-review.googlesource.com/33953
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Conditioning on the plugin.Open symbol existing before loading all
symbols means sometimes some packages don't have a hash value.
Fixes#17928
Change-Id: I2722449aa58eca08a25117d3ce976f11f805b5ac
Reviewed-on: https://go-review.googlesource.com/33925
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
