This change in terminology prevents potential confusion
that migth be caused by associating "structural type"
with "structural typing"; the two are not connected.
Also, adjusted introductory paragraph of section on
constraint type inference: type inference goes in both
directions, from type parameter to core type and vice
versa. The previous description was not quite accurate.
Change-Id: If4ca300f525eea660f68486302619aa6ad5dbc2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/384238
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #47694.
Change-Id: I5f6850e171f574a5342671778df854dc68a5148f
Reviewed-on: https://go-review.googlesource.com/c/go/+/384554
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
Trust: Alex Rakoczy <alex@golang.org>
Run-TryBot: Alex Rakoczy <alex@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The terms "integer type", "floating-point type", and "complex type"
are used frequently in the spec but are not explicitly (only indirectly)
defined.
Slightly rephrased the section on numeric types and introduce these
terms explicitly. Add links to this section.
Change-Id: I3fb888933bece047da8b356b684c855618e9aee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/384157
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I119cfb1a0da9af89ced78935b8fcdfdb8d9b4ab6
Reviewed-on: https://go-review.googlesource.com/c/go/+/383794
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
It has moved to golang.org/x/exp/constraints. Perhaps it will move
back to the standard library in a future release.
For golang/go#45458Fixesgolang/go#50792
Change-Id: I93aa251a7afe7b329a3d3faadc0c5d6388b1f0e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/382460
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #47694.
For #50912.
For #50937.
Change-Id: I3fae6c8dbbd61a45e669b8fb0c18ac76f2183963
Reviewed-on: https://go-review.googlesource.com/c/go/+/381967
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: Ic338788d6410ed0d09ad129811377ee9ce5ed496
Reviewed-on: https://go-review.googlesource.com/c/go/+/367954
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts CL 380854.
Per the conluding discussions on #50791. A follow-up will
document `comparable` more thoroughly.
For #50791.
Change-Id: I15db9051784a012f713e28d725c3b8bbfeb40569
Reviewed-on: https://go-review.googlesource.com/c/go/+/381076
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Mostly from CL 367954.
Change-Id: Id003b0f785a286a1a649e4d6e8c87d0418a36545
Reviewed-on: https://go-review.googlesource.com/c/go/+/379920
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This reverts CL 376414.
For #47694.
For #50481.
Change-Id: Ie73961046e52e6e5d3262ef0aeaa24bec7eaa937
Reviewed-on: https://go-review.googlesource.com/c/go/+/379835
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It was removed in CL 378576.
For #50501
Change-Id: I26b8f0e99a40fa5c616aa4849a6ab15dd0d072f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/379314
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Introduce a (local) notion of a set of representative types,
which serves as a representation/approximation of an
interface's actual type set. If the set of representative
types is is non-empty and finite, it corresponds to the set
of specific types of the interface.
In the implementation, the set of representative types serves
as a finite representation of an interface's type set, together
with the set of methods.
Change-Id: Ib4c6cd5e17b81197672e4247be9737dd2cb6b56f
Reviewed-on: https://go-review.googlesource.com/c/go/+/376834
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #47694.
Change-Id: I00862f987a0ff9f71e0295ce4320e6f9a6a4332f
Reviewed-on: https://go-review.googlesource.com/c/go/+/376414
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Problem pointed out on golang-nuts mailing list.
Change-Id: If1c9b22e1ed7b4ec7ebcaadc80fa450333e6856c
Reviewed-on: https://go-review.googlesource.com/c/go/+/375799
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The release notes explicitly refer to sections updated
for generics in the spec but then point to the old spec
which is very confusing for beta users.
For #47694
Change-Id: I5b555db3543cc32f088a8b267ec3f1195a52a812
Reviewed-on: https://go-review.googlesource.com/c/go/+/373174
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The change clarifies in the release notes for go1.18 that the variable
is for compilation and references the microarchitecture description in
the Go Wiki,
https://golang.org/wiki/MinimumRequirements#amd64,
and references the same information in the output of go help
environment.
Fixes#50174
Change-Id: I6a7d5a06f48463a810c96cc9c76fe66113d5147c
Reviewed-on: https://go-review.googlesource.com/c/go/+/372194
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #47694
For #48052
Change-Id: I136be9b498033309d876099aae16bad330555416
Reviewed-on: https://go-review.googlesource.com/c/go/+/373774
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
For #47694
Sorry about that! I guess the autocompleter in VSCode auto-closed the paragraph and I didn't notice.
Change-Id: I1e834e47deb708cd5285d26201a442305f8c3b24
GitHub-Last-Rev: ab88731551
GitHub-Pull-Request: golang/go#50305
Reviewed-on: https://go-review.googlesource.com/c/go/+/374014
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
For #47694
Change-Id: I9f4838100741d3ba13e9374e70466fa405c6e4d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/372634
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
For #47694
Change-Id: I9af871a4a45b002e72629904011aac8f076617f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/372974
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The new description matches the implementation (CL 370774).
Also, in the section on type constraints, use "defines" instead of
"determines" because the constraint interface defines the type set
which is precisely the set of acceptable type arguments.
For #49482.
Change-Id: I6f30f49100e8ba8bec0a0f1b450f88cae54312eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/372874
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #49602.
Change-Id: I0d3ff8f087dffb3409918494147fd1dceff7514d
Reviewed-on: https://go-review.googlesource.com/c/go/+/372694
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #47694
Change-Id: Ibf38eabcb78abc563fcf77e2b566175a18c06fa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/372114
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In release notes for Go 1.18, fix typo in changes for package testing to
correctly document the change in CL 343883.
Change-Id: I40d92858ed3f74554a094466c06771f83dd81942
Reviewed-on: https://go-review.googlesource.com/c/go/+/371616
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
It is a new package and seems a major change.
Updates #47694.
Change-Id: If854e494e28bcd1e79c99e59119755b9cb6793d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/371816
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
There doesn't seem anything that still needs to de done there.
Updates #47694.
Change-Id: I7909f566638332f3904d20a34f61d371af1d2da2
Reviewed-on: https://go-review.googlesource.com/c/go/+/371754
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
As written, the conversion P(x), where P and the type
of x are type parameters with identical underlying types
(i.e., identical constraints), is valid. However, unless
the type of x and P are identical (which is covered with
the assignability rule), such a conversion is not valid
in general (consider the case where both type parameters
are different type parameters with constraint "any").
This change adjusts the rules to prohibit type parameters
in this case. The same reasoning applies and the analogue
change is made for pointer types.
The type checker already implements these updated rules.
Change-Id: Id90187900cb2820f6a0a0cf582cf26cdf8addbce
Reviewed-on: https://go-review.googlesource.com/c/go/+/371074
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/vet has several precision improvements for the checkers copylock, printf, sortslice, testinggoroutine, and tests. Adds a high level mention in the release notes and an example of string constant concatenation.
Updates #47694
Change-Id: I7a342a57ca3fd9e2f3e8ec99f7b647269798317f
Reviewed-on: https://go-review.googlesource.com/c/go/+/370734
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Tim King <taking@google.com>
Run-TryBot: Tim King <taking@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also update some other go/types release notes to use the present tense.
Updates #47694
Change-Id: I654371c065e76fd5d22679d0d3c1a81bc3d1e513
Reviewed-on: https://go-review.googlesource.com/c/go/+/370235
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL reorders the bullet points in the generics section to more
closely match what I think users will consider most important. I put
the ~ token before the mention of ~T in interfaces to avoid a forward
reference, though I wonder if we actually want to spent a couple more
sentences saying what union and ~T types are, since most people are
going to care about that a lot more than they care about the low-level
detail that there's a new token.
For #47694.
Change-Id: Ib84f096ef6346a711801268ce362b64fa423d3f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/369734
Trust: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
NewTypeList was not part of the go/types API proposal, and was left in
by accident. It also shouldn't be necessary, so remove it.
Updates #47916
Change-Id: I4db3ccf036ccfb708ecf2c176ea4921fe68089a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/369475
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
For #47694
Change-Id: Iee4fda069a56ea4436b8aa32e2605f3349d7c154
Reviewed-on: https://go-review.googlesource.com/c/go/+/369334
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Also, move it up in the document.
Updates #47694
Change-Id: I927c4c845089a5c22e2c5b5f3de1831c04c6d990
Reviewed-on: https://go-review.googlesource.com/c/go/+/369102
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The number of involved CLs is too large (hundreds) so
no CLs are mentioned in (html) comments.
Updates #47694
Change-Id: I655d800a1e56a71e9d70a190f1c42c17baf6861e
Reviewed-on: https://go-review.googlesource.com/c/go/+/369099
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Also make a few small formatting fixes.
Change-Id: Iad99d030312393af3b6533f2cd00f09aea0f2a7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/369074
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
For #44853
For #47694
Change-Id: Ia76246218b1361d8bdf510bbfc5178c83cdd3eec
Reviewed-on: https://go-review.googlesource.com/c/go/+/368834
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is based off Michael's notes.
Updates #47694
Change-Id: I6e7944f85b776e8481829a2fafd177a49557c6ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/368156
Trust: Jeremy Faller <jeremy@golang.org>
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This description is based on https://golang.org/cl/321490.
Updates #47694
Change-Id: I48656cd487d2fccf0b0d3390f350f1bc6f2b0080
Reviewed-on: https://go-review.googlesource.com/c/go/+/365738
Trust: Jeremy Faller <jeremy@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Change-Id: I562d4648756e710020ee491f3801896563a89baa
Reviewed-on: https://go-review.googlesource.com/c/go/+/367395
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We want to support some special cases for index expressions, len, and
cap on operands of type parameters (such as indexing a value constrained
by byte slices and strings), hence the extra rules.
Change-Id: I4a07dc7e64bb47361b021d606c52eae1784d5430
Reviewed-on: https://go-review.googlesource.com/c/go/+/366814
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
- fix definition of "specific types" and add more examples
- state that a parameterized function must be instantiated
when used as a function value
- remove duplicate word ("can can" -> "can")
Thanks to @danscales for finding these.
Change-Id: Ideb41efc35a3e67694d3bc97e462454feae37c44
Reviewed-on: https://go-review.googlesource.com/c/go/+/367394
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
For #47694.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I38c2fd9b57fbbacf220a2bc679f67e2dfdcc7cb1
Reviewed-on: https://go-review.googlesource.com/c/go/+/367514
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This change corrects the link `Instantiantions` to `Instantiations` in the spec.
Change-Id: Ib0ed03420ae401d20af1ea723c5487018b2f462d
GitHub-Last-Rev: b84316c818
GitHub-Pull-Request: golang/go#49816
Reviewed-on: https://go-review.googlesource.com/c/go/+/367274
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Change-Id: I11111b3617673be94508128489aed6488d518537
Reviewed-on: https://go-review.googlesource.com/c/go/+/366834
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I5ffc7f26236487070447eaa0f6b14d1fab44c3c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/366794
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I2770da87b4c977b51dfa046f2f08283917675e1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/365916
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Change-Id: I7bfddf4be0d1d95419f312bb349ae2e16b74b795
Reviewed-on: https://go-review.googlesource.com/c/go/+/365915
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I3c4d8bdb5e92ee7fdca9593fb043f94f467755e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/365434
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I4423a059527066c4418c195911f8184dfd3f5a15
Reviewed-on: https://go-review.googlesource.com/c/go/+/365914
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The notion of specific types will be used to define rules for
assignability, convertability, etc. when type parameters are
involved.
Change-Id: Ic5c134261e2a9fe05cdf25efd342f052458ab5c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/366754
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
