In a recent change CL 388654 a function was updated so it
no longer needed stack space, but the TEXT statement was
not updated to reflect that change. This corrects that problem.
Change-Id: I9e60cebddae620788b1097ab7b39c47b323d1f62
Reviewed-on: https://go-review.googlesource.com/c/go/+/389674
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
For #51153
Change-Id: I4374c63498b62ba7a08f146eebd034cbd50623f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/389634
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
It's more trouble than it's worth. New code should be using x/sys/unix
anyhow.
Fixes#40564Fixes#51479
Change-Id: I1c0e13f494380c1565e98359f088af9f52790b79
Reviewed-on: https://go-review.googlesource.com/c/go/+/390020
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
An extra "go build" was happening, for the sake of -tags=testgo,
which would insert some extra behavior into ./internal/work.
Instead, reuse the test binary as cmd/go directly,
by calling the main func when a special env var is set.
We still duplicate the test binary into testBin,
because we need a "go" executable in that directory for $PATH.
Finally, the special behavior is instead inserted via TestMain.
The numbers below represent how long it takes to run zero tests,
measured via:
benchcmd GoTestNothing go test -run=-
That is, the time it takes to run the first test is reduced by half.
Note that these numbers are on a warm build cache,
so if the -tags=testgo build were to be done from scratch,
the speed-up would be significantly more noticeable.
name old time/op new time/op delta
GoTestNothing 830ms ± 2% 380ms ± 7% -54.23% (p=0.008 n=5+5)
name old user-time/op new user-time/op delta
GoTestNothing 1.64s ± 1% 0.82s ± 3% -50.24% (p=0.008 n=5+5)
name old sys-time/op new sys-time/op delta
GoTestNothing 306ms ± 7% 159ms ±28% -48.15% (p=0.008 n=5+5)
name old peak-RSS-bytes new peak-RSS-bytes delta
GoTestNothing 173MB ± 1% 147MB ± 1% -14.96% (p=0.008 n=5+5)
Change-Id: I1f8fc71269a7b45bc5b82b7228e13f56589d44c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/378294
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This should be a bit faster and slicker than the very old ANSI X9.31,
which relied on the system time. Uses AES instead of ChaCha because it's
in the standard library.
Reference: https://blog.cr.yp.to/20170723-random.html
Reference: https://github.com/jedisct1/supercop/blob/master/crypto_rng/aes256/ref/rng.c
Change-Id: Ib7b37a83cca29f5d346355b7cb8cfe5250086b95
Reviewed-on: https://go-review.googlesource.com/c/go/+/375215
Trust: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
The X9.31 expander is now only used for plan9. Perhaps once upon a time
there was a use for abstraction, but the code is now covered in hacky
"fileName == urandomDevice" and "GOOS == plan9" checks, to the point
where the abstraction is much too leaky. Since plan9 is the only
platform that has a /dev/random without a /dev/urandom, we can simplify
both the generic urandom code and the plan9 X9.31 code by separating
them into different files, each focusing on doing one thing well.
Change-Id: I0ca43b748a0fbbd60f2ec7819688a540506d34df
Reviewed-on: https://go-review.googlesource.com/c/go/+/370580
Trust: Jason Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Otherwise, the behavior of 'go work use -r' (without arguments)
may be surprising.
Change-Id: I50cf1339591720ec5bd333146b89c9944ce420d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/389855
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
On Linux, the minimum required kernel version for Go 1.18 was be changed
to 2.6.32, see #45964. The pipe2 syscall was added in 2.6.27.
All other platforms already provide the pipe2 syscall in the minimum
supported version:
- DragonFly BSD added it in version 4.2, see
https://www.dragonflybsd.org/release42/
- FreeBSD added it in version 10.0, see
https://www.freebsd.org/cgi/man.cgi?pipe(2)#end
- NetBSD added it in version 6.0, see
https://man.netbsd.org/pipe2.2#HISTORY
- OpenBSD added it in version 5.7, see
https://man.openbsd.org/pipe.2#HISTORY
- Illumos supports it since 2013, see
https://www.illumos.org/issues/3714
- Solaris supports it since 11.4
This also allows to remove setNonblock which was only used in the pipe
fallback path on these platforms.
Change-Id: I1f40d32fd3065d74e22af77b9ff2292b9cf66706
Reviewed-on: https://go-review.googlesource.com/c/go/+/389354
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The finalizer is called using reflectcall. When register ABI is
used, the finalizer's argument is passed in register(s). But the
frame size calculation does not include the spill slot. When the
argument actually spills, it may clobber the caller's stack frame.
This CL fixes it.
Change-Id: Ibcc7507c518ba65c1c5a7759e5cab0ae3fc7efce
Reviewed-on: https://go-review.googlesource.com/c/go/+/389574
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Both endians perform syscalls similarly. Only CR0S0 and R3 hold
the resultant status of a syscall. A random value may be stored into
the second return value (r2) result in some cases. Always set it to
zero.
Fixes#51192
Change-Id: Ida6a5692578d2cdadf3099af28478b3bc364f623
Reviewed-on: https://go-review.googlesource.com/c/go/+/385796
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Paul Murphy <murp@ibm.com>
CL 386017 added new API for encoding/binary package.
This file was accidentally not updated in the same CL.
Updates #50601
Change-Id: Iefeb596ba04b8c6576cf0fe42030f658a5848832
Reviewed-on: https://go-review.googlesource.com/c/go/+/389636
Trust: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Also correct scope position for such variables.
Adjusted some comments.
Fixes#51437.
Change-Id: Ic49a1459469c8b2c7bc24fe546795f7d56c67cb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/389594
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Findley <rfindley@google.com>
The preferred form of nop is ori 0,0,0. What was being generated was
or 0,0,0.
Fix a quirk in the assembler which effectively treats OR $0,Rx,Ry as
OR R0,Rx,Ry, and update the compiler to generate the preferred form.
Change-Id: I5ac4bf0258cff05b9eba516a767daebfc9e31bc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388974
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Paul Murphy <murp@ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Workaround the minor endian differences, and avoid needing to
stack a frame as extra VSRs can be used in a similar capacity.
The microbenchmarks show no significant differences on ppc64le/p9.
ppc64/linux performance difference on a POWER9:
name old time/op new time/op delta
Hash8Bytes 686ns ± 0% 372ns ± 0% -45.78%
Hash1K 9.17µs ± 0% 4.24µs ± 0% -53.74%
Hash8K 67.9µs ± 0% 31.7µs ± 0% -53.35%
Fixes#50785
Change-Id: I43d87670127df9767d54d10b5165b84e5b88f5d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/380776
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Paul Murphy <murp@ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The existing codegen strategy in sort.go relied on parsing the sort.go source
with go/ast and a combination of an AST rewrite + code text rewrite with regexes
to generate zfuncversion -- the same sort functionality with a different variant
of data.
In preparation for implementing #47619, we need a more robust codegen
strategy. To generate variants required for the generic sort functions
in the slices package, we'd need significanly more complicated AST
rewrites, which would make genzfunc.go much heavier.
Instead, redo the codegen strategy to use text/template instead of AST rewrites.
gen_sort_variants.go now contains the code for the underlying sort functions,
and generates multiple versions of them based on Variant configuration structs.
With this approach, adding new variants to generate generic sort functions for
the slices package becomes trivial.
See the discussion in #47619 for more details on the design decisions.
Change-Id: I8af784c41b1dc8ef92aaf6321359e8faa5fe106c
Reviewed-on: https://go-review.googlesource.com/c/go/+/353069
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Than McIntosh <thanm@google.com>
This adds an asm implementation of aes-cbc for ppc64le to
improve performance. This is ported from the
cryptogams implementation as are other functions in
crypto/aes with further description at the top of
the asm file.
Improvements on a power10:
name old time/op new time/op delta
AESCBCEncrypt1K 1.67µs ± 0% 0.87µs ±-48.15%
AESCBCDecrypt1K 1.35µs ± 0% 0.43µs ±-68.48%
name old speed new speed delta
AESCBCEncrypt1K 614MB/s ± 0% 1184MB/s ± 0%+92.84%
AESCBCDecrypt1K 757MB/s ± 0% 2403M/s ± 0 +217.21%
A fuzz test to compare the generic Go implemenation
against the asm implementation has been added.
Change-Id: I18613dfc95c640820b8f1c60d29df638efc7a75c
Reviewed-on: https://go-review.googlesource.com/c/go/+/355429
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Paul Murphy <murp@ibm.com>
Trust: Paul Murphy <murp@ibm.com>
Async preemption needs to save and restore almost all of the registers,
currently this is done by ldr and str on arm64. We can do it with ldp
and stp as they are more efficient.
Change-Id: Ida5a6f0a8d825a56af607ba2c2cd91fdc2e8f67f
Reviewed-on: https://go-review.googlesource.com/c/go/+/379715
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Advertise to DNS resolvers that we are willing and able to accept up
to 1232 bytes in a DNS packet. The value 1232 was chosen based on
https://dnsflagday.net/2020/.
For #6464
For #21160
For #44135
For #51127Fixes#51153
Change-Id: If9182d5210bfe047cf0a4d46163effc6812ab677
Reviewed-on: https://go-review.googlesource.com/c/go/+/386016
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL is a bit overkill, but it is pretty safe for 1.18. We'll
want to revisit for 1.19 so we can avoid the hash collisions between
types, e.g. G[int] and G[float64], that will cause some slowdowns
(but not incorrect behavior). Thanks Cherry for the simple idea.
Fixes#51250
Change-Id: I68130e09ba68e7cc35687bc623f63547bc552867
Reviewed-on: https://go-review.googlesource.com/c/go/+/389474
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This template is based on CL 342070 and previous ones like it.
Continue to eagerly include often-used sections, and clarify that
the TODO is about completing the section, or removing if it turns
out not to be needed.
Move the Go 1.18 release notes to x/website, since that's the new
home for past Go release notes as of CL 291711. They're added to
x/website in CL 388556.
For #51400
Updates #47694
Change-Id: I7b5213e039ad6e14a7ff7ad486311efcecc06824
Reviewed-on: https://go-review.googlesource.com/c/go/+/388515
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Go 1 compatibility guarantee permits us to break code if there is
a specification error or a bug. Emphasize that for generics.
Change-Id: I8379a14cdab9f63bb747e961ca12d1adecfc2eb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/388454
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
This adds big endian support for the assembly implementation of
sha512. There was a recent request to do this for sha256 for
AIX users; for completeness, the same is being done for sha512.
The majority of the code is common between big and little
endian with a few differences controlled by ifdefs: with LE
the generation of a mask is needed along with VPERM instructions
to put bytes in the correct order; some VPERMs need the V
registers in a different order.
name old time/op new time/op delta
Hash8Bytes 1.02µs ± 0% 0.38µs ± 0% -62.68%
Hash1K 7.01µs ± 0% 2.43µs ± 0% -65.42%
Hash8K 50.2µs ± 0% 14.6µs ± 0% -70.89%
Updates #50785
Change-Id: I739b5e7c07b22b5748af11ca781e82ac67adb4f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388654
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
AppendByteOrder specifies new methods for LittleEndian and BigEndian
for appending an unsigned integer to a byte slice.
The performance of AppendXXX methods are slower than PutXXX methods
since the former needs to do a few slice operations,
while the latter is essentially a single integer store.
In practice, existing usages of PutXXX performed slicing operations
around the call such that this cost was present, regardless.
name time/op
PutUint16-24 0.48ns ± 2%
AppendUint16-24 1.54ns ± 1%
PutUint32-24 0.46ns ± 2%
AppendUint32-24 0.89ns ± 1%
PutUint64-24 0.46ns ± 2%
AppendUint64-24 0.89ns ± 1%
LittleEndianPutUint16-24 0.47ns ± 2%
LittleEndianAppendUint16-24 1.54ns ± 1%
LittleEndianPutUint32-24 0.45ns ± 3%
LittleEndianAppendUint32-24 0.92ns ± 2%
LittleEndianPutUint64-24 0.46ns ± 3%
LittleEndianAppendUint64-24 0.95ns ± 4%
Fixes#50601
Change-Id: I33d2bbc93a3ce01a9269feac33a2432bc1166ead
Reviewed-on: https://go-review.googlesource.com/c/go/+/386017
Trust: Joseph Tsai <joetsai@digital-static.net>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Modify Value.Bytes to be callable addressable byte arrays.
While related, the behavior of Value.SetBytes was not modified.
Fixes#47066
Change-Id: Ic3ba4432353b8da5f33b3188e20034a33b2f6ee8
Reviewed-on: https://go-review.googlesource.com/c/go/+/357331
Trust: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
accept is no longer used on Linux since CL 346849 changed Accept to use
accept4 only.
For #45964
Change-Id: I72c13df1457016c4785ec13d356ab89cbca644b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/386415
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The latter returns a uintptr, while the former returns a unsafe.Pointer.
A uintptr is unsafe if Go ever switches to a moving GC,
while a unsafe.Pointer will be properly tracked by the GC.
We do not use unsafe.Pointer for any unsafe type conversions,
and only use it for comparability purposes, which is relatively safe.
Updates #40592
Change-Id: I813e218668704b63a3043acda4331205a3835a66
Reviewed-on: https://go-review.googlesource.com/c/go/+/360855
Trust: Joseph Tsai <joetsai@digital-static.net>
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
For cases where RFC 1952 requires a field, the code returns the error
io.ErrUnexpectedEOF except in two places: for the FNAME flag or the
FCOMMENT flag. These flags expect a null-terminated string and
readString may return an EOF if the Reader is truncated before a
null byte is found. For consistency with parsing other parts of the
header, this is converted to an unexpected EOF herein.
Follow-up to CL 14832.
Fixes#51417
Change-Id: I173283a6ae309e4a8e52fc15df404ce5db06eff1
GitHub-Last-Rev: 2e573cd961
GitHub-Pull-Request: golang/go#51418
Reviewed-on: https://go-review.googlesource.com/c/go/+/389034
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Trust: Joseph Tsai <joetsai@digital-static.net>
Trust: Ian Lance Taylor <iant@golang.org>
cmd/compile uses "noalg.struct {...}" as type name when hash and eq algorithm generation of this struct type is suppressed. This should be treated as normal struct type, that is, link shouldn't generate DW_TAG_typedef DIE for it.
Change-Id: Ifada8a818bcfa2e5615f85ead9582cead923b86c
GitHub-Last-Rev: 15de3e4a84
GitHub-Pull-Request: golang/go#50237
Reviewed-on: https://go-review.googlesource.com/c/go/+/373054
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Correct the slice expression in the description of Index functions.
Change-Id: I97a1b670c4c7e600d858f6550b647f677ef90b41
Reviewed-on: https://go-review.googlesource.com/c/go/+/360058
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
The benchmarks added in this change revealed that ValidString
runs ~17% faster than Valid([]byte) on the ASCII prefix
of the input. Inspection of the assembly revealed that the
code generated for p[8:] required recomputing the slice capacity
to handle the cap=0 special case, which added an ADD -8 instruction.
By making len=cap, the capacity becomes a common subexpression
with the length, saving the ADD instruction.
(Thanks to khr for the tip.)
Incidentally, I tried a number of other optimizations but was
unable to make consistent gains across all benchmarks. The most
promising was to retain the bitmask of non-ASCII bytes from the
fast loop; the slow loop would shift it, and when it becomes zero,
return to the fast loop. This made the MostlyASCII benchmark 4x
faster, but made the other cases slower by up to 10%.
cpu: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
benchmark old ns/op new ns/op delta
BenchmarkValidTenASCIIChars-16 4.09 4.06 -0.85%
BenchmarkValid100KASCIIChars-16 9325 7747 -16.92%
BenchmarkValidTenJapaneseChars-16 27.0 27.2 +0.85%
BenchmarkValidLongMostlyASCII-16 57277 58361 +1.89%
BenchmarkValidLongJapanese-16 94002 93131 -0.93%
BenchmarkValidStringTenASCIIChars-16 4.15 4.07 -1.74%
BenchmarkValidString100KASCIIChars-16 7980 8019 +0.49%
BenchmarkValidStringTenJapaneseChars-16 26.0 25.9 -0.38%
BenchmarkValidStringLongMostlyASCII-16 58550 58006 -0.93%
BenchmarkValidStringLongJapanese-16 97964 100038 +2.12%
Change-Id: Ic9d585dedd9af83c27dd791ecd805150ac949f15
Reviewed-on: https://go-review.googlesource.com/c/go/+/375594
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Alex Rakoczy <alex@golang.org>
If name is empty or a keyword, we can skip the loop entirely.
Otherwise, we do the same amount of work as before.
Here is the benchmark result for go/parser:
name old time/op new time/op delta
Parse-12 2.53ms ± 2% 2.47ms ± 1% -2.38% (p=0.000 n=9+10)
ParseOnly-12 1.97ms ± 1% 1.93ms ± 2% -1.80% (p=0.000 n=10+10)
Resolve-12 560µs ± 1% 558µs ± 1% ~ (p=0.200 n=9+8)
name old speed new speed delta
Parse-12 26.1MB/s ± 2% 26.8MB/s ± 1% +2.44% (p=0.000 n=9+10)
ParseOnly-12 33.6MB/s ± 1% 34.3MB/s ± 2% +1.82% (p=0.000 n=10+10)
Resolve-12 118MB/s ± 2% 119MB/s ± 1% ~ (p=0.116 n=10+8)
Change-Id: I87ac9c2637a6c0e697382b74245ac88ef523bba7
GitHub-Last-Rev: 036bc38d83
GitHub-Pull-Request: golang/go#48534
Reviewed-on: https://go-review.googlesource.com/c/go/+/351389
Trust: David Chase <drchase@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Robert Griesemer <gri@golang.org>
Confirm that the current implementation of core type unification
looks correct and update the respective comment. Add an extra test.
Fixes#51376.
Change-Id: I6a603a4baeee2ede5bb4a1d60766204a808936d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388294
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When doing constraint type inference, we must consider whether the
constraint's core type is precise (no tilde) or imprecise (tilde,
or not a single specific type). In the latter case, we cannot infer
an unknown type argument from the (imprecise) core type because there
are infinitely many possible types. For instance, given
[E ~byte]
if we don't know E, we cannot infer that E must be byte (it could be
myByte, etc.). On the other hand, if we do know the type argument,
say for S in this example:
[S ~[]E, E any]
we must consider the underlying type of S when matching against ~[]E
because we have a tilde.
Because constraint type inference may infer type arguments that were
not eligible initially (because they were unknown and the core type
is imprecise), we must iterate the process until nothing changes any-
more. For instance, given
[S ~[]E, M ~map[string]S, E any]
where we initially only know the type argument for M, we must ignore
S (and E) at first. After one iteration of constraint type inference,
S is known at which point we can infer E as well.
The change is large-ish but the actual functional changes are small:
- There's a new method "unknowns" to determine the number of as of yet
unknown type arguments.
- The adjCoreType function has been adjusted to also return tilde
and single-type information. This is now conveniently returned
as (*term, bool), and the function has been renamed to coreTerm.
- The original constraint type inference loop has been adjusted to
consider tilde information.
- This adjusted original constraint type inference loop has been
nested in another loop for iteration, together with some minimal
logic to control termination.
The remaining changes are modifications to tests:
- There's a substantial new test for this issue.
- Several existing test cases were adjusted to accomodate the
fact that they inferred incorrect types: tildes have been
removed throughout. Most of these tests are for pathological
cases.
- A couple of tests were adjusted where there was a difference
between the go/types and types2 version.
Fixes#51229.
Change-Id: If0bf5fb70ec22913b5a2da89adbf8a27fbc921d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/387977
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently we only include static entries in the hint for sizing
the map when allocating a map for a map literal. Change that to
include all entries.
This will be an overallocation if the dynamic entries in the map have
equal keys, but equal keys in map literals are rare, and at worst we
waste a bit of space.
Fixes#43020
Change-Id: I232f82f15316bdf4ea6d657d25a0b094b77884ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/383634
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Especially once this code gets copied into x/tools, we need a way to
evolve the file format, so add an explicit version number.
Change-Id: I9cc2e357c3ca3f07fd8d0c0ba4e4a95f89edeac6
Reviewed-on: https://go-review.googlesource.com/c/go/+/388914
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
We use AutogeneratedPos for most compiler-generated functions. But
for method value wrappers we currently don't. Instead, we use the
Pos for their (direct) declaration if there is one, otherwise
not set it in methodValueWrapper, which will probably cause it to
inherit from the caller, i.e. the Pos of that method value
expression. If that Pos has inline information, it will cause the
method wrapper to have bogus inline information, which could lead
to infinite loop when printing a stack trace.
Change it to use AutogeneratedPos instead.
Fixes#51401.
Change-Id: I398dfe85f9f875e1fd82dc2f489dab63ada6570d
Reviewed-on: https://go-review.googlesource.com/c/go/+/388794
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This test case is failing on the noopt builder, because it disables
inlining. Evidently the explicit -gcflags flag in all of our generics
tests was overriding the noopt builder's default mode.
This CL restores a noop -gcflags to get the builder green again until
the issue can be properly fixed.
Updates #51413.
Change-Id: I61d22a007105f756104ba690b73f1d68ce4be281
Reviewed-on: https://go-review.googlesource.com/c/go/+/388894
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
ir.PkgName was only used by the old -G=0 frontend for representing
identifiers that refer to a package name. The new types2-based
frontends directly resolve the qualified identifier to the respective
object during IR construction.
Similarly, most of the ir.*Type nodes were only needed for
representing types in the IR prior to type checking. The new
types2-based frontends directly construct the corresponding types.Type
instead.
Exception: The internal typecheck.DeclFunc API used for
compiler-generated functions still depends on ir.FuncType, so that IR
node type is retained for now. (Eventually, we should update
typecheck.DeclFunc and callers to not depend on it, but it's not
urgent.)
Change-Id: I982f1bbd41eef5b42ce0f32676c7dc4a8ab6d0ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/388538
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The typechecking code for dealing with dot imports and redeclaration
errors can be removed, as these will now always be caught by types2
instead. Even when running the typecheck on internally constructed IR,
we'll never introduce new imports or redeclare identifiers.
Also, Func.Shortname (and typecheck.addmethod) was only used by the
-G=0 frontend. The new types2-based frontends directly associate
methods with their receiver type during IR construction.
Change-Id: I6578a448412141c87a0a53a6566639d9c00eeed7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388537
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
