CL 163760 was submitted with this file generated from an old version
of the code generator.
Change-Id: I9a3b9a48f794f74567f82ef58637cb1820befd11
Reviewed-on: https://go-review.googlesource.com/c/go/+/167677
Reviewed-by: Richard Musiol <neelance@gmail.com>
TryBot is sometimes running into deadlocks on js/wasm. We haven't been
able to reproduce them yet. This workaround is an experiment to resolve
these deadlocks by retrying a missed timeout event.
A timeout event is scheduled by Go to be woken by JavaScript after a
certain amount of time. The checkTimeouts function then checks which
notes to wake by comparing their deadline to nanotime. If this
check fails erroneously then the note may stay asleep forever, causing
a deadlock. This may or may not be the reason of the observed
deadlocks.
Updates #28975.
Change-Id: I46b9d4069307142914f0e7b3acd4e65578319f0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/167119
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Checks that specs exist before attempting to access the first element in genDecl printer.
Change-Id: I3619bcabf6fec64c88b7a10cdb7be355e9e40559
GitHub-Last-Rev: 54cf699c96
GitHub-Pull-Request: golang/go#30823
Reviewed-on: https://go-review.googlesource.com/c/go/+/167390
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reverts CL 166985, restoring CL 162698.
The bootstrap failure from CL 162698 was fixed in
CL 167077 and CL 167078.
Fixes#30228
Change-Id: I5a4e3081018c51b74b67185e64f20a9c824a564e
Reviewed-on: https://go-review.googlesource.com/c/go/+/167087
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
A bug in the encoding of XX1-Form is flipping bit 31 of such instructions.
This may result in register clobering when using VSX instructions.
This was not exposed before because we currently don't generate these
instructions in SSA, and the asm files in which they are present aren't
affected by register clobbering.
This change fixes the bug and adds a testcase for the problem.
Fixes#30112
Change-Id: I77b606159ae1efea33d2ba3e1c74b7fae8d5d2e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/163759
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This applies only for cases where %w is not used.
The purpose of this change is to reduce test failures where tests
depend on these two being the same type, as they previously were.
Change-Id: I2dd28b93fe1d59f3cfbb4eb0875d1fb8ee699746
Reviewed-on: https://go-review.googlesource.com/c/go/+/167402
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
See Issue #29382 and Issue #30468.
Improvements in this CL:
name old time/op new time/op delta
New-8 352ns ± 2% 225ns ± 5% -36.04% (p=0.008 n=5+5)
Improvements together with moving to 1 uintptr:
name old time/op new time/op delta
New-8 475ns ± 3% 225ns ± 5% -52.59% (p=0.008 n=5+5)
Change-Id: I9d69a14e5e10a6498767defb7d5f26ceedcf9ba5
Reviewed-on: https://go-review.googlesource.com/c/go/+/167401
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
This is a refinement of CL 164557.
Make it explicit in tests that using a non-string verb with
fmtError does not result in falling back to using fmt.Formatter.
Change-Id: I6d090f31818eb7cc7668d7565b1449c91cd03a23
Reviewed-on: https://go-review.googlesource.com/c/go/+/164701
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Standard output is reserved for actual program output.
Debug print should be limited in general (here they are
enabled by an environment variable) and always go to
standard error.
Came across by accident.
Change-Id: I1490be71473520f049719572b3acaa0ea9f9e5c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/167502
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
As of CL 163747, we can write arbitrary length strings
in assembly DATA instructions.
Make use of it here to improve readability.
Change-Id: I556279ca893f527874e3b26112c43573834ccd9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/167386
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 165619 removed these names when it removed
the use of the plain 'return'. But the names help for
documentation purposes even without being mentioned
directly in the function, so removing them makes the
code less readable. Put them back. I renamed found
to zeroFound to make the meaning clearer.
Change-Id: I1010931f08290af0b0ede7d21b1404c2eea196a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/165899
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This rewrite rule triggers only once, in math/big.quotToFloat64,
as part of converting a uint64 to a float64.
Nevertheless, it is cheap; let's add it.
Change-Id: I3ed4a197a559110fec1bc04b3a8abb4c7fcc2c89
Reviewed-on: https://go-review.googlesource.com/c/go/+/167500
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
We know that a & 31 is non-negative for all a, signed or not.
We can avoid checking that and needing to write out an
unreachable call to panicshift.
Change-Id: I32f32fb2c950d2b2b35ac5c0e99b7b2dbd47f917
Reviewed-on: https://go-review.googlesource.com/c/go/+/167499
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Based on suggestion from gri@ on golang.org/cl/166980.
Passes toolstash-check.
Change-Id: I79b66bb09b5635f3a9daecaa5d605b661a0ab108
Reviewed-on: https://go-review.googlesource.com/c/go/+/167501
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The len godoc uses a blockquote to list the rules for its semantics.
The item that describes channels is a bit long, so it's split in two
lines. However, the first line ends with a semicolon, and the second
line can be read as a sentence of its own, so it's easy to misinterpret
that the two lines are separate.
Making that easy mistake would lead to an incorrect understanding of
len:
if v is nil, len(v) is zero.
This could lead us to think that len(nil) is valid and should return
zero. When in fact, that statement only applies to nil channels.
To make this less ambiguous, add a bit of indentation to the follow-up
line, to align with the channel body. If lists are added to godoc in the
future via #7873, perhaps this text can be simplified.
Fixes#30349.
Change-Id: I84226edc812d429493137bcc65c332e92d4e6c87
Reviewed-on: https://go-review.googlesource.com/c/go/+/167403
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
`go build` has chosen the last element of the package import path
as the default output name when -o option is given. That caused
the output of a package build when the module root is the major
version component such as 'v2'.
A similar issue involving `go install` was fixed in
https://golang.org/cl/128900. This CL refactors the logic added
with the change and makes it available as
internal/load.DefaultExecName.
This CL makes 'go test' to choose the right default test binary
name when the tested package is in the module root. (E.g.,
instead of v2.test, choose pkg.test for the test of 'path/pkg/v2')
Fixes#27283.
Change-Id: I6905754f0906db46e3ce069552715f45356913ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/140863
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The only ways to construct an OLITERAL node are (1) a basic literal
from the source package, (2) constant folding within evconst (which
only folds Go language constants), (3) the universal "nil" constant,
and (4) implicit conversions of nil to some concrete type.
Passes toolstash-check.
Change-Id: I30fc6b07ebede7adbdfa4ed562436cbb7078a2ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/166981
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
All setconst calls now happen within evconst. While here, get rid of
callrecv, which (incompletely) duplicates the logic of hascallchan.
Passes toolstash-check.
Change-Id: Ic67b9dd2a1b397d4bc25e8c8b6f81daf4f6cfb75
Reviewed-on: https://go-review.googlesource.com/c/go/+/166980
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We already have a pure go code sequence that is compiled into single load.
Just use it everywhere, instead of pointer hackery.
Passes toolstash-check.
Change-Id: I0c42b5532fa9a5665da3385913609c6d42aaff27
Reviewed-on: https://go-review.googlesource.com/c/go/+/118568
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This reduces the number of extra bounds check hints we need to
insert. For example, rather than producing:
_ = v.Args[2]
x := v.Args[0]
y := v.Args[1]
z := v.Args[2]
We now produce:
z := v.Args[2]
x := v.Args[0]
y := v.Args[1]
This gets rid of about 7000 lines of code from the rewrite rules.
Change-Id: I1291cf0f82e8d035a6d65bce7dee6cedee04cbcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/167397
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ppc64{,le} processor level selection allows the compiler to generate instructions
targeting newer processors and processor-specific optimizations without breaking
compatibility with our current baseline. This feature introduces a new environment
variable, GOPPC64.
GOPPC64 is a GOARCH=ppc64{,le} specific option, for a choice between different
processor levels (i.e. Instruction Set Architecture versions) for which the
compiler will target. The default is 'power8'.
Change-Id: Ic152e283ae1c47084ece4346fa002a3eabb3bb9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/163758
Run-TryBot: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
When a jump at the end of a block is about to be marked as
a statement, if the first real instruction in the target
block is also a statement for the same line, remove the
mark from the jump.
This is a first effort at a minimal-harm heuristic.
A better heuristic might skip over any "not-statement"
values preceding a definitely marked value.
Fixes#29443.
Change-Id: Ibd52783713b4936e0c2dfda8d708bf186f33b00a
Reviewed-on: https://go-review.googlesource.com/c/go/+/159977
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This internally exported function allowed merging environment variable
lists, and was mostly a convenience for the rest of cmd/go/internal.
It seems to date all the way back to 2013.
However, since CL 37586 in early 2017, os/exec has already taken care of
deduplicating environment variable lists. Thus, it's unnecessary for
cmd/go to take care of that before calling exec.Cmd.Start.
Moreover, because os/exec will deduplicate the list in any case, we're
adding extra work in all these scenarios.
Finally, remove an unnecessary addition of GOROOT= in internal/tool.
cfg.OrigEnv may not have the correct GOROOT set up, but os.Environ does;
cmd/go's main function makes sure of that.
Change-Id: I1f92f65fb927dc15bc7b0397cfd1a572b6337bb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/164703
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Most of the decoding time is spent in the first Decode loop, since the
rest of the function only deals with the few remaining bytes. Any
unnecessary work done in that loop body matters tremendously.
One such unnecessary bottleneck was the use of the enc.decodeMap table.
Since enc is a pointer receiver, and the field is used within the
non-inlineable function decode64, the decoder must perform a nil check
at every iteration.
To fix that, move the enc.decodeMap uses to the parent function, where
we can lift the nil check outside the loop. That gives roughly a 15%
speed-up. The function no longer performs decoding per se, so rename it.
While at it, remove the now unnecessary receivers.
An unfortunate side effect of this change is that the loop now contains
eight bounds checks on src instead of just one. However, not having to
slice src plus the nil check removal well outweigh the added cost.
The other piece that made decode64 slow was that it wasn't inlined, and
had multiple branches. Use a simple bitwise-or trick suggested by Roger
Peppe, and collapse the rest of the bitwise logic into a single
expression. Inlinability and the reduced branching give a further 10%
speed-up.
Finally, add these two functions to TestIntendedInlining, since we want
them to stay inlinable.
Apply the same refactor to decode32 for consistency, and to let 32-bit
architectures see a similar performance gain for large inputs.
name old time/op new time/op delta
DecodeString/2-8 47.3ns ± 1% 45.8ns ± 0% -3.28% (p=0.002 n=6+6)
DecodeString/4-8 55.8ns ± 2% 51.5ns ± 0% -7.71% (p=0.004 n=5+6)
DecodeString/8-8 64.9ns ± 0% 61.7ns ± 0% -4.99% (p=0.004 n=5+6)
DecodeString/64-8 238ns ± 0% 198ns ± 0% -16.54% (p=0.002 n=6+6)
DecodeString/8192-8 19.5µs ± 0% 14.6µs ± 0% -24.96% (p=0.004 n=6+5)
name old speed new speed delta
DecodeString/2-8 84.6MB/s ± 1% 87.4MB/s ± 0% +3.38% (p=0.002 n=6+6)
DecodeString/4-8 143MB/s ± 2% 155MB/s ± 0% +8.41% (p=0.004 n=5+6)
DecodeString/8-8 185MB/s ± 0% 195MB/s ± 0% +5.29% (p=0.004 n=5+6)
DecodeString/64-8 369MB/s ± 0% 442MB/s ± 0% +19.78% (p=0.002 n=6+6)
DecodeString/8192-8 560MB/s ± 0% 746MB/s ± 0% +33.27% (p=0.004 n=6+5)
Updates #19636.
Change-Id: Ib839577b0e3f5a2bb201f5cae580c61365d92894
Reviewed-on: https://go-review.googlesource.com/c/go/+/151177
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
This change makes it possible the runtime-integrated network poller and
APIs in the package internal/poll to report an event scanning error on a
read event.
The latest Go releases open up the way of the manipulation of the poller
for users. On the other hand, it starts misleading users into believing
that the poller accepts any user-configured file or socket perfectly
because of not reporting any error on event scanning, as mentioned in
issue 30426. The initial implementation of the poller was designed for
just well-configured, validated sockets produced by the package net.
However, the assumption is now obsolete.
Fixes#30624.
Benchmark results on linux/amd64:
benchmark old ns/op new ns/op delta
BenchmarkTCP4OneShot-4 24649 23979 -2.72%
BenchmarkTCP4OneShotTimeout-4 25742 24411 -5.17%
BenchmarkTCP4Persistent-4 5139 5222 +1.62%
BenchmarkTCP4PersistentTimeout-4 4919 4892 -0.55%
BenchmarkTCP6OneShot-4 21182 20767 -1.96%
BenchmarkTCP6OneShotTimeout-4 23364 22305 -4.53%
BenchmarkTCP6Persistent-4 4351 4366 +0.34%
BenchmarkTCP6PersistentTimeout-4 4227 4255 +0.66%
BenchmarkTCP4ConcurrentReadWrite-4 2309 1839 -20.36%
BenchmarkTCP6ConcurrentReadWrite-4 2180 1791 -17.84%
benchmark old allocs new allocs delta
BenchmarkTCP4OneShot-4 26 26 +0.00%
BenchmarkTCP4OneShotTimeout-4 26 26 +0.00%
BenchmarkTCP4Persistent-4 0 0 +0.00%
BenchmarkTCP4PersistentTimeout-4 0 0 +0.00%
BenchmarkTCP6OneShot-4 26 26 +0.00%
BenchmarkTCP6OneShotTimeout-4 26 26 +0.00%
BenchmarkTCP6Persistent-4 0 0 +0.00%
BenchmarkTCP6PersistentTimeout-4 0 0 +0.00%
BenchmarkTCP4ConcurrentReadWrite-4 0 0 +0.00%
BenchmarkTCP6ConcurrentReadWrite-4 0 0 +0.00%
benchmark old bytes new bytes delta
BenchmarkTCP4OneShot-4 2000 2000 +0.00%
BenchmarkTCP4OneShotTimeout-4 2000 2000 +0.00%
BenchmarkTCP4Persistent-4 0 0 +0.00%
BenchmarkTCP4PersistentTimeout-4 0 0 +0.00%
BenchmarkTCP6OneShot-4 2144 2144 +0.00%
BenchmarkTCP6OneShotTimeout-4 2144 2145 +0.05%
BenchmarkTCP6Persistent-4 0 0 +0.00%
BenchmarkTCP6PersistentTimeout-4 0 0 +0.00%
BenchmarkTCP4ConcurrentReadWrite-4 0 0 +0.00%
BenchmarkTCP6ConcurrentReadWrite-4 0 0 +0.00%
Change-Id: Iab60e504dff5639e688dc5420d852f336508c0af
Reviewed-on: https://go-review.googlesource.com/c/go/+/166497
Run-TryBot: Mikio Hara <mikioh.public.networking@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
-mcmodel=large and -Wl,-bbigtoc must always be passed to gcc in order to
prevent TOC overflow error. However, a warning is still issued by ld. It
is removed as it doesn't give any useful information.
Change-Id: I95a78e8993cc7b5c0f329654d507409785f7eea6
Reviewed-on: https://go-review.googlesource.com/c/go/+/164008
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
DWARF relocations isn't working with some older ld, because of
-Wl,-bnoobjreorder which is needed on Go.
This commit checks ld's version and disable DWARF generation in cmd/link
if it's too old. Some tests must therefore be skipped.
Change-Id: I2e794c263eb0dfe0b42e7062fb80c26f086b44d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/164007
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
With math/big supporting underscores directly, there is no need to
manually remove them before calling the math/big conversion routines.
Updates #28493.
Change-Id: I6f865c8f87c3469ffd6c33f960ed540135055226
Reviewed-on: https://go-review.googlesource.com/c/go/+/166417
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The primary change is in nat.scan which now accepts underscores for base 0.
While at it, streamlined error handling in that function as well.
Also, improved the corresponding test significantly by checking the
expected result values also in case of scan errors.
The second major change is in scanExponent which now accepts underscores when
the new sepOk argument is set. While at it, essentially rewrote that
function to match error and underscore handling of nat.scan more closely.
Added a new test for scanExponent which until now was only tested
indirectly.
Finally, updated the documentation for several functions and added many
new test cases to clients of nat.scan.
A major portion of this CL is due to much better test coverage.
Updates #28493.
Change-Id: I7f17b361b633fbe6c798619d891bd5e0a045b5c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/166157
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Lines with single cells prompt a flush. Unfortunately, a call to
Writer.Flush also means two defers, which is an expensive operation to
do if many lines consist of single cells.
This is common when formatting code with aligned comments. Most lines
aren't going to have any comments at all, so the performance hit is
going to be noticeable.
The Write method already has a "defer handlePanic" of its own, so we
don't need to worry about panics leaking out. The error will now mention
"Write" instead of "Flush" if a panic is encountered during that nested
flush, but arguably that's a good thing; the user called Write, not
Flush.
For the reset call, add a non-deferred call as part of flushNoDefers, as
that's still necessary. Otherwise, the exported Flush method still does
a "defer b.reset".
The current tabwriter benchmarks are unaffected, since they don't
contain many single-cell lines, and because lines are written one at a
time. For that reason, we add a benchmark which has both of these
characteristics.
name old time/op new time/op delta
Code-8 2.72µs ± 0% 1.77µs ± 0% -34.88% (p=0.000 n=6+5)
name old alloc/op new alloc/op delta
Code-8 648B ± 0% 648B ± 0% ~ (all equal)
name old allocs/op new allocs/op delta
Code-8 13.0 ± 0% 13.0 ± 0% ~ (all equal)
Perhaps unsurprisingly, go/printer also gets a bit faster, as it too
buffers its output before writing it to tabwriter.
name old time/op new time/op delta
Print-8 6.53ms ± 0% 6.39ms ± 0% -2.22% (p=0.008 n=5+5)
Change-Id: Ie01fea5ced43886a9eb796cb1e6c810f7a810853
Reviewed-on: https://go-review.googlesource.com/c/go/+/166797
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
I typo'd this variable in CL 165745, and neither I, the reviewer, nor the TryBots noticed.
But the longtest builder noticed, and it's not happy about it.
Updates #30571
Change-Id: I5e3d267346407855ec0d1f340a72dc2c521ecc63
Reviewed-on: https://go-review.googlesource.com/c/go/+/167086
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This test invokes 'go build', so in module mode it needs a module
cache to guard edits to go.mod.
Fixes#30776
Change-Id: I89ebef1fad718247e7f972cd830e31d6f4a83e4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/167085
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The sheer length of the generated rules files makes my
editor and git client unhappy.
This change is a small step towards shortening them.
We recognize a few magic variables during rulegen: b, config, fe, typ.
Of these, only b appears prone to false positives.
By tightening the heuristic and fixing one case in MIPS.rules,
we can make the heuristic enough that it has no failures.
That allows us to remove the hedge assignments to _,
removing 3000 pointless lines of code.
Change-Id: I080cde5db28c8277cb3fd9ddcd829306c9a27785
Reviewed-on: https://go-review.googlesource.com/c/go/+/166979
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes#30123
Change-Id: I310b89a344a262bb758d39dfdd485ed2940cc6aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/166577
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
GOPATH/pkg contains, among other things, the module cache (and associated lockfiles).
Fixes#30776
Change-Id: I305cb3c0daab8cedd2e6ad235d4733f66af18723
Reviewed-on: https://go-review.googlesource.com/c/go/+/167082
Reviewed-by: Jay Conrod <jayconrod@google.com>
