Thanks to @danscales for noticing the mistake.
Change-Id: I547ee80a78419765b82d39d7b34dc8d3bf962c35
Reviewed-on: https://go-review.googlesource.com/c/go/+/366215
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Fixes#49214.
For #47694.
Change-Id: Iba68ed17bfd81890309b6a6732087f87a03e1350
Reviewed-on: https://go-review.googlesource.com/c/go/+/366274
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change introduces the notion of a structural interface
and its corresponding structural type.
Change-Id: Ib5442dfd04cb5950b4467428cae51849f8922272
Reviewed-on: https://go-review.googlesource.com/c/go/+/365474
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- add section on type parameters
- added two sections on the scope of type parameters
- expanded general section on types accordingly
- introduced the notion of a named type which will
help in simplifying various rules (subsequent CLs)
Change-Id: I49c1ed7d6d4f951d751f0a3ca5dfb637e49829f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/365414
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I29e9188a0fa1326c2755a9b86aeb47feaa8019be
Reviewed-on: https://go-review.googlesource.com/c/go/+/365274
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- fixed a typo in the method set section
- express in the syntax that ~T denotes an underlying type
- be more precise when talking about types vs type terms
- refer to "unions" rather than "union expressions"
- make it clear in the spec title that this is WIP
Change-Id: I9b2c4b1f77bc50dd574ed6893bedd40529c320fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/365154
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is the first of several CLs that update the existing
Go 1.17 spec for type parameters.
This CL updates the section on method sets and interface types.
It also adds "any", "comparable" to the list of predeclared
identifiers.
Change-Id: I0ce25dc02791c33150c0d949528512610faf3eab
Reviewed-on: https://go-review.googlesource.com/c/go/+/362999
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also mention local types restriction.
We probably want to say more at some point, this is just a
placeholder to start.
Update #47631
Change-Id: I828e451e1e8504d21cb55c7132e9cb330b160a54
Reviewed-on: https://go-review.googlesource.com/c/go/+/364134
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
For #47694
Change-Id: I39594c273aeb038702457587ee1c46e4b3920bb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/363359
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Jeremy Faller <jeremy@golang.org>
Thanks for jtagcat@ for finding this.
Change-Id: If7324808edbae19ec8bf503b04e0426f3fb3b47a
Reviewed-on: https://go-review.googlesource.com/c/go/+/363394
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This PR adds a note into the Go 1.18 changelog for CL 330852.
Updates #46923.
Change-Id: I99150e9275ce23fcf3697d6a22ac216818223c74
GitHub-Last-Rev: b2772ce68b
GitHub-Pull-Request: golang/go#49258
Reviewed-on: https://go-review.googlesource.com/c/go/+/360297
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
For #47327
Change-Id: I50418c0d017c4e90a2c13d26945ee639079e4e33
Reviewed-on: https://go-review.googlesource.com/c/go/+/363174
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Paschalis Tsilias <paschalistsilias@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This will allow us to compare the changes made for Go 1.18.
Change-Id: I1456270b201967f5cb05e66cec556939e6e33265
Reviewed-on: https://go-review.googlesource.com/c/go/+/362894
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #48367.
Change-Id: Ib8fc6d9dd7c3c6a70fefe077615f51a71d9c42ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/361899
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
A small touchup after CL 361894.
For #47694.
Change-Id: Ifc161516f897f727195d21351a3c8eda7b6e327e
Reviewed-on: https://go-review.googlesource.com/c/go/+/361895
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Carlos Amedee <carlos@golang.org>
For #47694.
Change-Id: Ia80a1859bd0fc6f08d27293f519c22fd9a804fd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/361894
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
In modules that specify 'go 1.17' or higher, the go.mod file
explicitly requires modules for all packages transitively imported by
the main module. Users tend to use 'go mod download' to prepare for
testing the main module itself, so we should only download those
relevant modules.
In 'go 1.16' and earlier modules, we continue to download all modules
in the module graph (because we cannot in general tell which ones are
relevant without loading the full package import graph).
'go mod download all' continues to download every module in
'go list all', as it did before.
Fixes#44435
Change-Id: I3f286c0e2549d6688b3832ff116e6cd77a19401c
Reviewed-on: https://go-review.googlesource.com/c/go/+/357310
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This reverts CL 359096.
Updates #47788.
Reason for revert: -buildmode=shared may have actually been working in a few very specific cases. We should not remove -buildmode=shared until we have implemented an alternative to support those few cases.
Change-Id: Ia962b06abacc11f6f29fc29d092773be175e32f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/359575
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Change-Id: I032791a3cda1916099b0fd2955dcca4e69763660
Reviewed-on: https://go-review.googlesource.com/c/go/+/357958
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
It never worked in module mode (or with a read-only GOROOT).
A proposal to drop it was filed (and approved) in
https://golang.org/issue/47788.
Fixes#47788
Change-Id: I0c12f38eb0c5dfe9384fbdb49ed202301fa4273d
Reviewed-on: https://go-review.googlesource.com/c/go/+/359096
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Mention future versions will require the COMPAT_FREEBSD12 kernel option
set in the kernel.
For #47694.
Change-Id: Ia94c4f9dbb38c68025d3c1d12dd2e241a5480a6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/354971
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
For #43684
Change-Id: I9ce47de82203ec87e7d3683f56e6c6d61ae255f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/352151
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
gofmt is pretty heavily CPU-bound, since parsing and formatting 1MiB
of Go code takes much longer than reading that amount of bytes from
disk. However, parsing and manipulating a large Go source file is very
difficult to parallelize, so we continue to process each file in its
own goroutine.
A Go module may contain a large number of Go source files, so we need
to bound the amount of work in flight. However, because the
distribution of sizes for Go source files varies widely — from tiny
doc.go files containing a single package comment all the way up to
massive API wrappers generated by automated tools — the amount of
time, work, and memory overhead needed to process each file also
varies. To account for this variability, we limit the in-flight work
by bytes of input rather than by number of files. That allows us to
make progress on many small files while we wait for work on a handful
of large files to complete.
The gofmt tool has a well-defined output format on stdout, which was
previously deterministic. We keep it deterministic by printing the
results of each file in order, using a lazily-synchronized io.Writer
(loosly inspired by Haskell's IO monad). After a file has been
formatted in memory, we keep it in memory (again, limited by the
corresponding number of input bytes) until the output for all previous
files has been flushed. This adds a bit of latency compared to
emitting the output in nondeterministic order, but a little extra
latency seems worth the cost to preserve output stability.
This change is based on Daniel Martí's work in CL 284139, but using a
weighted semaphore and ephemeral goroutines instead of a worker pool
and batches. Benchmark results are similar, and I find the concurrency
in this approach a bit easier to reason about.
In the batching-based approach, the batch size allows us to "look
ahead" to find large files and start processing them early. To keep
the CPUs saturated and prevent stragglers, we would need to tune the
batch size to be about the same as the largest input files. If the
batch size is set too high, a large batch of small files could turn
into a straggler, but if the batch size is set too low, the largest
files in the data set won't be started early enough and we'll end up
with a large-file straggler.
One possible alternative would be to sort by file size instead of
batching: identify all of the files to be processed, sort from largest
to smallest, and then process the largest files first so that the
"tail" of processing covers the smallest files. However, that approach
would still fail to saturate available CPU when disk latency is high,
would require buffering an arbitrary amount of metadata in order to
sort by size, and (perhaps most importantly!) would not allow the
`gofmt` binary to preserve the same (deterministic) output order that
it has today.
In contrast, with a semaphore we can produce the same deterministic
output as ever using only one tuning parameter: the memory footprint,
expressed as a rough lower bound on the amount of RAM available per
thread. While we're below the memory limit, we can run arbitrarily
many disk operations arbitrarily far ahead, and process the results of
those operations whenever they become avaliable. Then it's up to the
kernel (not us) to schedule the disk operations for throughput and
latency, and it's up to the runtime (not us) to schedule the
goroutines so that they complete quickly.
In practice, even a modest assumption of a few megabytes per thread
seems to provide a nice speedup, and it should scale reasonably even
to machines with vastly different ratios of CPU to disk. (In practice,
I expect that most 'gofmt' invocations will work with files on at most
one physical disk, so the CPU:disk ratio should vary more-or-less
directly with the thread count, whereas the CPU:memory ratio is
more-or-less independent of thread count.)
name \ time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 11.9s ± 2% 2.7s ± 3% 2.8s ± 5%
name \ user-time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 13.5s ± 2% 14.4s ± 1% 14.7s ± 1%
name \ sys-time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 465ms ± 8% 229ms ±28% 232ms ±31%
name \ peak-RSS-bytes baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 77.7MB ± 4% 162.2MB ±10% 192.9MB ±15%
For #43566
Change-Id: I4ba251eb4d188a3bd1901039086be57f0b341910
Reviewed-on: https://go-review.googlesource.com/c/go/+/317975
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Thanks to @bodar (Github) for finding this.
Fixes#48422.
Change-Id: I031c3d82a02db1d204e2b86b494d89784d37f073
Reviewed-on: https://go-review.googlesource.com/c/go/+/350409
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 85215 added prose to provide some minimal intuition for the
definition of a "terminating statement". While the original definition
was perfectly fine, the added prose was actually incorrect: If the
terminating statement is a goto, it might jump to a labeled statement
following that goto in the same block (it could be the very next
statement), and thus a terminating statement does not in fact
"prevent execution of all statements that lexically appear after
it in the same block".
Rather than explaining the special case for gotos with targets that
are lexically following the goto in the same block, this CL opts for
a simpler approach.
Thanks to @3bodar (Github) for finding this.
Fixes#48323.
Change-Id: I8031346250341d038938a1ce6a75d3e687d32c37
Reviewed-on: https://go-review.googlesource.com/c/go/+/349172
Trust: Robert Griesemer <gri@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I33bde4835d3b83fafd55beea483f6236c4c62840
Reviewed-on: https://go-review.googlesource.com/c/go/+/338990
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Than McIntosh <thanm@google.com>
So it's clear to the reader that if "M" is a promoted method from
embedded field "T", then "x.M" will be expanded to "x.T.M" during the
evaluation of the method value.
Fixes#47863
Change-Id: Id3b82127a2054584b6842c487f6e15c3102dc9fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/344209
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL adds a new syscall.SyscallN API.
The proposal discussion also suggests the API should not only for
Windows but other platforms. However, the existing API set already
contain differences between platforms, hence the CL only implements
the Windows platform.
Moreover, although the API offers variadic parameters, the permitted
parameters remains up to a limit, which is selected as 42, and arguably
large enough.
Fixes#46552
Change-Id: I66b49988a304d9fc178c7cd5de46d0b75e167a4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/336550
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
This template is based on CL 295209 and previous ones like it.
Continue to eagerly include often-used sections, and clarify that
the TODO is about completing the section, or removing if it turns
out not to be needed.
Move the Go 1.17 release notes to x/website, since that's the new
home for past Go release notes as of CL 291711. They're added to
x/website in CL 342089.
For #47694
Updates #44513
Change-Id: I24962eed800d1509bdf71b7d7f819a683eb96f8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/342070
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The current text is slightly inaccurate. Make it more correct.
Change-Id: Iebe0051b74649d13982d7eefe3697f9e69c9b75d
Reviewed-on: https://go-review.googlesource.com/c/go/+/340449
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Fixes#44513.
Change-Id: I82c44a681b1fa67df123af86ee02a980b13acdc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/341673
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
For #22446
Change-Id: I71a30761a28e81c50b7089d5a28be99c736c2dc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/341332
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The current document uses the "top" and "bottom" when talking
about the address within a frame, which may easily lead to
misunderstandings. This patch directly uses "high address"
and "low address" to make the expression clearer.
Change-Id: I7469330bbdc158672d7f0314fe6680ebdd9ab79a
Reviewed-on: https://go-review.googlesource.com/c/go/+/339369
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
