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>
This was the last remaining use of staticbytes, so we can now
delete it.
The new code appears slightly faster on amd64:
name old time/op new time/op delta
SliceByteToString/1-4 6.29ns ± 2% 5.89ns ± 1% -6.46% (p=0.000 n=14+14)
This may not be the case on the big-endian architectures, since they have
to do an extra addition.
Updates #37612
Change-Id: Icb84c5911ba025f798de152849992a55be99e4f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/221979
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is one of several changes that were part of a larger rewrite
which I made in early 2019 after switching to the new number literal
syntax implementation. The purpose of the rewrite was to simplify
reading of source code (Unicode character by character) and speed up
the scanner but was never submitted for review due to other priorities.
Part 3 of 3:
This change contains a complete rewrite of source.go, the file that
implements reading individual Unicode characters from the source.
The new implementation is easier to use and has simpler literal
buffer management, resulting in faster scanner and thus parser
performance.
Thew new source.go (internal) API is centered around nextch() which
advances the scanner by one character. The scanner has been adjusted
around nextch() and now consistently does one character look-ahead
(there's no need for complicated ungetr-ing anymore). Only in one
case backtrack is needed (when finding '..' rather than '...') and
that case is now more cleanly solved with the new reset() function.
Measuring line/s parsing peformance by running
go test -run StdLib -fast -skip "syntax/(scanner|source)\.go"
(best of 5 runs on "quiet" MacBook Pro, 3.3GHz Dual-Core i7, 16GB RAM,
OS X 10.15.3) before and after shows consistently 3-5% improvement of
line parsing speed:
old: parsed 1788155 lines (3969 files) in 1.255520307s (1424234 lines/s)
new: parsed 1788155 lines (3969 files) in 1.213197037s (1473919 lines/s)
(scanner.go and parser.go are skipped because this CL changed those files.)
Change-Id: Ida947f4b538d42eb2d2349062c69edb6c9e5ca66
Reviewed-on: https://go-review.googlesource.com/c/go/+/221603
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This allows for zero stores to be performed using the zero register, rather
than loading a separate register with zero.
Change-Id: Ic81d8dbcdacbb2ca2c3f77682ff5ad7cdc33d18d
Reviewed-on: https://go-review.googlesource.com/c/go/+/221684
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
These changes fix go doc -src mode that vomits comments from random files if
filesystem does not sort files by name. The issue was with parse.ParseDir
using the Readdir order of files, which varies between platforms and filesystem
implementations. Another option is to merge comments using token.FileSet.Iterate
order in cmd/doc, but since ParseDir is mostly used in go doc, I’ve opted for
smaller change because it’s unlikely to break other uses or cause any perfomance
issues.
Example (macOS APFS): `go doc -src net.ListenPacket`
Change-Id: I7f9f368c7d9ccd9a2cbc48665f2cb9798c7b3a3f
GitHub-Last-Rev: 654fb45042
GitHub-Pull-Request: golang/go#36104
Reviewed-on: https://go-review.googlesource.com/c/go/+/210999
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This is one of several changes that were part of a larger rewrite
which I made in early 2019 after switching to the new number literal
syntax implementation. The purpose of the rewrite was to simplify
reading of source code (Unicode character by character) and speed up
the scanner but was never submitted for review due to other priorities.
Part 2 of 3:
This change contains improvements to the scanner error messages:
- Use "rune literal" rather than "character literal" to match the
spec nomenclature.
- Shorter, more to the point error messages.
(For instance, "more than one character in rune literal" rather
than "invalid character literal (more than one character)", etc.)
Change-Id: I1aaf79003374a68dbb05926437ed305cf2a8ec96
Reviewed-on: https://go-review.googlesource.com/c/go/+/221602
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is one of several changes that were part of a larger rewrite
which I made in early 2019 after switching to the new number literal
syntax implementation. The purpose of the rewrite was to simplify
reading of source code (Unicode character by character) and speed up
the scanner but was never submitted for review due to other priorities.
Part 1 of 3:
This change contains improvements to the scanner tests.
Change-Id: Iecfcaef00fdeb690b0db786edbd52e828417141b
Reviewed-on: https://go-review.googlesource.com/c/go/+/221601
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There are still two places in src/runtime/string.go that use
staticbytes, so we cannot delete it just yet.
There is a new codegen test to verify that the index calculation
is constant-folded, at least on amd64. ppc64, mips[64] and s390x
cannot currently do that.
There is also a new runtime benchmark to ensure that this does not
slow down performance (tested against parent commit):
name old time/op new time/op delta
ConvT2EByteSized/bool-4 1.07ns ± 1% 1.07ns ± 1% ~ (p=0.060 n=14+15)
ConvT2EByteSized/uint8-4 1.06ns ± 1% 1.07ns ± 1% ~ (p=0.095 n=14+15)
Updates #37612
Change-Id: I5ec30738edaa48cda78dfab4a78e24a32fa7fd6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/221957
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Increase the size of the signal stack as the value given by SIGSTKSZ
is too small for the Go signal handler.
Fixes#37609
Change-Id: I56f1006bc69a2a9fb43f9e0da00061964290a690
Reviewed-on: https://go-review.googlesource.com/c/go/+/221804
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trying this CL again, with a fixed test that allows platforms
to disagree on the exact behavior of converting NaNs.
We store 32-bit floating point constants in a 64-bit field, by
converting that 32-bit float to 64-bit float to store it, and convert
it back to use it.
That works for *almost* all floating-point constants. The exception is
signaling NaNs. The round trip described above means we can't represent
a 32-bit signaling NaN, because conversions strip the signaling bit.
To fix this issue, just forbid NaNs as floating-point constants in SSA
form. This shouldn't affect any real-world code, as people seldom
constant-propagate NaNs (except in test code).
Additionally, NaNs are somewhat underspecified (which of the many NaNs
do you get when dividing 0/0?), so when cross-compiling there's a
danger of using the compiler machine's NaN regime for some math, and
the target machine's NaN regime for other math. Better to use the
target machine's NaN regime always.
Update #36400
Change-Id: Idf203b688a15abceabbd66ba290d4e9f63619ecb
Reviewed-on: https://go-review.googlesource.com/c/go/+/221790
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The goal here is to make it easier for a human to
examine the SSA when a function contains lots of dead code.
No significant compiler metric or generated code differences.
Change-Id: I81915fa4639bc8820cc9a5e45e526687d0d1f57a
Reviewed-on: https://go-review.googlesource.com/c/go/+/221791
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
If an error occurs during the HTTP/2 upgrade phase, originally this
resulted in a pconn with pconn.alt set to an http2erringRoundTripper,
which always fails. This is not wanted - we want to retry in this case.
CL 202078 added a check for the http2erringRoundTripper to treat it
as a failed pconn, but the handling of the failure was wrong in the case
where the pconn is not in the idle list at all (common in HTTP/2).
This made the added test TestDontCacheBrokenHTTP2Conn flaky.
CL 218097 (unsubmitted) proposed to expand the handling of the
http2erringRoundTripper after the new check, to dispose of the pconn
more thoroughly. Bryan Mills pointed out in that review that we probably
shouldn't make the never-going-to-work pconn in the first place.
This CL changes the upgrade phase look for the http2erringRoundTripper
and return the underlying error instead of claiming to have a working
connection. Having done that, the CL undoes the change in CL 202078
and with it the need for CL 218097, but it keeps the new test added
by CL 202078.
On my laptop, before this commit, TestDontCacheBrokenHTTP2Conn
failed 66 times out of 20,000. With this commit, I see 0 out of 20,000.
Fixes#34978.
Fixes#35113.
Change-Id: Ibd908b63c2ae96e159e8e604213d8373afb350e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/220905
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change-Id: I1fd47e5eab27346cec488098d4f6102a0749bd28
Reviewed-on: https://go-review.googlesource.com/c/go/+/221788
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Convert subtraction of a constant into an ADDI with a negative immediate,
where possible.
Change-Id: Ie8d54b7538f0012e5f898abea233b2957fe31899
Reviewed-on: https://go-review.googlesource.com/c/go/+/221679
Reviewed-by: Cherry Zhang <cherryyz@google.com>
currently the snippet is segmented but should be one code snippet.
Change-Id: Ic747faf9bb1b52f9d1786eca70616a05b71ee801
Reviewed-on: https://go-review.googlesource.com/c/go/+/211198
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
The obj.Prog needs to be an obj.ARET rather than an obj.AJMP, otherwise the
epilogue does not get correctly produced.
Change-Id: Ie1262f2028d3b51720eeb0364a627fbde8b14df9
Reviewed-on: https://go-review.googlesource.com/c/go/+/221683
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Changed the flag variable name to nFlag instead of flagname,
because flagname was confusing.
Change-Id: I20dd4c4b4f605395d427a125ba4fd14580e5d766
Reviewed-on: https://go-review.googlesource.com/c/go/+/221678
Reviewed-by: Rob Pike <r@golang.org>
Make panics more useful by printing values, if their
underlying kind is printable, instead of just their memory address.
Thus now given any custom type derived from any of:
float*, int*, string, uint*
if we have panic with such a result, its value will be printed.
Thus given any of:
type MyComplex128 complex128
type MyFloat64 float64
type MyString string
type MyUintptr uintptr
panic(MyComplex128(32.1 + 10i))
panic(MyFloat64(-93.7))
panic(MyString("This one"))
panic(MyUintptr(93))
They will now print in the panic:
panic: main.MyComplex64(+1.100000e-001+3.000000e+000i)
panic: main.MyFloat64(-9.370000e+001)
panic: main.MyString("This one")
panic: main.MyUintptr(93)
instead of:
panic: (main.MyComplex128) (0xe0100,0x138cc0)
panic: (main.MyFloat64) (0xe0100,0x138068)
panic: (main.MyString) (0x48aa00,0x4c0840)
panic: (main.MyUintptr) (0xe0100,0x137e58)
and anything else will be printed as in the past with:
panic: (main.MyStruct) (0xe4ee0,0x40a0e0)
Also while here, updated the Go1.15 release notes.
Fixes#37531
Change-Id: Ia486424344a386014f2869ab3483e42a9ef48ac4
Reviewed-on: https://go-review.googlesource.com/c/go/+/221779
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestStdLib reports parsed lines and lines/s information. To make
it easier to compare apples to apples when making changes in the
std lib, a regular expression provided via the -skip flag filters
files we don't want to process.
Change-Id: I27d9c32032eac4e78581205892e4f26947c91bd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/221600
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
After fixing #37081 we don't need to explicitly keep track of
field collisions in the method set computation anymore; we only
need to know which field (names) exists at each embedding level.
Simplify the code by removing the dedicated fieldSet data type
in favor of a simple string set.
Follow-up on https://golang.org/cl/218617; separate CL to make it
easier to identify a problem with these two changes, should there
be one.
Updates #37081.
Change-Id: I5c259c63c75a148a42d5c3e1e4860e1ffe5631bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/218618
Reviewed-by: Alan Donovan <adonovan@google.com>
When computing method sets, any struct field that "shadows" a
method at a lower embedding level eliminates that method from
the method set. Treat any field at a given level as a "collision"
for any methods at lower embedding level.
Method sets are not directly used by go/types (except for self-
verification in debug mode); they are a functionality provided
by go/types. Thus, the method sets that go/types is using were
not affected by this bug.
Fixes#37081.
Change-Id: Ic1937e01891b3614a6f7965d4384aeb485f3fe3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/218617
Reviewed-by: Alan Donovan <adonovan@google.com>
This change adds the option to run the ssa checker with a random seed.
The current system uses a completely fixed seed,
which is good for reproducibility but bad for exploring the state space.
Preserve what we have, but also provide a way for the caller
to provide a seed. The caller can report the seed
alongside any failures.
Change-Id: I2676a8112d8260e6cac86d95d2e8db4d3221aeeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/216418
Reviewed-by: Keith Randall <khr@golang.org>
Const64 gets lowered to MOVDconst.
Change rules using interior Const64 to use MOVDconst instead,
to be less dependent on rule application order.
As a result of doing this, some of the rules end up being
exact duplicates; remove those.
We had those exact duplicates because of the order dependency;
ppc64 had no way to optimize away shifts by a constant
if the initial lowering didn't catch it.
Add those optimizations as well.
The outcome is the same, but this makes the overall rules more robust.
Change-Id: Iadd97a9fe73d52358d571d022ace145e506d160b
Reviewed-on: https://go-review.googlesource.com/c/go/+/220877
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Print the bytes of the instruction that generated a SIGILL.
This should help us respond to bug reports without having to
go back-and-forth with the reporter to get the instruction involved.
Might also help with SIGILL problems that are difficult to reproduce.
Update #37513
Change-Id: I33059b1dbfc97bce16142a843f32a88a6547e280
Reviewed-on: https://go-review.googlesource.com/c/go/+/221431
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In cases in which we had a named value whose args were all _,
like this rule from ARM.rules:
(MOVBUreg x:(MOVBUload _ _)) -> (MOVWreg x)
We previously inserted
_ = x.Args[1]
even though it is unnecessary.
This change eliminates this pointless bounds check.
And in other cases, we now check bounds just as far as strictly necessary.
No significant movement on any compiler metrics.
Just nicer (and less) code.
Passes toolstash-check -all.
Change-Id: I075dfe9f926cc561cdc705e9ddaab563164bed3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/221781
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Test all the paths by which a Hash picks its seed.
Make sure they all behave identically to a preset seed.
Change-Id: I2f7950857697f2f07226b96655574c36931b2aae
Reviewed-on: https://go-review.googlesource.com/c/go/+/220686
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Vladimir Evgrafov <evgrafov.vladimir@gmail.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This:
* Simplifies and shortens the generated code for rewrite rules.
* Shrinks cmd/compile by 86k (0.4%) and makes it easier to compile.
* Removes the stmt boundary code wrangling from Value.reset,
in favor of doing it in the one place where it actually does some work,
namely the writebarrier pass. (This was ascertained by inspecting the
code for cases in which notStmtBoundary values were generated.)
Passes toolstash-check -all.
Change-Id: I25671d4c4bbd772f235195d11da090878ea2cc07
Reviewed-on: https://go-review.googlesource.com/c/go/+/221421
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Issue #37598 reports a nil-panic in *Client.send that can
only occur if one of the RoundTripper invariants is violated.
Unfortunately, that condition is currently difficult to diagnose: it
manifests as a panic during a Response field access, rather than
something the user can easily associate with an specific erroneous
RoundTripper implementation.
No test because the new code paths are supposed to be unreachable.
Updates #37598
Change-Id: If0451e9c6431f6fab7137de43727297a80def05b
Reviewed-on: https://go-review.googlesource.com/c/go/+/221818
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL documents that unsynchronized send and close operations
on a channel are detected as a race condition.
Fixes#27769
Change-Id: I7495a2d0dd834c3f3b6339f8ca18ea21ae979aa8
Reviewed-on: https://go-review.googlesource.com/c/go/+/219637
Reviewed-by: Rob Pike <r@golang.org>
Like in x/sys/cpu, use anonymous structs to declare the CPU feature vars
instead of defining single-use types. Also, order the vars
alphabetically.
Change-Id: Iedd3ca51916e3cbb852d2aeed18b3a4c6613e778
Reviewed-on: https://go-review.googlesource.com/c/go/+/221757
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Currently, the time.Format docs use 7 Mar 2015 as the day/month/year. In numeric
form, that is either 7/3/2015 or 3/7/2015 depending on which part of the world
you're from. This is extremely confusing.
In fact, the reference time being defined in a very US-centric way is quite
confusing for the rest of the world, too [1].
We can't change that, but we can make the time.Format docs more comprehendable
to the rest of the world without sacrificing by simply choosing a day that is
not ambiguous (a value greater than 24 for day). This CL does makes the
necessary change.
Note: this CL moves some of the padding examples into their own example, since
those examples do need a <10 day to demonstrate padding.
1: Additional context: a very old golang-nuts thread in which Rob expresses some
regret about the format being the USA standard, rather than the alternative:
https://groups.google.com/forum/m/#!msg/golang-nuts/0nQbfyNzk9E/LWbMgpRQNOgJ.
Change-Id: If0a07c5e0dab86f8420cbf59543405eb857aa7f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/221612
Run-TryBot: Jean de Klerk <deklerk@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
When we seek on the underlying FD, discard any directory entries
we've already read and cached. This makes sure we won't return
the same entry twice.
We already fixed this for Darwin in CL 209961.
Fixes#37161
Change-Id: I20e1ac8d751443135e67fb4c43c18d69befb643b
Reviewed-on: https://go-review.googlesource.com/c/go/+/219143
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing documentation is improved to be more
explicit about the lifecycle and its consequences.
Fixes#34324
Change-Id: I9969afc69f6eeb7812c11fe821a842794df5aa5b
GitHub-Last-Rev: 246a499166
GitHub-Pull-Request: golang/go#34551
Reviewed-on: https://go-review.googlesource.com/c/go/+/197458
Reviewed-by: Richard Musiol <neelance@gmail.com>
