Currently, for version errors, types2 adds the helpful hint
(-lang was set to go1.xx; check go.mod)
where 1.xx is the respective language version, to the error message.
This requires that the type checker knows that it was invoked by the
compiler, which is done through the Config.CompilerErrorMessages flag.
This change looks for version errors being returned by the type checker
and then adds the hint at that point, external to the type checker.
This removes a dependency on the Config.CompilerErrorMessages. Once
we have removed all dependencies on Config.CompilerErrorMessages we
can remove it.
For #55326.
Change-Id: I1f9b2e472c49fe785a2075e26c4b3d9b8fcdbf4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/432559
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
A linear search through a list of 22 strings takes ~80ns.
A quick check for 3-4 byte strings reduces this check to 2ns
for a vast majority of inputs.
In the event of a name match, the new logic is either just
as fast (for "CON") or 10x faster (for "LPT9").
Change-Id: I412fa73beebd7c81dc95f9ed12c35ca1d5d6baf0
Reviewed-on: https://go-review.googlesource.com/c/go/+/433175
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Pprof's converter from legacy text format to protobuf format
assumes that if the alloc and inuse stats are equal, then what's
really going on is that the program makes no distinction, and it
reads them as a two-column profile: objects and bytes.
Most of the time, some sampled object has been freed, and alloc != inuse.
In that case, pprof reads the profile as a four-column profile, with
alloc_objects, alloc_bytes, inuse_objects, inuse_bytes.
The 2-column form causes problems in a few ways. One is that if
you are reading the proto form and expect samples with the 4-column
names, they're not there. Another is that pprof's profile merger insists
on having the same number of columns and same names. This means
that
pprof *.memprofile
works most of the time but fails if one of the memory profiles hit
the unlikely condition that alloc == inuse, since now its converted
form differs from the others.
Most programs should simply not be using this output form at all,
but cmd/compile and cmd/link still do, because x/tools/cmd/compilebench
reads some extra values from the text form that we have not yet added
to the proto form.
For the programs still writing this form, the easiest way to avoid the
column collapse issues is to ensure that the header never reports
alloc == inuse. The actual values in the header are ignored by pprof now,
except for the equality check (they should sum to the other values in the
file, so they are technically redundant). Because the actual values are not
used except for the equality check, we could hard-code different values
like 0 and 1, but just in case, to break as little as possible, this CL only
adjusts the values when they would otherwise be equal. In that case it
adds 1 to allocBytes. For most profiles, where alloc != inuse already, there
is no effect at all.
Change-Id: Ia563e402573d0f6eb81ae496645db27c08f9fe31
Reviewed-on: https://go-review.googlesource.com/c/go/+/432758
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
For PIE binaries, the .gopclntab section doesn't have the usual
name, but .data.rel.ro.gopclntab. Try the relro version as well.
If both failed (e.g. for externally linked PIE binaries), try
runtime.pclntab symbol.
This should make cmd/objdump able to print the file/line
information for PIE binaries.
I attempted to do this a few years ago, but that wasn't enough,
because the pclntab itself contains dynamic relocations which are
not applied by the tool. As of Go 1.18 the pclntab is mostly
position independent and does not contain dynamic relocations, so
this should be possible now.
Fixes#17883.
Updates #46639.
Change-Id: I85dc3d50ffcc1a4b187a349479a6a162de1ab2b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/227483
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
After CL 22425, there're two optimizations for slice expr which are
never applied during walk pass:
s[i:len(s)]
s[i:j:cap(s)]
The order pass have already rewritten len/cap expression to use autotmp,
thus the same safe expression check will never fire. The code can now be
simplified by moving the only case left from reduceSlice to walkSlice,
then removing reduceSlice entirely.
Passes toolstash-check.
Change-Id: Ia8cfb15c8e96c186a214c17b42d0fee51b0d3a1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/432695
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
cmd/dist can't easily hard-code -buildvcs=false because not all
versions of cmd/go supported for bootstrapping recognize that flag.
However, we don't want to stamp the bootstrap binaries: the stamping
is redundant with the VERSION file writted during bootstrapping (which
is why it is normally omitted for standard-library packages and
commands), and it may also interfere with building the Go repo from a
source tarball or zip file.
Fixes#54852.
Change-Id: If223f094af137c4c202d6bf622619bd2da397ec4
Reviewed-on: https://go-review.googlesource.com/c/go/+/432435
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
RFC 7231 permits HEAD requests to contain a body, although it does
state there are no defined semantics for payloads of HEAD requests
and that some servers may reject HEAD requests with a payload.
Accept HEAD requests with a body.
Fix a bug where a HEAD request with a chunked body would interpret
the body as the headers for the next request on the connection.
For #53960.
Change-Id: I83f7112fdedabd6d6291cd956151d718ee6942cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/418614
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This commit adds an ASCII fast path to bytes/strings EqualFold that
roughly doubles performance when all characters are ASCII.
It also changes strings.EqualFold to use `for range` for the first
string since this is ~10% faster than using utf8.DecodeRuneInString for
both (see #31666).
Performance (similar results on arm64 and amd64):
name old time/op new time/op delta
EqualFold/Tests-10 238ns ± 0% 172ns ± 1% -27.91% (p=0.000 n=10+10)
EqualFold/ASCII-10 20.5ns ± 0% 9.7ns ± 0% -52.73% (p=0.000 n=10+10)
EqualFold/UnicodePrefix-10 86.5ns ± 0% 77.6ns ± 0% -10.37% (p=0.000 n=10+10)
EqualFold/UnicodeSuffix-10 86.8ns ± 2% 71.3ns ± 0% -17.88% (p=0.000 n=10+8)
Change-Id: I058f3f97a08dc04d65af895674d85420f920abe1
Reviewed-on: https://go-review.googlesource.com/c/go/+/425459
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On Linux a signal sent using tgkill will have si_code == SI_TKILL,
not SI_USER. Treat the two cases the same. Add a Linux-specific test.
Change the test to use the C pause function rather than sleeping
for a second, as that achieves the same effect.
This is a roll forward of CL 431255 which was rolled back in CL 431715.
This new version skips flaky tests on more systems, and marks a new method
nosplit.
Change-Id: Ibf2d3e6fc43d63d0a71afa8fcca6a11fda03f291
Reviewed-on: https://go-review.googlesource.com/c/go/+/432136
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When one has a []byte on hand, but desires to call the Parse function,
the conversion from []byte to string would allocate.
This occurs frequently through UnmarshalText and UnmarshalJSON.
This changes it such that the input string never escapes from
any of the Parse functions. Together with the compiler optimization
where the compiler stack allocates any string smaller than 32B
this makes most valid inputs for Parse(layout, string(input))
not require an allocation for the input string.
This optimization works well for most RFC3339 timestamps.
All timestamps with second resolution
(e.g., 2000-01-01T00:00:00Z or 2000-01-01T00:00:00+23:59)
or timestamps with nanosecond resolution in UTC
(e.g., 2000-01-01T00:00:00.123456789Z)
are less than 32B and benefit from this optimization.
Unfortunately, nanosecond timestamps with non-UTC timezones
(e.g., 2000-01-01T00:00:00.123456789+23:59)
do not benefit since they are 35B long.
Previously, this was not possible since the input leaked
to the error and calls to FixedZone with the zone name,
which causes the prover to give up and heap copy the []byte.
We fix this by copying the input string in both cases.
The advantage of this change is that you can now call Parse
with a []byte without allocating (most of the times).
The detriment is that the timezone and error path has an extra allocation.
Handling of timezones were already expensive (3 allocations and 160B allocated),
so the additional cost of another string allocation is relatively minor.
We should optimize for the common case, rather than the exceptional case.
Performance:
name old time/op new time/op delta
ParseRFC3339UTCBytes 54.4ns ± 1% 40.3ns ± 1% -25.91% (p=0.000 n=9+10)
Now that parsing of RFC3339 has been heavily optimized in CL 425197,
the performance gains by this optimization becomes relatively more notable.
Related to CL 345488.
Change-Id: I2a8a9cd6354b3bd46c2f57818ed2646a2e485f36
Reviewed-on: https://go-review.googlesource.com/c/go/+/429862
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Replace custom append functions in the hash functions with the implementation of the encoding/binary package that do the same thing.
The binary bigendian functions are already used in other parts of the code in the crypto package.
Change-Id: I76d2dbe143fc72a3b4ac06be312caf72bd71378a
GitHub-Last-Rev: 1c6c68279e
GitHub-Pull-Request: golang/go#55085
Reviewed-on: https://go-review.googlesource.com/c/go/+/431035
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Use "%w" instead of "%v" as format verb for error value in the NextPart
method. This way it will be possible to use common go error utilities
from std library when parsing from custom io.Readers.
This issue was discovered during attempts to use
http.Request.ParseMultipartForm together with http.MaxBytesHandler.
Change-Id: Idb82510fb536b66b51ed1d943737c4828f07c2f2
GitHub-Last-Rev: 8bc49c945c
GitHub-Pull-Request: golang/go#55133
Reviewed-on: https://go-review.googlesource.com/c/go/+/431675
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
This CL adds some optimizaion rules:
1, Converts CMP to CMN, or vice versa, when comparing with a negative
number.
2, For equal and not equal comparisons, CMP can be converted to CMN in
some cases. In theory we could do the same optimization for LT, LE, GT
and GE, but need to account for overflow, this CL doesn't handle them.
There are no noticeable performance changes.
Change-Id: Ia49266c019ab7908ebc9510c2f02e121b1607869
Reviewed-on: https://go-review.googlesource.com/c/go/+/429795
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Eric Fang <eric.fang@arm.com>
get, at least, is called from typedmemclr which must not be interruptible.
These were previously nosplit by accident before CL 424395 (the only
call they had was an intrinsic, so they were leaf functions, so they had
no prologue). After CL 424395 they contained a call (in noinline builds),
thus had a prologue, thus had a suspension point.
I have no idea how we might test this.
This is another motivating use case for having a nosplitrec directive
in the runtime.
Fixes#55156Fixes#54779Fixes#54906Fixes#54907
Change-Id: I851d733d71bda7172c4c96e027657e22b499ee00
Reviewed-on: https://go-review.googlesource.com/c/go/+/431919
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Although I can't think of any reason to do this, it is possible for
a user-defined flag to implement IsBoolFlag but return "false".
This is nuts because checking the interface is satisfied should
obviously be sufficient, but the documentation kinda implies it's
not. And if you try this, you'll discover that the usage message
ignores the return value even though the rest of the package plays
nice. Bother.
So we fix it, as the fix is trivial: call the method when creating
the usage message.
Fixes#53473
Change-Id: I1ac80a876ad5626eebfc5ef6cb972cd3007afaad
Reviewed-on: https://go-review.googlesource.com/c/go/+/431102
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The nounified frontend currently tries to construct dictionaries that
correspond to invalid instantiations (i.e., instantiations T[X] where
X does not satisfy the constraints specified on T's type parameter).
As a consequence, we may fail to find method expressions needed by the
dictionary.
The real fix for this is to avoid creating those dictionaries in the
first place, because they should never actually be needed at runtime.
But that seems scary for a backport: we've repeatedly attempted to
backport generics fixes, which have fixed one issue but introduced
another.
This CL is a minimally invasive solution to #54225, which avoids the
ICE by instead skipping emitting the invalid dictionary. If the
dictionary ends up not being needed (which I believe will always be
the case), then the linker's reachability analysis will simply ignore
its absence.
Or worst case, if the dictionary *is* reachable somehow, we've simply
turned an ICE into a link-time missing symbol failure. That's not
great for user experience, but it seems like a small trade off to
avoid risking breaking any other currently working code.
Updates #54225.
Change-Id: Ic379696079f4729b1dd6a66994a58cca50281a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/429655
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
In unified IR, local defined types are promoted to a global defined
type with a "vargen" suffix. These shouldn't actually be exposed to
go/types users, because they're only relevant within function bodies,
which go/types doesn't support importing.
Moreover, in the case of defined types that were declared within a
generic function, they can have ambient type parameters, which the
go/types importer doesn't know how to handle (because they shouldn't
be needed for that use case).
While here, prune the gcimporter_test.go skip list, because some of
the listed failures have actually been fixed and all of them are
specific to the Go 1.18 (nounified) frontend. They all work correctly
with GOEXPERIMENT=unified.
Fixes#55110.
Change-Id: I7dd8b86355d910dfed1d47edbad7695144c3f84d
Reviewed-on: https://go-review.googlesource.com/c/go/+/431495
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The type of the source and destination of a memmove call isn't
always accurate. It will always be a pointer (or an unsafe.Pointer), but
the base type might not be accurate. This comes about because multiple
copies of a pointer with different base types are coalesced into a single value.
In the failing example, the IData selector of the input argument is a
*[32]byte in one branch of the type switch, and a *[]byte in the other branch.
During the expand_calls pass both IDatas become just copies of the input
register. Those copies are deduped and an arbitrary one wins (in this case,
*[]byte is the unfortunate winner).
Generally an op v can rely on v.Type during rewrite rules. But relying
on v.Args[i].Type is discouraged.
Fixes#55122
Change-Id: I348fd9accf2058a87cd191eec01d39cda612f120
Reviewed-on: https://go-review.googlesource.com/c/go/+/431496
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
TestReadRequest_Bad's tests for leading whitespace in the first header
were also exercising the test verifying that a HEAD request has no
Content-Length. Also, the test intended to test a leading tab was
actually testing for a leading \t (literal backslash, literal t).
Change-Id: I05b46d05851b49bf75f1d1257c421b953b66ea9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/428134
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
