Change-Id: I39917b90b67f630f8212853c0a201635960275cb
GitHub-Last-Rev: fe886534b4
GitHub-Pull-Request: golang/go#66180
Reviewed-on: https://go-review.googlesource.com/c/go/+/569975
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
go install golang.org/x/tools/cmd/bundle@latest
go generate net/http
This fixes the longtest builders, which broke at CL 570156.
Change-Id: I85e6a1c20bd0080228400a561efd750342ae2d67
Reviewed-on: https://go-review.googlesource.com/c/go/+/570276
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
OpenBSD enables Indirect Branch Tracking (IBT) on amd64 and Branch Target
Identification (BTI) on arm64, where hardware permits. Since Go generated
binaries do not currently support IBT or BTI, temporarily mark them with
PT_OPENBSD_NOBTCFI which prevents branch target CFI from being enforced
on execution. This should be removed as soon asn IBT and BTI support are
available.
Fixes#66040
Updates #66054
Change-Id: I91ac05736e6942c54502bef4b8815eb8740d2d5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/568435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Josh Rickmar <jrick@zettaport.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
GODEBUG affects test execution but was not being tracked.
Fixes#66213.
Fixes#65436.
Change-Id: I3ac3c397f0c6fa46cd9be0d22d03020d0632f64f
Reviewed-on: https://go-review.googlesource.com/c/go/+/570259
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
The simulators are too slow.
Change-Id: I0aaf2304ad0881c74886ff3185c09614de2aae63
Reviewed-on: https://go-review.googlesource.com/c/go/+/570236
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
A few recent godebugs are missing IncNonDefault uses.
Test for that, so that people remember to do it.
Filed bugs for the missing ones.
For #66215.
For #66216.
For #66217.
Change-Id: Ia3fd10fd108e1b003bb30a8bc2f83995c768fab6
Reviewed-on: https://go-review.googlesource.com/c/go/+/570275
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Telemetry counters writing is disabled on certain platforms.
See x/telemetry/internal/telemetry.DisabledOnPlatform.
For #66205
Change-Id: I833e15ae33fb27e09d67fc77b921498476237176
Reviewed-on: https://go-review.googlesource.com/c/go/+/570196
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
If user code has two timers t1 and t2 and does *t1 = *t2
(or *t1 = Timer{}), it creeps me out that we would be
corrupting the runtime data structures inlined in the
Timer struct. Replace that field with a pointer to the
runtime data structure instead, so that the corruption
cannot happen, even in a badly behaved program.
In fact, remove the struct definition entirely and linkname
a constructor instead. Now the runtime can evolve the struct
however it likes without needing to keep package time in sync.
Also move the workaround logic for #21874 out of
runtime and into package time.
Change-Id: Ia30f7802ee7b3a11f5d8a78dd30fd9c8633dc787
Reviewed-on: https://go-review.googlesource.com/c/go/+/568339
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: Ib24841f4823c357ddeefa28435c2b80867d752d2
GitHub-Last-Rev: b0c6c58b24
GitHub-Pull-Request: golang/go#66182
Reviewed-on: https://go-review.googlesource.com/c/go/+/570015
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commands run (in both src and src/cmd):
go get golang.org/x/net@master
go mod tidy
go mod vendor
For #24135
Change-Id: I88084d174c15a65350be1b43e27de619dc6d4dd6
Reviewed-on: https://go-review.googlesource.com/c/go/+/570156
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: 胡玮文 <huww98@outlook.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
An upcoming CL will give this call more to do.
For now, separate out the compiler change that
stops inlining the computation.
For #37196.
Change-Id: I965426d446964b9b4958e4613246002a7660e7eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/568375
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Ticker.Reset was added in CL 217362 in 2020.
It added the runtime helper modTimer, which is
analogous to startTimer and resetTimer but for tickers.
Unlike those, it does not contain a racerelease, which
means that code synchronizing by starting a ticker
will be diagnosed with a spurious race.
Add racerelease to modTimer and add tests of all
three racereleases (in startTimer, resetTimer, and modTimer).
Also do not call time.resetTimer from elsewhere in runtime,
since that function is only for package time. Use t.reset instead.
For #33184.
Change-Id: Ie40c1ad24911f21e81b1d3cc608cf086ff2bc83d
Reviewed-on: https://go-review.googlesource.com/c/go/+/568340
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
allp < timers has not been necessary since CL 258303.
sched < timers was implied by allp < timers, and that
was still necessary, but only when the world is stopped.
Rewrite the code to avoid that lock since the world is stopped.
Now timers and timer are independent of the scheduler,
so they could call into the scheduler (for example to ready
a goroutine) if we wanted them to.
Change-Id: I12a93013c98e51c9e2f2148175b02afce8384a59
Reviewed-on: https://go-review.googlesource.com/c/go/+/568337
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Before CL 564118, there were two ways to add a new timer:
addtimer or modtimer. Much code was duplicated between them
and it was always valid to call modtimer instead of addtimer
(but not vice versa), so that CL changed all addtimer call sites
to use modtimer and deleted addtimer.
One thing that was unique to addtimer, however, was that it
called cleantimers (now named ts.cleanHead) after locking the
timers, while modtimer did not. This was the only difference
in the duplicated code, and I missed it. Restore the call to
ts.cleanHead when adding a new timer.
Also fix double-unlock in cleanHead.
Change-Id: I26cc50d650f31f977c0c31195cd013244883dba9
Reviewed-on: https://go-review.googlesource.com/c/go/+/568338
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The comment in updateTimerPMask is wrong. It says:
// Looks like there are no timers, however another P
// may be adding one at this very moment.
// Take the lock to synchronize.
This was my incorrect simplification of the original comment
from CL 264477 when I was renaming all the things it mentioned:
// Looks like there are no timers, however another P may transiently
// decrement numTimers when handling a timerModified timer in
// checkTimers. We must take timersLock to serialize with these changes.
updateTimerPMask is being called by pidleput, so the P in question
is not in use. And other P's cannot add to this P.
As the original comment more precisely noted, the problem was
that other P's might be calling timers.check, which updates ts.len
occasionally while ts is locked, and one of those updates might
"leak" an ephemeral len==0 even when the heap is not going to
be empty when the P is finally unlocked. The lock/unlock in
updateTimerPMask synchronizes to avoid that. But this defeats
most of the purpose of using ts.len in the first place.
Instead of requiring that synchronization, we can arrange that
ts.len only ever shows a "publishable" length, meaning the len(ts.heap)
we leave behind during ts.unlock.
Having done that, updateTimerPMask can be inlined into pidleput.
The big comment on updateTimerPMask explaining how timerpMask
works is better placed as the doc comment for timerpMask itself,
so move it there.
Change-Id: I5442c9bb7f1473b5fd37c43165429d087012e73f
Reviewed-on: https://go-review.googlesource.com/c/go/+/568336
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
No semantic changes here.
Cleaning up for next change.
Change-Id: I9706009739677ff9eb893bcc007d805f7877511e
Reviewed-on: https://go-review.googlesource.com/c/go/+/568335
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
windows.Version is just a thin wrapper around RtlGetNtVersionNumbers,
which is an undocumented Windows API.
This CL unexports windows.Version so it is harder to use by accident.
Change-Id: Ib782da04e4e8be66970111a75f5c2df27ef51643
Reviewed-on: https://go-review.googlesource.com/c/go/+/570055
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Many of the tests in package time are about proper manipulation
of the timer heap. But now NewTimer bypasses the timer heap
except when something is blocked on the associated channel.
Make the tests test the heap again by using AfterFunc instead of
NewTimer.
In particular, adds a non-chan version of TestZeroTimer, which
was flaky-broken and then fixed by CLs in the cleanup stack.
This new tests makes sure we notice if it breaks again.
Fixes#66006.
Change-Id: Ib59fc1b8b85ef5a21e72fe418c627c9b8b8a083a
Reviewed-on: https://go-review.googlesource.com/c/go/+/568255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The timer zombie count was fundamentally racy and worked around
in CL 569995. We worked around that by ignoring underflow.
The fundamnental race was because t.ts was set before t was
inserted into ts. CL 564997 corrected that fundamental problem,
so now we can account for zombies completely accurately,
never seeing values less than zero. Do that.
Change-Id: Idfbccc6662af5935f29f2a06a35e8ea93929bed7
Reviewed-on: https://go-review.googlesource.com/c/go/+/569996
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
timers.wakeTime, which is called concurrently by P's trying to decide
how long they should sleep, can return inaccurate values while
timers.adjust is running. (Before the refactoring, this was still true
but the code did not have good names and was spread across more
files, making the race harder to see.)
The runtime thread sleeping code is complex enough that I am not
confident that the inaccuracy can cause delayed timer wakeups,
but I am also not confident that it can't, nor that it won't in the future.
There are two parts to the fix:
1. A simple logic change in timers.adjust.
2. The introduction of t.maybeAdd to avoid having a t that is
marked as belonging to a specific timers ts but not present
in ts.heap. That was okay before when everything was racy
but needs to be eliminated to make timers.adjust fully consistent.
The cost of the change is an extra CAS-lock operation on a timer add
(close to free since the CAS-lock was just unlocked) and a change
in the static lock ranking to allow malloc while holding a timer lock.
Change-Id: I1249e6e24ae9ef74a69837f453e15b513f0d75c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/564977
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Writes to timers.len are protected by the timers.lock.
There is no need to use an Add instead of a Store,
and the code is clearer (and perhaps slightly faster)
using the Store.
Change-Id: Icc6caef1b7405adec55c9b55b999b71de7d97484
Reviewed-on: https://go-review.googlesource.com/c/go/+/564976
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
These names were copied over from the p field names,
but now that they are part of the timers type they can use
shorter names that make the relationship clearer.
timer0When -> minWhen
timerModifiedEarliest -> minNextWhen
This code change is only the renaming.
Change-Id: I1c0adc0b3a1289d35639619d5c945585b2d81a9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/564975
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
The value produced for the EvFrequency event on Windows is missing the
fact that the cputicks clock gets divided. This results in durations
that are consistently wrong by the same factor (about 256).
Fixes#65997.
Change-Id: I930cbfce3499d435c20699f41c11e3227d84f911
Reviewed-on: https://go-review.googlesource.com/c/go/+/567937
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Right now, we're careful to clean up dead P state when we advance to
future trace generations. If we don't, then if that P comes back to
life, we might end up using its old stale trace state.
Unfortunately, we never handled this in the case when tracing stops,
only when advancing to new generations. As a result, stopping a trace,
starting it again, and then bringing a P back to life in the following
generation meant that the dead P could be using stale state.
Fixes#65318.
Change-Id: I9297d9e58a254f2be933b8007a6ef7c5ec3ef4f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/567077
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
This change cleans up the ordering interface in several ways.
First, it resolves a TODO about using a proper queue of events for extra
events produced while performing ordering. This will be necessary for a
follow-up change to handle coroutine switch events.
Next, it simplifies the ordering.advance method's signature by not
returning a schedCtx. Instead, ordering.advance will take responsibility
for constructing the final Event instead of the caller, and places it on
its own internal queue (in addition to any other Events generated). The
caller is then responsible for taking events off of the queue with a new
method Next.
Finally, hand-in-hand with the signature change, the implementation of
ordering.advance no longer forces each switch case to return but instead
has them converge past the switch. This has two effects. One is that we
eliminate the deferred call to update the M state. Using a defer here is
technically incorrect, because we might end up changing the M state even
if we don't advance the event! We got lucky here that curCtx == newCtx
in all such cases, but there may have been a subtle bug lurking here.
Unfortunately because of the queue's semantics however, we can't
actually avoid pushing into the queue at every possible successful exit
out of the switch. Hopefully this can become less error-prone in the
future by splitting up the switch into a dispatch of different
functions, instead of everything living in one giant function. This
cleanup will happen in a follow-up change.
Change-Id: Ifebbbf14e8ed5c08be5c1b0fadc2e5df3915c656
Reviewed-on: https://go-review.googlesource.com/c/go/+/565936
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Tracing is currently broken when using iter.Pull from the rangefunc
experiment partly because the "tracing is off" fast path in traceAcquire
was deemed too expensive to check (an atomic load) during the coroutine
switch.
This change adds trace.enabled, a non-atomic indicator of whether
tracing is enabled. It doubles trace.gen, which is the source of truth
on whether tracing is enabled. The semantics around trace.enabled are
subtle.
When tracing is enabled, we need to be careful to make sure that if gen
!= 0, goroutines enter the tracer on traceAcquire. This is enforced by
making sure trace.enabled is published atomically with trace.gen. The
STW takes care of synchronization with most Ms, but there's still sysmon
and goroutines exiting syscalls. We need to synchronize with those
explicitly anyway, which luckily takes care of trace.enabled as well.
When tracing is disabled, it's always OK for trace.enabled to be stale,
since traceAcquire will always double-check gen before proceeding.
For #61897.
Change-Id: I47c2a530fb5339c15e419312fbb1e22d782cd453
Reviewed-on: https://go-review.googlesource.com/c/go/+/565935
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The current implementation sets t.ts before adding t to ts;
that can cause inconsistencies with temporarily negative
ts.zombies values. Handle them gracefully, since we only
care about detecting very positive values.
Pending CL 564977 removes the race that sets t.ts early,
and then CL 569996 builds on top of that to make the count precise.
This CL just gets examples like the new test working sooner.
Change-Id: Ibe1aecc2554f83436f761f48e4050bd962982e4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/569995
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This reverts commit 8a0fbd75a5.
Reason for revert: Breaking real-world tests inside Google,
which means it probably breaks real-world tests outside Google.
One instance I have seen is a <!-- --> comment (often a copyright notice) before the procinst.
Another test checks that a canonicalizer can handle a test input that simply has procinsts mid-XML.
XML is full of contradictions, XML implementations more so. If we are going to start being picky, that probably needs to be controlled by a GODEBUG (and a proposal).
For #65691 (will reopen manually).
Change-Id: Ib52d0944b1478e71744a2a35b271fdf7e1c972ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/570175
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
A Path that starts with / is absolute.
A Path that starts with any other character is relative.
The meaning of a Path of "" is not defined,
but RequestURI converts a "" Path to "/"
and an empty Path may represent a URL with just
a hostname and no trailing / such as "http://localhost".
Handle empty paths in the base URL of JoinPath consistently with
RequestURI, so that joining to an empty base produces an absolute
path rather than a relative one.
u, _ := url.Parse("http://localhost")
u = u.JoinPath("x")
fmt.Println(u.Path) // "/x", not "x"
Fixes#58605
Change-Id: Iacced9c173b0aa693800dd01caf774f3f9a66d56
Reviewed-on: https://go-review.googlesource.com/c/go/+/469935
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
As CL 569755 did, for consistency, this CL slightly improves
the documentation for RuneLen.
Change-Id: Ic9776648baf2809af36cd16a94d1313938bb0e52
Reviewed-on: https://go-review.googlesource.com/c/go/+/569816
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
CL 541715 added an optimization to copy SSA-able variables.
When handling m[k] = append(m[k], ...) case, it uses ir.SameSafeExpr to
check that m[k] expressions are the same, then doing type assertion to
convert the map index to ir.IndexExpr node. However, this assertion is
not safe for m[k] expression in append(m[k], ...), since it may be
wrapped by ir.OCONVNOP node.
Fixing this by un-wrapping any ir.OCONVNOP before doing type assertion.
Fixes#66096
Change-Id: I9ff7165ab97bc7f88d0e9b7b31604da19a8ca206
Reviewed-on: https://go-review.googlesource.com/c/go/+/569716
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Transport getConn creates wantConn w, tries to obtain idle connection for it
based on the w.key and, when there is no idle connection, puts wantConn into
idleConnWait wantConnQueue.
Then getConn dials connection for w in a goroutine and blocks.
After dial succeeds getConn unblocks and returns connection to the caller.
At this point w is stored in the idleConnWait and will not be evicted
until another wantConn with the same w.key is requested or alive
connection returned into the idle pool which may not happen e.g. if
server closes the connection.
The problem is that even after tryDeliver succeeds w references
persistConn wrapper that allocates bufio.Reader and bufio.Writer and
prevents them from being garbage collected.
To fix the problem this change removes persistConn and error references
from wantConn and delivers them via channel to getConn.
This way wantConn could be kept in wantConnQueues arbitrary long.
Fixes#43966Fixes#50798
Change-Id: I77942552f7db04c225fb40d770b3101a8cfe655d
GitHub-Last-Rev: 027a0833f9
GitHub-Pull-Request: golang/go#62227
Reviewed-on: https://go-review.googlesource.com/c/go/+/522095
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Change-Id: I0e55dd68d92c39aba511b55368bf50d929d75f86
GitHub-Last-Rev: 1743014078
GitHub-Pull-Request: golang/go#66158
Reviewed-on: https://go-review.googlesource.com/c/go/+/569696
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I83c23ae0933f6abe4c07144f69c3d9c18aece6e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/569175
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: I99e5f6fab900b0bf301f78460c618c01b231f62b
Reviewed-on: https://go-review.googlesource.com/c/go/+/568956
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For actions with no package, the title "Executing action" is extremely
vague. Add the action mode so that there is some differentiation.
Change-Id: If6dcf81c7cd1f19a9532e56dd9f88abd1182ea97
Reviewed-on: https://go-review.googlesource.com/c/go/+/567936
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 544019 changes http.Error to remove misleading response headers.
However, it also adds new "Cache-Control" header unconditionally, which
may breaks existing clients out there, who do not expect to see the
this header in the response like test in golang.org/x/net/http2.
To keep thing backward compatible, http.Error should only add
Cache-Control header if it has been presented.
Updates #50905
Change-Id: I989e9f999a30ec170df4fb28905f50aed0267dad
Reviewed-on: https://go-review.googlesource.com/c/go/+/569815
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Change-Id: I1285ee047fd465f48028186ae04d4de60cc9969e
Reviewed-on: https://go-review.googlesource.com/c/go/+/569715
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: Ibc1344b678d5f7c730b924c697717305c90c26e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/569537
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
In certain scenarios, such as network mounts, calling Fsync results in
ENOTSUP in OSX. This issue was introduced in CL 130676 since
syscall.FSync was not properly flushing contents to disk, and it was
replaced with fcntl(fd, F_FULLSYNC). Most SMB servers, like Windows
Server and Samba don't support F_FULLSYNC.
To avoid such issues fallback to syscall.Fsync if fcntl returns ENOTSUP.
Fixes#64215
Change-Id: I567191e1179b7e70ddffb6b881469de1872746ef
GitHub-Last-Rev: 62e6931cf7
GitHub-Pull-Request: golang/go#64258
Reviewed-on: https://go-review.googlesource.com/c/go/+/543535
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This CL adds func RuneLen, while here, also uses RuneLen to simplify
code in Encode.
Fixes#44940
Change-Id: Ifd3b537f69880dfd32a69a6733d8d3c2b5d4ecba
Reviewed-on: https://go-review.googlesource.com/c/go/+/569755
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: Icc254cad3c861fd2b33228aa4d19424ce57a1b55
GitHub-Last-Rev: f557a696e4
GitHub-Pull-Request: golang/go#66153
Reviewed-on: https://go-review.googlesource.com/c/go/+/569695
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I6ac2863e2af8c23588d35bf142f607e241f98405
GitHub-Last-Rev: 445cf7b29e
GitHub-Pull-Request: golang/go#66152
Reviewed-on: https://go-review.googlesource.com/c/go/+/569675
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I211442f2bbdab29820126a350cbdb0886a10d6e5
GitHub-Last-Rev: 0347054a55
GitHub-Pull-Request: golang/go#66160
Reviewed-on: https://go-review.googlesource.com/c/go/+/569697
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Add code that will set a scriptGoInvoked bit for the testing.TB when
it invokes the go command. If the go command was invoked, make sure
that at least one counter was incremented.
Also add the counters cmd/go/gomodcache-entry-relative,
cmd/go/gopath-entry-relative, and cmd/go/invalid-toolchain-in-file so
we can increment counters when a test errors out before the flag
subcommand counters are processed. This enforces the invariant that at
least one counter is incremented by every test that invokes the go
command.
Add the counter cmd/go/exec-go-toolchain for when a toolchain switch
happens.
Add cmd/go/subcommand:help for invoking help without arguments and
cmd/go/help-unknown-topic for when an unknown command is provided
to help.
Change-Id: Id90f2bbe4c7e89b846da00ec1ed9595ece2b269c
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/568259
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
