syscall.ETXTBSY is only meaningful on Unix platforms, not on Windows.
Fixes#67356
Change-Id: I1b13292d821d61d820b396e08be9a4dd1683e843
Reviewed-on: https://go-review.googlesource.com/c/go/+/585695
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
To be consistent with other tests.
Change-Id: Ibea1d3bf57a295f024e05173d17112ce46a4f0bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/585895
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run telemetry.Start (without the upload) first thing so we can increment
counters in toolchain selection. Then run telemetry.StartWithUpload
after toolchain selection so we don't start the upload until after
toolchain selection has happened so we don't start something heavyweight
before selection.
Change-Id: Ia8979175a163265c3e29f6cb11a4ada4714d1d95
Reviewed-on: https://go-review.googlesource.com/c/go/+/585419
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
This CL adds a new function Preorder that makes it
easier to iterate over the nodes of a syntax tree.
In particular, break, continue, and return retain
their usual continuations.
Fixes#66339
Change-Id: I438b3c23780c91ed589871ad3b8822d54e8fabc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/570680
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Also, remove types2.Signature.SetTypeParams as it is not used
and does not exist in go/types.
Change-Id: I16c3ae988988d3735907e9c6c56e8626497ea405
Reviewed-on: https://go-review.googlesource.com/c/go/+/581817
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Fixes#67143.
Change-Id: I8bf9c2559f95d3d6a40874454208ae074b68875c
Reviewed-on: https://go-review.googlesource.com/c/go/+/583757
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is a placeholder for future options (e.g. JSON).
The parameter is temporarily variadic to avoid breaking
x/telemetry (see CL 585378), but I plan to remove
the "..." later this week.
Updates #67182
Change-Id: I3f6f39455d852f92902f8e3f007d3093cbe555db
Reviewed-on: https://go-review.googlesource.com/c/go/+/585557
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
The concept of an underlying type has become more complicated with the
addition of TypeParam and Alias types. Update the documentation to
clarify that it strips off Named, TypeParam, and Alias types, and to
reference the spec.
Fixes#65774
Change-Id: I40a8efe15b45591b95068acbf4ef9eae17a4cef1
Reviewed-on: https://go-review.googlesource.com/c/go/+/585456
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
As mentioned in CL 584598, linkname is a mechanism that, when
abused, can break API integrity and even safety of Go programs.
CL 584598 is a first step to restrict the use of linknames, by
implementing a blocklist. This CL takes a step further, tightening
up the restriction by allowing linkname references ("pull") only
when the definition side explicitly opts into it, by having a
linkname on the definition (possibly to itself). This way, it is at
least clear on the definition side that the symbol, despite being
unexported, is accessed outside of the package. Unexported symbols
without linkname can now be actually private. This is similar to
the symbol visibility rule used by gccgo for years (which defines
unexported non-linknamed symbols as C static symbols).
As there can be pull-only linknames in the wild that may be broken
by this change, we currently only enforce this rule for symbols
defined in the standard library. Push linknames are added in the
standard library to allow things build.
Linkname references to external (non-Go) symbols are still allowed,
as their visibility is controlled by the C symbol visibility rules
and enforced by the C (static or dynamic) linker.
Assembly symbols are treated similar to linknamed symbols.
This is controlled by -checklinkname linker flag, currently not
enabled by default. A follow-up CL will enable it by default.
Change-Id: I07344f5c7a02124dbbef0fbc8fec3b666a4b2b0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/585358
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Linknaming an instantiated generic symbol isn't particularly
useful: it doesn't guarantee the instantiation exists, and the
instantiated symbol name may be subject to change. Checked with a
large code corpus, currently there is no occurrance of linkname
to an instantiated generic symbol (or symbol with a bracket in its
name). This also suggests that it is not very useful. Linkname is
already an unsafe mechanism. We don't need to allow it to do more
unsafe things without justification.
Change-Id: Ifaa20c98166b28a9d7dc3290c013c2b5bb7682e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/585458
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 581215 changed 'throw' so that instead of print(s) it called
a more complicated function, printpanicval, that statically
appeared to have convTstring in its call graph, even though this
isn't dynamically reachable when called with a string argument.
However, this caused the link-time static callgraph test to point
out that throw (which is called in nowritebarrierrec contexts
such as markgc) reaches a write barrier.
The solution is to inline and specialize the printpanicval
function for strings; it reduces to printindented.
Thanks to mpratt for pointing out that the reachability
check is on the fully lowered code, and is thus sensitive
to optimizations such as inlining.
I added an explanatory comment on the line that generates
the error message to help future users confused as I was.
Fixesgolang/go#67274
Change-Id: Ief110d554de365ce4c09509dceee000cbee30ad9
Reviewed-on: https://go-review.googlesource.com/c/go/+/584617
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The Requirements structure, which represents the root level requirements
of the module graph also has a 'direct' field which contains the set of
direct dependencies of a module.
Before this change, in workspace mode, the direct field was not set on
the Requirements structure. This change sets direct in the two places
it's needed: when initializing Requirements from the workspace's mod
files and when updating Requirements based on imports.
When initializing Requirements from the workspace's mod files, this
change will use the 'indirect' comments in those mod files to record the
set of direct modules passed to the Requirements.
There is a loop in updateRequirements where we consider the imports of
the packages we loaded from the main module to make sure that all those
imported packages' modules are required. The loop also updates direct
for each of those modules (which have at least one package directly
imported by the main modules). Before this change, in the workspace
case we continued early from the loop and didn't proceed to the code
where direct is computed. This change fixes that.
Fixes#66789
Change-Id: I2b497fbf28c2197e8ba8e8ca5314c1a720f16364
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/580256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This appears to be useful only on amd64, and was specifically
benchmarked on Apple Silicon and did not produce any benefit there.
This CL adds the assembly instruction `PCALIGNMAX align,amount`
which aligns to `align` if that can be achieved with `amount`
or fewer bytes of padding. (0 means never, but will align the
enclosing function.)
Specifically, if low-order-address-bits + amount are
greater than or equal to align; thus, `PCALIGNMAX 64,63` is
the same as `PCALIGN 64` and `PCALIGNMAX 64,0` will never
emit any alignment, but will still cause the function itself
to be aligned to (at least) 64 bytes.
Change-Id: Id51a056f1672f8095e8f755e01f72836c9686aa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/577935
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This CL fixes an initialization loop during IR construction, that
stems from IR lacking first-class support for aliases. As a
workaround, we avoid publishing alias declarations until the RHS type
expression has been constructed.
Thanks to gri@ for investigating while I was out.
Fixes#66873.
Change-Id: I11e0d96ea6c357c295da47f44b6ec408edef89b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/585399
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Since CL 393354 this should no longer be necessary.
Change-Id: Ie9a7f779515aaf8b40a4f0083ba680f7b0231f04
Reviewed-on: https://go-review.googlesource.com/c/go/+/585576
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: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, the SEH symbol is defined as an aux symbol of the
function symbol, without adding to ctxt.Data. Each function has
its own SEH symbol. As there are a lot of duplications of the
SEH symbol contents, currently a Go object file may contain many
copies of identical SEH symbols. They are deduplicated at link
time. But it does make the linker do redundant work, and make it
hard to reason about the SEH symbol writing in the object file
writer, and its resolution in the linker. In fact, in the object
file writer, the same SEH symbol may be added to the ctxt.defs
multiple times (as it is the aux of multiple function symbols),
which is not expected.
In fact, "aux symbol" is just a mechanism to associate auxiliary
data to another symbol. The auxiliary data symbol itself can be an
ordinary data symbol, even a content-addressable symbol. Define
the SEH symbol as a conntent-addressable symbol and add it to
ctxt.Data. This way there is only one definition of each unique
SEH symbol, which can be the aux of many functions.
While here, add a check to ensure that we add a symbol at most
once to the defs list.
Change-Id: Ie7a0cf02ca114060423e025931b30de97ca330fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/585656
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
When the compiler or assembler's -S flag is set to 3 or higher,
print the symbol index, for debugging.
Change-Id: Ia7a42b0c017105ef12fd97b3e52de0e155b0cf2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/585655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Merge the handling of CMPx r,r,cr and CMPx r,i,cr when assembling.
This prevents generating machine code like cmpd rx,r0 when cmpdi rx,0
is preferred. The preferred form can be fused on Power10 for faster
execution of some instruction sequences.
Likewise, update a common case to use $0 instead of R0 to take
advantage of this.
Change-Id: If2549ca25a5f7d23001885ad444c70d829b3b066
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-ppc64_power8,gotip-linux-ppc64le_power10,gotip-linux-ppc64le_power8,gotip-linux-ppc64le_power9
Reviewed-on: https://go-review.googlesource.com/c/go/+/585137
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The fact that the go line sets both the language version and the
GODEBUG compatibility version can be a problem, especially since
the go line is also required to be ≥ the go lines of any required
dependency modules.
This change adds a new 'godebug' line to go.mod and go.work
to allow setting the GODEBUG values for the entire module.
It also adds a new meta-value default=go1.21 that means
take the defaults from Go 1.21 no matter what the go line says.
These were discussed in proposal #65573.
Fixes#65573.
Change-Id: I91746322a10178370ed1015ce5278372a024c824
Reviewed-on: https://go-review.googlesource.com/c/go/+/584476
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Investigating binaries, these patterns seem to show up frequently.
Change-Id: I987251e4070e35c25e98da321e444ccaa1526912
Reviewed-on: https://go-review.googlesource.com/c/go/+/583302
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Per the note earlier in the page, GODEBUGs are maintained for a
minimum of two years (four Go releases). Not said but certainly
implied is that they are maintained for four Go releases from the
point where people started needing to use them.
Since people would start needing gotypesalias=0 in Go 1.23,
it can be removed in Go 1.27.
Change-Id: Ifad63a1fff63c3f96f2ee192ca74bd1ce8bdb61f
Reviewed-on: https://go-review.googlesource.com/c/go/+/585457
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
fixesgolang/go#67088
Change-Id: I42e7a8d02b161187772f147e3e136ab6e0f71d7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/585059
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
When a request contains an "Expect: 100-continue" header,
the first read from the request body causes the server to
write a 100-continue status.
This write caused a panic when performed after the server handler
has exited. Disable the write when cleaning up after a handler
exits.
This also fixes a bug where an implicit 100-continue could be
sent after a call to WriteHeader has sent a non-1xx header.
This change drops tracking of whether we've written a
100-continue or not in response.wroteContinue. This tracking
was used to determine whether we should consume the remaining
request body in chunkWriter.writeHeader, but the discard-the-body
path was only taken when the body was already consumed.
(If the body is not consumed, we set closeAfterReply, and we
don't consume the remaining body when closeAfterReply is set.
If the body is consumed, then we may attempt to discard the
remaining body, but there is obviously no body remaining.)
Fixes#53808
Change-Id: I3542df26ad6cdfe93b50a45ae2d6e7ef031e46fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/585395
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
When the test fails to run the command, print the error message
to help debug.
Change-Id: I443579a622ba1bf67ef27071f141e945303d4c2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/585357
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
There are 16 bytes reduced.
Change-Id: I33ca96fd22002b3111f0462c3029d70df48adb6e
GitHub-Last-Rev: 8df56a9655
GitHub-Pull-Request: golang/go#67055
Reviewed-on: https://go-review.googlesource.com/c/go/+/581935
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This change modifies the commands in cmd to open counter files,
increment invocations counters and to increment counters for the names
of the flags that were passed in.
cmd/pprof and cmd/vet are both wrappers around tools defined in other
modules which do their own flag processing so we can't directly
increment flag counters right after flags are parsed. For those two
commands we wait to increment counters until after the programs have
returned.
cmd/dist is built with the bootstrap go so it can't depend on telemetry
yet. We can add telemetry support to it once 1.23 is the minimum
bootstrap version.
For #58894
Change-Id: Ic7f6009992465e55c56ad4dc6451bcb1ca51374a
Reviewed-on: https://go-review.googlesource.com/c/go/+/585235
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commands run:
go get golang.org/x/telemetry@7d78a97
go mod tidy
go mod vendor
Change-Id: Iea0fbe11bcc69fac35fba0ee3d02cd14344a3ee9
Reviewed-on: https://go-review.googlesource.com/c/go/+/585455
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
go get golang.org/x/mod@c0bdc7bd
go mod tidy
go mod vendor
Pulls in CL 584300.
For #65573.
Change-Id: Ia8ec86e2ee049b911fcf09d57f83972786b0470d
Reviewed-on: https://go-review.googlesource.com/c/go/+/584475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trying to write a test for the corner cases in the old async timer chan
implementation may have been a mistake, especially since this isn't
going to be the default timer chan implementation anymore.
But let's try one more time to fix the test.
I reproduced the remaining builder failures on my Mac laptop
by overloading the CPU in one window and then running 48 instances
of the flaky test in loops using 'stress' in another window.
It turns out that, contrary to my understanding of async timers
and therefore contrary to what the test expected, it is technically
possible for
t := time.NewTicker(1)
t.Reset(1000*time.Hour)
<-t.C
<-t.C
to observe two time values on t.C, as opposed to blocking forever.
We always expect the first time value, since the ticker goes off
immediately (after 1ns) and sends that value into the channel buffer.
To get the second value, the ticker has to be in the process of
going off (which it is doing constantly anyway), and the timer
goroutine has to be about to call sendTime and then get rescheduled.
Then t.Reset and the first <-t.C have to happen.
Then the timer goroutine gets rescheduled and can run sendTime's
non-blocking send on t.C, which finds an empty buffer and writes
a value.
This is unlikely, of course, but it definitely happens. This program
always panics in just a second or two on my laptop:
package main
import (
"os"
"time"
)
func main() {
os.Setenv("GODEBUG", "asynctimerchan=1")
for {
go func() {
t := time.NewTicker(1)
t.Reset(1000*time.Hour)
<-t.C
select {
case <-t.C:
panic("two receives")
case <-time.After(1*time.Second):
}
}()
}
}
Because I did not understand this nuance, the test did not expect it.
This CL rewrites the test to expect that possibility. I can no longer
make the test fail under 'stress' on my laptop.
For #66322.
Change-Id: I15c75d2c6f24197c43094da20d6ab55306a0a9f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/585359
Reviewed-by: Cherry Mui <cherryyz@google.com>
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>
Add a blurb to the toolchain section talking about stack slot merging.
Updates #62737.
Change-Id: I26193a6a381c95ff5d79ce80b77c10c7561d00cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/581439
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This patch changes the Go linker to "clean" (reset to Unix epoch) the
timestamps on object files copied to the tmpdir that is presented to
the external linker or archive tool. The intent is to improve build
reproducibility on Darwin, where later versions of xcode seem to want
to incorporate object file timestamps into the hash used for the final
build ID (which precludes the possibility of having reproducible Go
builds). Credit for this idea goes to Cherry (see
https://github.com/golang/go/issues/64947#issuecomment-1887667189).
Updates #64947.
Change-Id: I2eb7dddff538e247122b04fdcf8a57c923f61201
Reviewed-on: https://go-review.googlesource.com/c/go/+/585355
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
If unpadded content was passed, in some occassions content was omitted,
because the division result was floored. Ceiling it makes sure all
content is always read.
Fixes#65166
Change-Id: I1d8ee7ef436080483ed8f0e615b70a1013455f92
Reviewed-on: https://go-review.googlesource.com/c/go/+/581415
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: Ia5bcaba47da949583a720ca3506d6bd9e3794824
GitHub-Last-Rev: 1ed3dad2bf
GitHub-Pull-Request: golang/go#67320
Reviewed-on: https://go-review.googlesource.com/c/go/+/584996
Reviewed-by: Dmitri Shuralyov <dmitshur@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>
CL 584995 made Addr.AsSlice inlineable as a side effect. Make sure we
don't regress.
Updates #56136
Change-Id: Ib5f77a430db66ffe45c4cbb264da7a401945fec9
Reviewed-on: https://go-review.googlesource.com/c/go/+/585057
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: Idea4f92d511b5f18531758667cb0cb5ed6f91a0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/584359
Reviewed-by: 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: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: Ic00e63aa35bcea4c97a5885d61edb8fc37d84e22
GitHub-Last-Rev: 1ad3a5d0ed
GitHub-Pull-Request: golang/go#67324
Reviewed-on: https://go-review.googlesource.com/c/go/+/584997
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Package documentation of encoding/csv says:
> this package supports the format described in RFC 4180.
According to section 2 of RFC 4180:
> Each record is located on a separate line, delimited by a line break (CRLF).
On the other hand, Writer uses LF (not CRLF) as newline character by default.
> If [Writer.UseCRLF] is true, the Writer ends each output line with \r\n instead of \n.
Strictly speaking, this behavior is different from RFC 4180.
Package documentation would improve if we clarify that point.
Change-Id: I120e9332b593e1ac9ed8e49f6f8419ea88efc57d
GitHub-Last-Rev: 489167eb04
GitHub-Pull-Request: golang/go#67290
Reviewed-on: https://go-review.googlesource.com/c/go/+/584835
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: Id07f16d14133ee539bc2880b39641c42418fa6e2
GitHub-Last-Rev: 7b327d508f
GitHub-Pull-Request: golang/go#67319
Reviewed-on: https://go-review.googlesource.com/c/go/+/585016
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Fixes: #67184
Change-Id: Ibdf3810cbba30ae29f466f7f95f357e8512f228b
GitHub-Last-Rev: 5eabc760be
GitHub-Pull-Request: golang/go#67185
Reviewed-on: https://go-review.googlesource.com/c/go/+/583299
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Updates #54097
Change-Id: I827a5efd1736ce057b76f079466f2d9ead225898
GitHub-Last-Rev: 40af10469d
GitHub-Pull-Request: golang/go#67321
Reviewed-on: https://go-review.googlesource.com/c/go/+/585017
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
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>
