Most of the test cases in the test directory use the new go:build syntax
already. Convert the rest. In general, try to place the build constraint
line below the test directive comment in more places.
For #41184.
For #60268.
Change-Id: I11c41a0642a8a26dc2eda1406da908645bbc005b
Cq-Include-Trybots: luci.golang.try:gotip-linux-386-longtest,gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/536236
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is a pure code movement change.
Now that we've introduced a Shell type that lives in shell.go, move
all of its methods (which used to be on Builder) to shell.go as well.
Change-Id: Ie1802353c8a64590219b08893e8c74649228e5e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/536536
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
There are quite a few places that perform their own command logging
and then use os.RemoveAll. Unify (nearly) all of these into
(*Shell).RemoveAll, like many of the other internal implementations of
basic shell operations.
Change-Id: I94a2cbd9dc150a4c94a4051c42ce8e86dcc736fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/536099
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>
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>
Currently, Builder.fmtcmd can read scriptDir without taking the output
lock. This introduces a potential data race between the read in fmtcmd
and the write in Showcmd. There's also a logical race here: because
fmtcmd doesn't know when its output is going to be printed, Showcmd
may print a "cd" command between when fmtcmd is called and when its
output is printed. As a result, it doesn't make sense to just lock
around the access in fmtcmd.
Instead, move the entire scriptDir substitution to Showcmd. This will
generally result in the same output. In the cases where Builder.run is
called with a non-empty desc, it means we may print a full path in the
comment line above output rather than substituting the script
directory. I think this is okay.
This lets us undo the workaround in CL 536355.
Change-Id: I617fe136eaafcc9bbb7e701b427d956aeab8a2b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/536376
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>
Currently, cmdError makes a somewhat fuzzy attempt to ensure the
package import path is part of the printed error, using a string
prefix check. Also, if it decides it does need to add the import path,
it prints it as a "go build" line, which could be misleading because
it can happen outside of "go build".
Clean up the whole code path by explicitly checking the provided error
description against Package.Desc(), and instead of emitting "go build"
in the error message, print it as "# importPath" just like we do in
the common case.
Change-Id: Idb61ac8ffd6920a3d2d282697f4d7d5555ebae0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/534655
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Change-Id: I2839ecb091c4f0b30d0dcee708bf9e9a55e3672a
Reviewed-on: https://go-review.googlesource.com/c/go/+/535196
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
Change-Id: Ie2e8b56225292ef0a28a25f96b0a57cc198a13e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/535195
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: I4a6c2ef6fd21355952ab7d8eaad883646a95d364
Reviewed-on: https://go-review.googlesource.com/c/go/+/535087
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Change-Id: I23e2bc67476ed1cedf61db9953683e57ab6bf522
GitHub-Last-Rev: 458581ec26
GitHub-Pull-Request: golang/go#63530
Reviewed-on: https://go-review.googlesource.com/c/go/+/535655
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Yohan Mok <yohan@ab180.co>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The current implementation of the builtin copy function will return early
when it is found that the addresses of the first elements of the two
slice arguments are identical, so it is unnecessarily to do this in user code.
See #57759 for details.
Change-Id: I7c101eee496923d7aa59f94720da6c84feb93af8
GitHub-Last-Rev: 4d6819fb25
GitHub-Pull-Request: golang/go#63617
Reviewed-on: https://go-review.googlesource.com/c/go/+/536255
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Commit 061d77cb70 was published in parallel with another commit
36ecff0893 which changed how certain constants were generated.
Update the test to account for the changes.
Change-Id: I314b735a34857efa02392b7a0dd9fd634e4ee428
Reviewed-on: https://go-review.googlesource.com/c/go/+/536256
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Paul Murphy <murp@ibm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 529219 made an existing race with accessing Builder.scriptDir from
Builder.fmtcmd (and now also Builder.Showcmd) much more likely by
dropping a theoretically unnecessary condition from the call from
Builder.run to Builder.fmtcmd.
For an example race report, see
https://build.golang.org/log/c3cad62d0fc33a8381d2091661c685ea1fc525c4
The race is between
(*Builder).cover2() -> (*Builder).run() -> (*Builder).fmtcmd()
and various other call paths of the form
(*Builder).build() -> (*gcToolchain).* (*Builder).Showcmd() -> (*Builder).fmtcmd()
The race can be reproduced with
go install -race cmd/go
stress -p 1 go test -x -cover -a log
Return this race to its existing likelihood by putting the condition
back. This isn't a "correct" solution because the race could still
happen if the "cover" tool invoked by Builder.cover2 emits output. But
this will do for a temporary fix.
Change-Id: Ifd811dea07f05e1422fd02b63cd958627727aa12
Reviewed-on: https://go-review.googlesource.com/c/go/+/536355
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>
IsZero does the same thing, using this rather than writing it again.
Follow-up to https://github.com/golang/go/pull/63519
Change-Id: I93768874052935dd7cb58804f22748091bcc3ef7
GitHub-Last-Rev: dfbc6ed635
GitHub-Pull-Request: golang/go#63540
Reviewed-on: https://go-review.googlesource.com/c/go/+/535415
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I6150858f1186edc6cebd38ff166d57287fa430f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/535078
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: Iefccc7aeb0f697c555ae8a6a6bb6cd5091882195
Reviewed-on: https://go-review.googlesource.com/c/go/+/535079
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: shuang cui <imcusg@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: I00d49ded65801ab12322f711d1ac6131d69aea34
Reviewed-on: https://go-review.googlesource.com/c/go/+/535081
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: shuang cui <imcusg@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: I5973a352edb73e02a274d939d6d0573788640dc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/535435
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Change-Id: I9e7b7e10d9e3d23e4ed540eb8137cd1f4d103711
Reviewed-on: https://go-review.googlesource.com/c/go/+/534761
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: shuang cui <imcusg@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, go mod vendor copy all files matched by //go:embed,
even when it is in a _test.go file. According to the documentation,
it should not include test code for vendored packages.
Fixes#63473
Change-Id: I28c411724fc7b7aeb683857fc114e20b08635e01
Reviewed-on: https://go-review.googlesource.com/c/go/+/534376
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Converting and verifying a bitmask can be done much quicker
and simpler. Since this touches the MD-form opcodes, cleanup
their encoding too.
Change-Id: I9b1c1fdc4c9622e489ff6cf8181c5b647afae7c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/534017
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This is only supported power10/linux/PPC64. This generates smaller,
faster code by merging a pli + add into paddi.
Change-Id: I1f4d522fce53aea4c072713cc119a9e0d7065acc
Reviewed-on: https://go-review.googlesource.com/c/go/+/531717
Run-TryBot: Paul Murphy <murp@ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
In the Power10 rule to fold bit reversal into load, the MOVWZreg or
MOVHZreg (Zeroing out the upper bits of a word or halfword) becomes
redundant since byte reverse (BR) load clears the upper bits. Hence
removing for Power10. Similarly for < Power10 cases in the rule used to
fold bit reversal into load (Bswap), the above redundant operation is removed.
Change-Id: Idb027e8b6e79b6acfb81d48a9a6cc06f8e9cd2db
Reviewed-on: https://go-review.googlesource.com/c/go/+/531377
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jayanth Krishnamurthy <jayanth.krishnamurthy@ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The documentation of readvarintUnsafe claims itself and readvarint are
duplicated. However, two implementation are not in synced, since when
readvarint got some minor improvements in CL 43150.
Updating readvarintUnsafe to match readvarint implementation to gain a
bit of speed. While at it, also updating its documentation to clarify
the main difference.
name time/op
ReadvarintUnsafe/old-8 6.04ns ± 2%
ReadvarintUnsafe/new-8 5.31ns ± 3%
Change-Id: Ie1805d0747544f69de88f6ba9d1b3960f80f00e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/535815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Follow up discussion in CL 535077.
Change-Id: I102c90839e39c463e878ff925872376303724e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/535636
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The funcdata is encoded as varint, with the upper limit set to 1e9.
However, the stack offsets could be up to 1<<30. Thus emitOpenDeferInfo
will trigger an ICE for function with large frame size.
By using binary.PutUvarint, the frame offset could be encoded correctly
for value larger than 1<<35, allow the compiler to report the error.
Further, the runtime also do validation when reading in the funcdata
value, so a bad offset won't likely cause mis-behavior.
Fixes#52697
Change-Id: I084c243c5d24c5d31cc22d5b439f0889e42b107c
Reviewed-on: https://go-review.googlesource.com/c/go/+/535077
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
In the PPC64 ISA, the instruction to do an 'and' operation
using an immediate constant is only available in the form that
also sets CR0 (i.e. clobbers the condition register.) This means
CR0 is being clobbered unnecessarily in many cases. That
affects some decisions made during some compiler passes
that check for it.
In those cases when the constant used by the ANDCC is a right
justified consecutive set of bits, a shift instruction can
be used which has the same effect if CR0 does not need to be
set. The rule to do that has been added to the late rules file
after other rules using ANDCCconst have been processed in the
main rules file.
Some codegen tests had to be updated since ANDCC is no
longer generated for some cases. A new test case was added to
verify the ANDCC is present if the results for both the AND
and CR0 are used.
Change-Id: I304f607c039a458e2d67d25351dd00aea72ba542
Reviewed-on: https://go-review.googlesource.com/c/go/+/531435
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Jayanth Krishnamurthy <jayanth.krishnamurthy@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
CL 529219 tweaked the list_pkgconfig_error script test currently to
expect pkg-config to fail with "Package .* not found$", but on several
OSes (at least OpenBSD, AIX, and Solaris), pkg-config prints "Package
libnot-a-valid-cgo-library was not found in the pkg-config search
path". Fix the test on these OSes by dropping the "$" so the test
doesn't require the line to end with "not found".
Change-Id: I40c577521f34c360a1d62355596958f6f969eb54
Reviewed-on: https://go-review.googlesource.com/c/go/+/536195
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alan Donovan <adonovan@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>
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>
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>
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>
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>
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>
Some new linker may emit warning message to standard error, causing
false positive in test result.
Fixing this by testing only stdout output.
Fixes#63588
Change-Id: I272048c41dc1c316f44af2dfc903bb03383baea3
Reviewed-on: https://go-review.googlesource.com/c/go/+/535975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The function WriteTabs has been renamed WritePluginTable.
Change-Id: I5f04b99b91498c41121f898cb7774334a730d7b4
GitHub-Last-Rev: c98ab3f872
GitHub-Pull-Request: golang/go#63595
Reviewed-on: https://go-review.googlesource.com/c/go/+/535996
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
QueryPerformanceCounter is available since Windows 2000 [1], so there
is no need to conditionally load it.
Even if the Go runtime doesn't eventually use it, it is still simpler
and faster to just tell the Windows loader to load it, instead of doing
it ourselves.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter
Change-Id: Ied3b54a6a8fe3b8d51aefab0fe483b3a193b5522
Reviewed-on: https://go-review.googlesource.com/c/go/+/532915
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
AddVectoredContinueHandler is available since Windows XP [1], there is
no need to check if it is available.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-addvectoredcontinuehandler
Change-Id: I1ddc3d58b3294d9876620cd46159d9692694b475
Reviewed-on: https://go-review.googlesource.com/c/go/+/532817
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The current output for empty declarations such as var, const, import
results in "var", "const", "import" respectively. These are not valid
and the parser will promptly reject them as invalid syntax.
This CL updates this behavior by adding "()" to the output of empty
decls so the syntax becomes valid, e.g "var ()" instead of "var".
Fixes#63566
Change-Id: I571b182d9ccf71b159360c8de003ad55d0ff3443
GitHub-Last-Rev: 2720419e36
GitHub-Pull-Request: golang/go#63593
Reviewed-on: https://go-review.googlesource.com/c/go/+/535995
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
While at it, also using "slices" package to simplify code.
For #63489
Change-Id: I72b325f6ad379b996c108145885fa71706f6659f
Reviewed-on: https://go-review.googlesource.com/c/go/+/536055
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
"out" is often used for stdout or stderr. Rename it to targetPath to
clarify its meaning.
Change-Id: I95823e9119843a7026dc26c192497776ee4219e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/534595
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>
Fixes#63525.
Change-Id: Ie9aa4dd47c025cd593e576c6e8de1774e1d1e302
Reviewed-on: https://go-review.googlesource.com/c/go/+/535775
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
We need to track the brace depth for each individual nested expression,
since a string interpolation expression may be nested inside of an
object.
e.g. `${ {1:`${}`}}` has brace depths [1, 0] when inside of the inner
${} expression. When we exit the inner expression, we need to reset to
the previous brace depth (1) so that we know that the following } closes
the object, but not the outer expression.
Note that if you write a broken expression (i.e. `${ { }`) escaping will
clearly not work as expected (or depending on your interpretation, since
it is broken, it will work as expected). Since the JS parser doesn't
catch syntax errors, it's up to the user to write a valid template.
Updates #61619
Change-Id: I4c33723d12aff49facdcb1134d9ca82b7a0dffc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/532995
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: Iba8878420c59d705066d1d9955e91a5c2eb4faf5
Reviewed-on: https://go-review.googlesource.com/c/go/+/507615
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: Id0a4f5716da98008eec10eee05b74fc2a155ba3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/535216
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
We were using the size stored in the map, which is the smaller
of the real type size and 128.
As of CL 61538 we don't use these functions, but we expect to
use them again in the future after #61626 is resolved.
Change-Id: I7bfb4af5f0e3a56361d4019a8ed7c1ec59ff31fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/535215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
