This was missed in CL 223139. It doesn't seem to affect correctness,
but might be confusing if we need to debug the cache key.
Updates #37804
Change-Id: I979efa68381cf79a7e246581510c90a724be6cd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/223144
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Offered as an alternative to CL 221380, which was more
tutorial than necessary.
Update #37344
Change-Id: Ide673b0b97983c2c2319a9311dc3d0a10567e6c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/223097
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Regenerate symkind_string.go, since it has become a bit out of date.
Change-Id: I57abf67aab8fe4e4a94fb5e45b9bc4c4005cbae3
Reviewed-on: https://go-review.googlesource.com/c/go/+/223079
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
After CL 166983, the guard for OCOMPLEX in evconst is not necessary
anymore.
Passes toolstash-check.
Change-Id: I1d4a9b447bad9ba0289fc7f997febc0e0b4167ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/214837
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
1) Introduced setLit method to uniformly set the scanner state for
literals instead of directly manipulating the scanner fields.
2) Use a local variable 'ok' to track validity of literals instead
of relying on the side-effect of error reporters setting s.bad.
More code but clearer because it is local and explicit.
3) s/litname/baseName/ and use this function uniformly, also for
escapes. Consequently we now report always "hexadecimal" and
not "hex" (in the case of invalid escapes).
4) Added TestDirectives verifying that we get the correct directive
string (even if that string contains '%').
Verified that lines/s parsing performance is unchanged by comparing
go test -run StdLib -fast -skip "syntax/(scanner|scanner_test)\.go"
before and after (no relevant difference).
Change-Id: I143e4648fdaa31d1c365fb794a1cae4bc1c3f5ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/222258
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This fixes observed failures using the following steps to reproduce:
go env -w GO111MODULE=off
go test cmd/internal/moddeps
Fixes#37749
Change-Id: I7761f0b20266ac911ad19a724ba2551beca3f267
Reviewed-on: https://go-review.googlesource.com/c/go/+/222674
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Previously, we extracted module zip files to temporary directories
with random names, then renamed them to their final locations. This
failed with ERROR_ACCESS_DENIED on Windows if any file in the
temporary was open. Antivirus programs did this occasionally. Retrying
the rename did not work (CL 220978).
With this change, we extract module zip files in place. We create a
.partial file alongside the .lock file to indicate a directory is not
fully populated, and we delete this at the end of the process.
Updates #36568
Change-Id: I75c09df879a602841f3459322c021896292b2fdb
Reviewed-on: https://go-review.googlesource.com/c/go/+/221157
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Currently, we extract module zip files to temporary directories, then
atomically rename them into place. On Windows, this can fail with
ERROR_ACCESS_DENIED if another process (antivirus) has files open
before the rename. In CL 220978, we repeated the rename operation in a
loop over 500 ms, but this didn't solve the problem for everyone.
A better solution will extract module zip files to their permanent
locations in the cache and will keep a ".partial" marker file,
indicating when a module hasn't been fully extracted (CL 221157).
This approach is not safe if current versions of Go access the module
cache concurrently, since the module directory is detected with a
single os.Stat.
In the interim, this CL makes two changes:
1. Flaky file system operations are repeated over 2000 ms to reduce
the chance of this error occurring.
2. cmd/go will now check for .partial files created by future
versions. If a .partial file is found, it will lock the lock file,
then remove the .partial file and directory if needed.
After some time has passed and Go versions lacking this CL are no
longer supported, we can start extracting module zip files in place.
Updates #36568
Change-Id: I467ee11aa59a90b63cf0e3e761c4fec89d57d3b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/221820
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Also increase the default deadline to 5s, since it empirically
doesn't need to be short and 1s seems to be too slow on some platforms.
Fixes#37795
Change-Id: Ie6bf3916b107401235a1fa8cb0f22c4a98eb2dae
Reviewed-on: https://go-review.googlesource.com/c/go/+/222959
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
CL 213058's "bonus optimization I noticed while working on this"
turns out to be buggy. It would be correct for CMP, but not TEST.
Fix it to use TEST semantics instead.
This was breaking compilation with the upcoming Spectre mode.
Change-Id: If2d4c3798ed182f35f0244febe74e68c61e4c61b
Reviewed-on: https://go-review.googlesource.com/c/go/+/222853
Reviewed-by: Keith Randall <khr@golang.org>
The default is for later flags to override earlier ones,
so if the asmcheck set flags, it lost the important -S=2.
Change-Id: Id538254908d658da2acb55157ac4f6fa44f6a467
Reviewed-on: https://go-review.googlesource.com/c/go/+/222820
Reviewed-by: Keith Randall <khr@golang.org>
This test is flaky, and the cause is suspected to be an OpenBSD kernel bug.
Since there is no obvious workaround on the Go side, skip the test on
builders whose versions are known to be affected.
Fixes#17496
Change-Id: Ifa70061eb429e1d949f0fa8a9e25d177afc5c488
Reviewed-on: https://go-review.googlesource.com/c/go/+/222856
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
This change forces CFGs to take the full width of their column
and allows them to be as tall as necessary.
In my (recent) experience, this makes them far less likely to
be cropped, which makes them much more useful.
On rare occasions, this can lead to gigantic CFGs,
but if you've bothered to explicitly request a CFG,
this is still better than an irrevocably truncated CFG.
Change-Id: I9a649ea57fa3c2792998bb71331a2580e429b36a
Reviewed-on: https://go-review.googlesource.com/c/go/+/222618
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In the open-code defer implementation, we add defer struct entries to the defer
chain on-the-fly at panic time to represent stack frames that contain open-coded
defers. This allows us to process non-open-coded and open-coded defers in the
correct order. Also, we need somewhere to be able to store the 'started' state of
open-coded defers. However, if a recover succeeds, defers will now be processed
inline again (unless another panic happens). Any defer entry representing a frame
with open-coded defers will become stale once we run the corresponding defers
inline and exit the associated stack frame. So, we need to remove all entries for
open-coded defers at recover time.
The current code was only removing the top-most open-coded defer from the defer
chain during recovery. However, with recursive functions that do repeated
panic-recover-repanic, multiple stale entries can accumulate on the chain. So, we
just adjust the loop to process the entire chain. Since this is at panic/recover
case, it is fine to scan through the entire chain (which should usually have few
elements in it, since most defers are open-coded).
The added test fails with a SEGV without the fix, because it tries to run a stale
open-code defer entry (and the stack has changed).
Fixes#37664.
Change-Id: I8e3da5d610b5e607411451b66881dea887f7484d
Reviewed-on: https://go-review.googlesource.com/c/go/+/222420
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Tighten up a testpoint that looks for the compile unit
DW_AT_go_package_name attribute. The linker code that injects this
attribute was accidentally broken on the dev.link branch, but in a way
that wasn't detected by the test (attr was generated, but always with
an empty string). The new test will fail if the attr is an empty
string, or if we can't find the attribute for the runtime package.
Change-Id: I8b065e7eb3486646364d0eaf48a73db6acffbd18
Reviewed-on: https://go-review.googlesource.com/c/go/+/218483
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
AIX, Solaris, and Illumos all appear to implement fcntl deadlock
detection at the granularity of processes. However, we are acquiring
and releasing file locks on individual goroutines running
concurrently: our locking occurs at a much finer granularity. As a
result, these platforms occasionally fail with EDEADLK errors, when
they detect locks that would be _misordered_ in a single-threaded
program but are safely _unordered_ in a multi-threaded context.
To work around the spurious errors, we treat EDEADLK as always
spurious, and retry the failing system call with a bounded exponential
backoff. This approach may introduce substantial latency since we no
longer benefit from kernel-scheduled wakeups in case of collisions,
but high-latency operations seem better than spurious failures.
Updates #33974
Updates #35618Fixes#32817
Change-Id: I58b2c6a0f143bce55d6460fd4ddc3db83577ada7
Reviewed-on: https://go-review.googlesource.com/c/go/+/222277
Reviewed-by: Jay Conrod <jayconrod@google.com>
If typehash (used by reflect) does not match the built-in map's hash,
then problems occur. If a map is built using reflect, and then
assigned to a variable of map type, the hash function can change. That
causes very bad things.
This issue is rare. MapOf consults a cache of all types that occur in
the binary before making a new one. To make a true new map type (with
a hash function derived from typehash) that map type must not occur in
the binary anywhere. But to cause the bug, we need a variable of that
type in order to assign to it. The only way to make that work is to
use a named map type for the variable, so it is distinct from the
unnamed version that MapOf looks for.
Fixes#37716
Change-Id: I3537bfceca8cbfa1af84202f432f3c06953fe0ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/222357
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Due to improved optimisation, we no longer emit SUBW for the write barrier
checks on riscv64, hence remove special handling in markUnsafePoints.
Change-Id: Ia1150c3e11f25e183735e58f8716a511d9e90fb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/222638
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL copies IMAGE_FILE_*, IMAGE_SUBSYSTEM_* and
IMAGE_DLLCHARACTERISTICS_* consts from cmd/link/internal/ld package.
The consts are also used in cmd/go and debug/pe tests. So avoid the
duplication.
The consts are defined in
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
and might be useful to other Go users.
The CL also adds some related consts.
RELNOTE=yes
Change-Id: Iaa868deaffc7c61051f2273397f3e7e101880a5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/222637
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Functions that are exported through cgo will now retain their
parameter names provided that their parameter names use only
ASCII characters.
Fixes#37746
Change-Id: Ia5f643e7d872312e81c224febd1f81ce14425c32
GitHub-Last-Rev: 220959beba
GitHub-Pull-Request: golang/go#37750
Reviewed-on: https://go-review.googlesource.com/c/go/+/222619
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change re-vendors x/tools to add the ifaceassert and stringintconv
checks to cmd/vet.
Fixes#32479.
Updates #4483.
Change-Id: I6bd30b0a3278592dfab4bd247036404ddaff09e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/221339
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Rewrite string(int) to a string literal with a NUL byte, in preparation for the vet warning.
Updates #32479.
Change-Id: If4b6879334884324df3d566b6b4166ecf501d066
Reviewed-on: https://go-review.googlesource.com/c/go/+/221338
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Use a separate compiler pass to introduce complicated x86 addressing
modes. Loads in the normal architecture rules (for x86 and all other
platforms) can have constant offsets (AuxInt values) and symbols (Aux
values), but no more.
The complex addressing modes (x+y, x+2*y, etc.) are introduced in a
separate pass that combines loads with LEAQx ops.
Organizing rewrites this way simplifies the number of rewrites
required, as there are lots of different rule orderings that have to
be specified to ensure these complex addressing modes are always found
if they are possible.
Update #36468
Change-Id: I5b4bf7b03a1e731d6dfeb9ef19b376175f3b4b44
Reviewed-on: https://go-review.googlesource.com/c/go/+/217097
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Re-vendor x/net/dns/dnsmessage, x/net/route, and github.com/google/pprof
(commit 1ebb73c). The updated dependencies fix the string(int)
conversions, in preparation for the vet warning.
Updates #32479.
Change-Id: I023a4e30415d060f8b403b9943fe911f6d19f2e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/221337
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 212777 added a check to isNonNegative
to return true for unsigned values.
However, the SSA backend isn't type safe
enough for that to be sound.
The other checks in isNonNegative
look only at the pattern of bits.
Remove the type-based check.
Updates #37753
Change-Id: I059d0e86353453133f2a160dce53af299f42e533
Reviewed-on: https://go-review.googlesource.com/c/go/+/222620
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
It does nothing (it can't even be parsed).
Change-Id: I29abdddea1955d2ad93a97696f6542fa47cdb954
Reviewed-on: https://go-review.googlesource.com/c/go/+/222672
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I do not know much about xcoff, but this was probably the intended
behavior. (The comparison is tautologically false, as is.)
Also note: does any other code even depend on the changed code existing?
Maybe it should just be removed, as I did not find any uses of fields
that are written to if the branch condition tests true.
Change-Id: I1f23d33764df40e87f3e64460d63f6efc51a2a78
GitHub-Last-Rev: 268909130f
GitHub-Pull-Request: golang/go#37733
Reviewed-on: https://go-review.googlesource.com/c/go/+/222478
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Clément Chigot <clement.chigot%atos.net@gtempaccount.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
-gcflags=-flag means apply the flags only to the package named
on the command line (the main package, for these tests).
-gcflags=all=-flag means apply the flags to everything in the build,
including the standard library.
cmd/dist uses -gcflags=all=$GO_GCFLAGS, so test/run should do the same,
as the comment already explains, to avoid rebuilding the entire standard
library without the flags during test/run's builds.
We changed the scope of the flags without a pattern a few releases
ago and missed this one.
Change-Id: I039e60ca619d39e5b502261d4a73e1afc7e3f9fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/213827
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Since json is popular and mime package's builtin type does not contain
it, and some Linux distributions do not contain the '/etc/mime.types' file
with minimal installations.
Change-Id: I933393c82be296ef176206c253f4dd19b6f33bb1
GitHub-Last-Rev: ce4eae56a4
GitHub-Pull-Request: golang/go#34737
Reviewed-on: https://go-review.googlesource.com/c/go/+/199657
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Cookies already work as http.Request parses the Cookie header on-demand
when the Cookie methods are called.
Change-Id: Ib7a6f68be02940ff0b56d2465c94545d6fd43847
Reviewed-on: https://go-review.googlesource.com/c/go/+/221417
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The default error string for a command failure is just its status code,
and "exit status 1" is not at all helpful for debugging.
Change-Id: I822c89bcc9e73283b33e01792bf9c40b1add3c35
Reviewed-on: https://go-review.googlesource.com/c/go/+/222308
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
'go test -json' should report that a test failed if the test binary
did not exit normally with status 0. This covers panics, non-zero
exits, and abnormal terminations.
These tests don't print a final result when run with -test.v (which is
used by 'go test -json'). The final result should be "PASS" or "FAIL"
on a line by itself. 'go test' prints "FAIL" in this case, but
includes error information.
test2json was changed in CL 192104 to report that a test passed if it
does not report a final status. This caused 'go test -json' to report
that a test passed after a panic or non-zero exit.
With this change, test2json treats "FAIL" with error information the
same as "FAIL" on a line by itself. This is intended to be a minimal
fix for backporting, but it will likely be replaced by a complete
solution for #29062.
Fixes#37555
Updates #29062
Updates #31969
Change-Id: Icb67bcd36bed97e6a8d51f4d14bf71f73c83ac3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/222243
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When generating stacks, the runtime automatically expands inline
functions to inline all inline frames in the stack. However, due to the
stack size limit, the final frame may be truncated in the middle of
several inline frames at the same location.
As-is, we assume that the final frame is a normal function, and emit and
cache a Location for it. If we later receive a complete stack frame, we
will first use the cached Location for the inlined function and then
generate a new Location for the "caller" frame, in violation of the
pprof requirement to merge inlined functions into the same Location.
As a result, we:
1. Nondeterministically may generate a profile with the different stacks
combined or split, depending on which is encountered first. This is
particularly problematic when performing a diff of profiles.
2. When split stacks are generated, we lose the inlining information.
We avoid both of these problems by performing a second expansion of the
last stack frame to recover additional inline frames that may have been
lost. This expansion is a bit simpler than the one done by the runtime
because we don't have to handle skipping, and we know that the last
emitted frame is not an elided wrapper, since it by definition is
already included in the stack.
Fixes#37446
Change-Id: If3ca2af25b21d252cf457cc867dd932f107d4c61
Reviewed-on: https://go-review.googlesource.com/c/go/+/221577
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The test will remain flaky on the -nocgo builder until #37695 is addressed.
Updates #37695Fixes#33041
Change-Id: I5d661ef39e82ab1dce3a76e0e4059cf556135e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/222158
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
