When ABI wrappers are used, we may end up with two functions
having the same name. On ELF we mangle the name with ABI. Do the
same for PE.
TODO: other platforms?
Change-Id: If89f214a6286bc28c062c1aa1bad78dc353a9231
Reviewed-on: https://go-review.googlesource.com/c/go/+/304432
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When a in-flight request is cancelled, (*Transport).cancelRequest is
called. The cancelRequest function looks up and invokes a cancel
function before returning. The function lookup happens with reqMu held,
but the cancel function is invoked after dropping the mutex.
If two calls to cancelRequest are made at the same time, it is possible
for one to return before the cancel function has been invoked.
This race causes flakiness in TestClientTimeoutCancel:
- The test cancels a request while a read from the request body is
pending.
- One goroutine calls (*Transport).cancelRequest. This goroutine
will eventually invoke the cancel function.
- Another goroutine calls (*Transport).cancelRequest and closes the
request body. The cancelRequest call returns without invoking
the cancel function.
- The read from the request body returns an error. The reader
checks to see if the request has been canceled, but concludes
that it has not (because the cancel function hasn't been invoked
yet).
To avoid this race condition, call the cancel function with the
transport reqMu mutex held.
Calling the cancel function with the mutex held does not introduce any
deadlocks that I can see. The only non-noop request cancel functions
are:
A send to a buffered channel:
https://go.googlesource.com/go/+/refs/heads/master/src/net/http/transport.go#1362
The (*persistConn).cancelRequest function, which does not cancel any
other requests:
https://go.googlesource.com/go/+/refs/heads/master/src/net/http/transport.go#2526Fixes#34658.
Change-Id: I1b83dce9b0b1d5cf7c7da7dbd03d0fc90c9f5038
Reviewed-on: https://go-review.googlesource.com/c/go/+/303489
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
I don't know why the test requires runtime.(*Frame).Next symbol
present in the binary under test. I assume it is just some
sanity check? With CL 268479 runtime.(*Frame).Next can be pruned
by the linker. Replace it with runtime.main which should always
be present.
May fix the longtest builders.
Change-Id: Id3104c058b2786057ff58be41b1d35aeac2f3073
Reviewed-on: https://go-review.googlesource.com/c/go/+/304431
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The size of the field may be smaller than the addend,
such is the case with R_PPC64_TOC16_HA/LO and similar
relocations.
Add an extra return value to ldelf.relSize to account for
addend size which may be larger than the relocated field,
and fix the related ppc64 relocations.
Such relocs can be seen in large PIC blobs such
as the ppc64le race detector included with golang.
Change-Id: I457186fea5d0ec5572b9bbf79bb7fa21a36cc1b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/303990
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
When converting a type T to a non-empty interface I, we build the
itab which contains the code pointers of the methods. Currently,
this brings those methods live (if the itab is live), even if the
interface method is never used. This CL changes the itab to use
weak references, so the methods can be pruned if not otherwise
live.
Fixes#42421.
Change-Id: Iee5de2ba11d603c5a102a2ba60440d839a7f9702
Reviewed-on: https://go-review.googlesource.com/c/go/+/268479
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
No valid operation should match those removed by this patch. They
kind of look as if they match X-form load/stores on ppc64, but the
second argument is always ignored when translating to machine code.
Similarly, it should be noted an X-form memory access encodes into
an Addr which is a classified as a ZOREG argument with a non-zero
index, and a register type Addr.
Change-Id: I1adbb020d1b2612b18949d0e7eda05dbb3e8a25c
Reviewed-on: https://go-review.googlesource.com/c/go/+/303329
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
Remove more now-redundant code, methods, and types
associated with transition to register ABI.
Repaired some broken comments.
Tested on link-register architectures (arm64, ppc64le)
Updates #40724.
Change-Id: Ie8433f6d38ec4a1d9705f22dcb596f267d81f203
Reviewed-on: https://go-review.googlesource.com/c/go/+/304189
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Corrected typo/thinko.
We should keep the test for this, but it doesn't run yet because of reflection
as far as I know (but I am not testing w/ GOEXPERIMENT).
See https://github.com/golang/go/issues/44816#issuecomment-805297295
Updates #40724
Updates #44816
Change-Id: Ia12d0d4db00a8ec7174e72de460173876bd17874
Reviewed-on: https://go-review.googlesource.com/c/go/+/304233
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change-Id: Icfa204761045b72a8ea173fd55eddf1f0e58d819
Reviewed-on: https://go-review.googlesource.com/c/go/+/304253
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Adds code to the compiler's "order" phase to rewrite go and defer
statements to always be argument-less. E.g.
defer f(x,y) => x1, y1 := x, y
defer func() { f(x1, y1) }
This transformation is not beneficial on its own, but it helps
simplify runtime defer handling for the new register ABI (when
invoking deferred functions on the panic path, the runtime doesn't
need to manage the complexity of determining which args to pass in
register vs memory).
This feature is currently enabled by default if GOEXPERIMENT=regabi or
GOEXPERIMENT=regabidefer is in effect.
Included in this CL are some workarounds in the runtime to insure that
"go" statement targets in the runtime are argument-less already (since
wrapping them can potentially introduce heap-allocated closures, which
are currently not allowed). The expectation is that these workarounds
will be temporary, and can go away once we either A) change the rules
about heap-allocated closures, or B) implement some other scheme for
handling go statements.
Change-Id: I01060d79a6b140c6f0838d6e6813f807ccdca319
Reviewed-on: https://go-review.googlesource.com/c/go/+/298669
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TestContextCancel is a test that ensures a process is killed soon after
canceling the context, even if Wait is not called (#16222). The test
checks whether the process exited without calling Wait by writing some
data to its stdin.
Currently the test involves two goroutines writing to stdin and reading
from stdout. However the reading goroutine is not very necessary to
detect the process exit.
This patch simplifies the test by connecting the process stdout to
/dev/null.
For #42061
Change-Id: I0447a1c024ee5abb050c627ec3766b731b02181a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303352
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the process of refactoring ioutil.Discard to io.Discard in
CL 263141 "an" should have been changed to "a" but was likely
missed in the process.
This commit corrects the spelling of the documentation.
Change-Id: I0609c45878291f8f01560efc3f3e6fba191e095b
GitHub-Last-Rev: e3257ca272
GitHub-Pull-Request: golang/go#45190
Reviewed-on: https://go-review.googlesource.com/c/go/+/304209
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
The internal ABI spec was recently updated to include specific
language covering "past-the-end" pointers and structs containing
trailing zero-sized fields. Add a unit test that makes sure we do the
right thing in this case. Fix a couple comments in other unit tests.
Change-Id: I18d373d11e122aec74b316837843887272676c63
Reviewed-on: https://go-review.googlesource.com/c/go/+/303809
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Otherwise, the added test would fail in an unnecessary way:
go build example.com/cov/onlytest: no non-test Go files ...
The test script is mimicking other cover_pkgall_*.txt scripts, so it
similarly tests both GOPATH and module modes.
Fixes#27333.
Change-Id: Ie60be569b31d49b173a78556c0669a87ada6799e
Reviewed-on: https://go-review.googlesource.com/c/go/+/288292
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Current MaxBytesReader behaviour differs from its documentation. It's
not similar enough to io.LimitReader. It panics when limit (n) < -1 and
returns [-1, <nil>] when limit (n) = -1. To fix that, we treat all
negative limits as equivalent to 0.
It would be possible to make MaxBytesReader analogically identical in
behaviour to io.LimitReader, but that would require to stop
maxBytesReader's Read from reading past the limit. Read always reads one
more byte (if possible) for non-negative limits and returns a non-EOF
error. This behaviour will now apply to all limits.
Fixes#45101
Change-Id: I25d1877dbff1eb4b195c8741fe5e4a025d01ebc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/303171
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Damien Neil <dneil@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
More cleanup to remove unnecessary parts of AuxCall.
Passed testing on arm64 (a link-register architecture)
in addition to amd64 so very likely okay.
(Gratuitously updated commit message to see if it will
correctly this time.)
Updates #40724
Change-Id: Iaece952ceb5066149a5d32aaa14b36755f26bb8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303433
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently, the go resolver always send two DNS queries (A and AAAA) even
if tcp4/udp4/ip4 or tcp6/udp6/ip6 is used. This can cause unwanted
latencies when making IPv4-only or IPv6-only connections.
This change make go resolver aware of network parameter. Now, only one A
query is sent when tcp4/udp4/ip4 is used, and vice versa for
tcp6/udp6/ip6.
Fixes#45024
Change-Id: I815f909e6df5f7242cfc900f7dfecca628c3a2c8
GitHub-Last-Rev: 3d30c486de
GitHub-Pull-Request: golang/go#45016
Reviewed-on: https://go-review.googlesource.com/c/go/+/301709
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Temporarily disable a questionable test case in fixedbugs/bug193.go
and enable the test as a whole. See the issues below for details.
Updates #45114.
Updates #45117.
Change-Id: I1de6f8d79b592eeeec139cd92b6c9cac56a9a74b
Reviewed-on: https://go-review.googlesource.com/c/go/+/303094
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Negative constant shift counts are already handled
earlier in the code. No need anymore for this extra
section.
With this change, the shift code matches types2
with respect to the function logic.
Change-Id: Ic8b7f382271c79ab66021e30955cd9bac092332b
Reviewed-on: https://go-review.googlesource.com/c/go/+/303093
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For #42989.
Change-Id: Ic354edde23ed7bfb4cb3eec2794f7213ed862b47
Reviewed-on: https://go-review.googlesource.com/c/go/+/303090
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Based on https://golang.org/cl/284256 for go/types.
Brings this code more in line with go/types.
Adjusted various tests to match new error messages which
generally are now better: for assignment errors, instead
of a generic "cannot convert" we now say "cannot use"
followed by a clearer reason as to why not.
Major differences to go/types with respect to the changed
files:
- Some of the new code now returns error codes, but they
are only used internally for now, and not reported with
errors.
- go/types does not "convert" untyped nil values to target
types, but here we do. This is unchanged from how types2
handled this before this CL.
Change-Id: If45336d7ee679ece100f6d9d9f291a6ea55004d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/302757
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For additions, compares, and slices, create transform functions that do
just the transformations for those nodes by the typecheck package (given
that the code has been fully typechecked by types2). For nodes that have
no args with typeparams, we call these transform functions directly in
noder2. But for nodes that have args with typeparams, we have to delay
and call the tranform functions during stenciling, since we don't know
the specific types involved.
We indicate that a node still needs transformation by setting Typecheck
to a new value 3. This value means the current type of the node has been
set (via types2), but the node may still need transformation.
Had to export typcheck.IsCmp and typecheck.Assignop from the typecheck
package.
Added new tests list2.go (required delaying compare typecheck/transform
because of != compare in checkList) and adder.go (requires delaying add
typecheck/transform, since it can do addition for numbers or strings).
There are several more transformation functions needed for expressions
(indexing, calls, etc.) and several more complicated ones needed for
statements (mainly various kinds of assignments).
Change-Id: I7d89d13a4108308ea0304a4b815ab60b40c59b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303091
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Windows 10 >= 1607 allows CreateFile and friends to use long paths if
bit 0x80 of the PEB's BitField member is set.
In time this means we'll be able to entirely drop our long path hacks,
which have never really worked right (see bugs below). Until that point,
we'll simply have things working well on recent Windows.
Updates #41734.
Updates #21782.
Updates #36375.
Change-Id: I765de6ea4859dd4e4b8ca80af7f337994734118e
Reviewed-on: https://go-review.googlesource.com/c/go/+/291291
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Optimize some patterns into rev16/rev16w instruction.
Pattern1:
(c & 0xff00ff00)>>8 | (c & 0x00ff00ff)<<8
To:
rev16w c
Pattern2:
(c & 0xff00ff00ff00ff00)>>8 | (c & 0x00ff00ff00ff00ff)<<8
To:
rev16 c
This patch is a copy of CL 239637, contributed by Alice Xu(dianhong.xu@arm.com).
Change-Id: I96936c1db87618bc1903c04221c7e9b2779455b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/268377
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The current calculation method of constant pool size is:
c.pool.size = -c.pool.size & (funcAlign - 1)
c.pool.size += uint32(sz)
This doesn't make sense. This CL changes it as:
if q.As == ADWORD {
c.pool.size = roundUp(c.pool.size, 8)
}
c.pool.size += uint32(sz)
which takes into account the padding size generated by aligning DWORD to
8 bytes.
It's unnecessary to set the Pc field in addpool and addpool128 because
the Pc value will be reset in function span7, so remove the related lines.
Change-Id: I5eb8f259be55a6b97fc2c20958b4a602bffa4f88
Reviewed-on: https://go-review.googlesource.com/c/go/+/298609
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Move DWARF generation for global variables from the linker to the
compiler. This effectively parallelizes this part of DWARF generation,
speeds up the linker minutely, and gives us a slightly more rational
implementation (there was really no compelling reason to do DWARF gen
for globals in the linker).
Change-Id: I0c1c98d3a647258697e90eb91d1d8a9f6f7f376a
Reviewed-on: https://go-review.googlesource.com/c/go/+/295011
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Adds a new method IsPrivate to check if an IP is
private according to RFC 1918 & RFC 4193.
Fixes#29146
Change-Id: If77b9e1746d86029df66ae9f18437b1f65a18b59
GitHub-Last-Rev: 09f4ba7598
GitHub-Pull-Request: golang/go#42793
Reviewed-on: https://go-review.googlesource.com/c/go/+/272668
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
The explanatory comment and the associated version counter variable
for the helper routine "wrapCall" seem to have been left behind in
walk.go during the big refactoring -- move it back to where it should
be, next to wrapCall in stmt.go. Also fix a small buglet in the
comment itself.
Change-Id: I8637a838214b216581be59e01149a72282a46526
Reviewed-on: https://go-review.googlesource.com/c/go/+/303729
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
replaced old type-based logic with new abi-based logic;
earlier versions of this CL compared them for equality.
For not-in-a-register, they match everywhere tested.
also modified GetFrameOffset to make it more like the one it replaces;
the LocalsOffset is subtracted.
Change-Id: I65ce7f0646c493c277df6b6f46e4839a0d886ac9
Reviewed-on: https://go-review.googlesource.com/c/go/+/302072
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This change just increases the timeout to 1 minute to avoid test
flakiness.
Fixes#42061
Change-Id: Id258488ee8f062cd5e68b68bb5cf11e15fdbb396
Reviewed-on: https://go-review.googlesource.com/c/go/+/303351
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Benny Siegert <bsiegert@gmail.com>
runtime.save_g adds X18 to runtime.tls_g in order to have a pointer to
thread local storage. X18 represents a pointer to the TEB on ARM64 and
runtime.tls_g is set in runtime.wintls at initialization time. This
function calls TlsAlloc to allocate a "TLS slot", which is supposed to
index into NtCurrentTeb()->TlsSlots. So the full calculation we want is:
X18 + offsetof(TEB, TlsSlots) + 8*TlsAllocReturnValue
It makes sense to store the complete value of "offsetof(TEB,
TlsSlots) + TlsAllocReturnValue" into runtime.tls_g so that the
calculation can simplify to:
X18 + runtime.tls_g
But, instead of computing that, we're currently doing something kind of
strange, in which we:
- call TlsAlloc, which puts its return value into X0
- make sure X0 is less than 64, so we don't overflow
- set runtime.tls_g to 8*X1 + offsetof(TEB, TlsSlots)
The question is: why are we using X1 instead of X0? What is in X1?
Probably it was, by luck, zero before, and TlsAlloc returned zero, so
there was no problem. But on recent versions of Windows, X1 is some
other garbage value and not zero, so we eventually crash when trying to
dereference X18 + runtime.tls_g.
This commit fixes the problem by just computing:
runtime.tls_g = 8*X0 + offsetof(TEB, TlsSlots)
Fixes#45138.
Change-Id: I560426bae7468217bd183ac6c6eb4b56a3815b09
Reviewed-on: https://go-review.googlesource.com/c/go/+/303273
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Correct sign extension handling for consts on riscv64. This fixes a bug
in part exposed by CL 302609 - previously 64 bit consts were rewritten into
multiple 32 bit consts and the expansion would result in sign/zero extension
not being eliminated. With this change a MOVDconst with a 64 bit value can be
followed by a MOV{B,H,W}reg, which will be eliminated without actually
truncating to a smaller value.
Change-Id: I8d9cd380217466997b341e008a1f139bc11a0d51
Reviewed-on: https://go-review.googlesource.com/c/go/+/303350
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If I change a rule in ARM64.rules to use the variable name "b" in a
conflicting way, rulegen would previously not complain, and the compiler
would later give a confusing error:
$ go run *.go && go build cmd/compile/internal/ssa
# cmd/compile/internal/ssa
../rewriteARM64.go:24236:10: b.NewValue0 undefined (type int64 has no field or method NewValue0)
Make rulegen complain early about those cases. Sometimes they might
happen to be harmless, but in general they can easily cause confusion or
unintended effect due to shadowing.
After the change, with the same conflicting rule:
$ go run *.go && go build cmd/compile/internal/ssa
2021/03/22 11:31:49 rule ARM64.rules:495 uses the reserved name b
exit status 1
Note that 24 existing rules were using reserved names. It seems like the
shadowing was harmless, as it wasn't causing typechecking issues nor did
it seem to cause unintended behavior when the rule rewrite code ran.
The bool values "b" were renamed "t", since that seems to have a
precedent in other rules and in the fmt package.
Sequential values like "a b c" were renamed to "x y z", since "b" is
reserved.
Finally, "typ" was renamed to "_typ", since there doesn't seem to be an
obviously better answer.
Passes all three of:
$ GOARCH=amd64 go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=arm64 go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=mips64 go build -toolexec 'toolstash -cmp' -a std
Fixes#45154.
Change-Id: I1cce194dc7b477886a9c218c17973e996bcedccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/303549
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This doesn't change any behavior, but should help the compiler realise
that these funcs really do nothing at all.
Change-Id: Ib26c02ef264691acac983538ec300f91d6ff98db
Reviewed-on: https://go-review.googlesource.com/c/go/+/280314
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This constant existed in case there was a serious problem with the
change to the "all" pattern in Go 1.16 (CL 240623), so that we could
roll back the change in behavior by just flipping the constant without
introducing merge conflicts elsewhere.
Go 1.16 has been out for a while and the new "all" behavior seems fine,
so we can jettison this feature flag.
For #36460
Change-Id: Ic2730edcee81514d56c7086e11542468eb63c84a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303431
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Windows amd64 calling convention requires 16-bytes aligned
stack pointer. Before this patch, the real frame size is
0x48 (frame size) + 0x10 (frame pointer & return address),
which does not satisfy the alignment requirement.
_cgo_sys_thread_create eventually calls NtCreateThread,
which receives a pointer to a ThreadContext structure
allocated from (mis-aligned) stack, and may fail with
STATUS_DATATYPE_MISALIGNMENT on some implementations.
BP is saved/restored by prolog/epilog.
AX, CX, DX are volatile, no need to save and restore.
Fixes#41075
Change-Id: I01c0a22b4bf3b4cfdebf4df587445aa46c667973
GitHub-Last-Rev: 15d2bd740e
GitHub-Pull-Request: golang/go#44524
Reviewed-on: https://go-review.googlesource.com/c/go/+/295329
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Christopher Nelson <nadiasvertex@gmail.com>
When -clobberdeadreg flag is set, the compiler inserts code that
clobbers integer registers at call sites. This may be helpful for
debugging register ABI.
Only implemented on AMD64 for now.
Change-Id: Ia203d3f891c30fd95d0103489056fe01d63a2899
Reviewed-on: https://go-review.googlesource.com/c/go/+/302809
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Alpine Linux is not the only musl-based Linux distribution. Checking for
/etc/alpine-release excludes many other distributions (Oasis, KISS,
Sabotage, sta.li). Not having the correct GO_LDSO set during go builds will
result in the wrong linker/loader on nonalpine musl systems for pie builds.
Instead, the dynamic loader should be checked for every system and set. This
results in the correct dynamic linker being found on glibc systems
(/lib/ld-linux-x86-64.so.2) and musl systems (/lib/ld-musl-x84_64.so.1).
Fixes#45034
Change-Id: I4c9389abc759aa34431dc6c781022636b81d6910
GitHub-Last-Rev: e17b9eb106
GitHub-Pull-Request: golang/go#45036
Reviewed-on: https://go-review.googlesource.com/c/go/+/301989
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
In the runtime there are Windows-specific assembly routines that are
address-taken via funcPC and are not intended to be called through a
wrapper. Mark them as ABIInternal so that we don't grab the wrapper,
because that will break in all sorts of contexts.
For #40724.
For #44065.
Change-Id: I12a728786786f423e5b229f8622e4a80ec27a31c
Reviewed-on: https://go-review.googlesource.com/c/go/+/302109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This changes makes it so that nanotimeQPC calls nanotime1 without an ABI
wrapper by specifying the ABIInternal version directly. The reason why
this is necessary is because ABI wrappers typically require additional
stack space, and nanotimeQPC is used deep within nosplit contexts,
and with the ABI wrappers now enabled, this exhausts the stack guard
space held for nosplit functions. Rather than increase the stack guard,
we choose to do this.
For #40724.
Change-Id: Ia9173ca903335a9d6f380f57f4a45e49b58da6bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/303069
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Updates ExampleGet to show how to handle bad responses with non-1XX,2XX
status codes. Given that the canonical examples are copied, we need
to have them properly check against failures. This is a bug I've seen
often in the wild, that's exacerbated when for example unmarshalling
JSON or even protobufs, and no errors are returned by the decoders,
so code fails silently after making a request for example to a gateway
that they were unauthorized to access.
Fixes#39778
Change-Id: I1cd688f2fab47581c8cf228235d3662b4c8e4315
Reviewed-on: https://go-review.googlesource.com/c/go/+/299609
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Adds mentions of NewRequestWithContext and *Client.Do as prescriptions
for how to use a specified context.Context, to the docs of:
* (*Client).Get
* (*Client).Head
* (*Client).Post
* (*Client).PostForm
* Get
* Head
* Post
* PostForm
given that we can't remove those convenience functions, nor
change the method signatures, except for Go2.
Fixes#35562
Change-Id: I4859e6757e7f958c9067ac4ef15881cfba7d1f8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/299610
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Several classifications exist only to help disambiguate an
implied register (i.e $0/R0 as the implied second register
argument when loading constants, or pseudo-registers used
exclusively by the assembler front-end).
The register determination is folded into getimpliedreg. The
classifications and their related optab entries are removed
or updated.
Change-Id: Iffb167aa9fa57fbc1a537c79fbdfb36cb38f9d95
Reviewed-on: https://go-review.googlesource.com/c/go/+/301789
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
