The spec states that if the argument type for close is a type parameter,
it's type set must only contain channels and they must all have the same
element type. This latter requirement (all must have the same element
type) was never enforced by the compiler, nor is it important for
correctness or required by the implementation.
This change removes this requirement also in the spec and thus
documents what was always (since 1.18) the case.
Fixes#74034.
Change-Id: If65d50bfb581b7f37999413088d3d3b1820e054a
Reviewed-on: https://go-review.googlesource.com/c/go/+/725923
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
1) explain new(type) (simpler) before new(expr) (more complicated)
2) for new(expr), explain what happens when expr is an untyped bool
3) explain that new(nil) is not permitted
4) streamline examples slightly
Fixes#76122.
Change-Id: I5ddb26bd88241b4b2b9aa9b532a62f7861c2341c
Reviewed-on: https://go-review.googlesource.com/c/go/+/722482
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Commit-Queue: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Per discussion on issue #75885, a type parameter on the RHS of an alias
declaration must not be declared in the same declaration (but it may be
declared by an enclosing function). This relaxes the spec slightly and
allows for (pre-existing) test cases.
Add a corresponding check to the type checker (there was no check for
type parameters on the RHS of alias declarations at all, before).
Fixes#75884.
Fixes#75885.
Change-Id: I1e5675978e6423d626c068829d4bf5e90035ea82
Reviewed-on: https://go-review.googlesource.com/c/go/+/721820
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
As written, the special case for append may be interpreted
such that any first argument that is assignable to []byte
is permissible, including nil. This change makes makes it
clear that a slice argument is required.
Not a language change. The compiler always expected a slice
argument.
Fixes#76226.
Change-Id: I73a1725d10096690335d6edf5793beb5de73578f
Reviewed-on: https://go-review.googlesource.com/c/go/+/718880
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
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: Ian Lance Taylor <iant@golang.org>
Close an "a" tag. While we are here, fix some escapes.
Change-Id: I16040eff0d4beeef6230aec8fcf4315f0efd13a4
GitHub-Last-Rev: 3ba7b9f747
GitHub-Pull-Request: golang/go#75760
Reviewed-on: https://go-review.googlesource.com/c/go/+/708517
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
(addressing comment from review of CL 704737)
Change-Id: I483dea046f664035e79c51729203c9a9ff0cbc59
Reviewed-on: https://go-review.googlesource.com/c/go/+/708299
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Also, add a release note.
For #45624
Change-Id: I1a0e111e00885c9640c073000afb72731d0930fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/704737
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
For #73526
Change-Id: I06d8ae9080695745db68a51635faa0b244c1760e
Reviewed-on: https://go-review.googlesource.com/c/go/+/670155
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Auto-Submit: Mark Freeman <mark@golang.org>
This CL removes the notion of core types from the spec.
Instead of referring to core types, each section that did
so before is reverted to approx. the pre-generics (1.17)
prose, and additional paragraphs cover the type parameter
cases as needed.
The hope is that this makes it easier to read the spec.
When type parameters are involved, the extra prose is
local to the language feature in question and thus more
readily available. When no type parameters are present,
readers do not have to concern themselves with core types.
In contrast to CL 621919, this change is not intended to
loosen the spec in any way and therefore does not change
the language (if the new prose implies otherwise, we will
correct it).
Except for adjustments to compiler error messages
(no mention of core types anymore), no other changes
to the compiler or tools are required.
Future CLs may selectively relax requirements on a language
construct by language construct basis; each such change can
be discussed and proposed independently.
For #70128.
Change-Id: I6ed879a472c615d7c8dbdc7b6bd7eef3d12eff7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/645716
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Also, delete go1.17_spec.html.
Change-Id: I7c78029dcfbbe8dbabb4ca81052976c1c8f4ed9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/645717
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Change-Id: If4d3b3965762c8979d304a82493c9eb1068ee13c
Reviewed-on: https://go-review.googlesource.com/c/go/+/642037
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Fixes#24163.
Change-Id: If389c4abf3b9b6e4eba6f31c3c12779329456df6
Reviewed-on: https://go-review.googlesource.com/c/go/+/637655
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Add a section on the representation of values:
distinguish between values that are self-contained
and values that contain references while avoiding
the notion of "reference types" which is misleading.
Also, use "predeclared identifier nil" rather than
"predeclared value nil" because it is the identifier
that is predeclared.
Fixes#5083.
Change-Id: I2235673c6404f2c055f195e879f198c7ab246d58
Reviewed-on: https://go-review.googlesource.com/c/go/+/635801
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
- Describe that function invocation allocates space for a functions'
variables.
- Explain parameter passing in terms of assignments.
Change-Id: Ia693d73a570f7d1aa2ac05e6095b4e602e4e9bf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/635800
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Change-Id: Ib1b14b8880c6de5606f7f425a5fc1c8749d8a4b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/635799
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
For #70417.
Change-Id: I5e6b3011f356c7ecd8f64f5dcf0a6a77dcb21bbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/629577
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
For #46477.
Change-Id: Id02d8f67fe82228bab3f26b1cb4ebd6ee67c4634
Reviewed-on: https://go-review.googlesource.com/c/go/+/616816
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
The existing prose for struct identity did only require that two structs
"have the same sequence of fields, and if corresponding fields have the
same names, and identical types, and identical tags" for the structs to
be identical.
The implementation (forever) has also required that two corresponding
fields are either both embedded or not embedded. This is arguably part
of a struct's structure but is not explicitly specified.
This CL makes a minor change to the prose to address that.
Fixes#69472.
Change-Id: Ifa4ca69717986675642a09d03ce683ba8235efcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/616697
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The spec says that an embedded field must be specified
as a type name (or a pointer to a type name). This is
explicit in the prose and the FieldDecl syntax.
However, the prose on promoted methods required a named
type (originally the term used for a "defined type").
Before the introduction of alias types, type names could
only refer to named/defined types, so the prose was ok.
With the introduction of alias types in Go 1.9, we
distinguished between defined types (i.e., types given
a name through a type declaration) and type aliases
(types given an alternative name), and retired the notion
of a named type since any type with a name (alias type
and defined type) could be considered a "named type".
To make things worse, with Go 1.18 we re-introduced the
notion of a named type which now includes predeclared
types, defined types, type parameters (and with that
type aliases denoting named types).
In the process some of the wording on method promotion
didn't get updated correctly. At attempt to fix this
was made with CL 406054, but while that CL's description
correctly explained the intent, the CL changed the prose
from "defined type" to "named type" (which had the new
meaning after Go 1.18), and thus did not fix the issue.
This CL fixes that fix by using the term "type name".
This makes the prose consistent for embedded types and
in turn clarifies that methods of embedded alias types
(defined or not) can be promoted, consistent with the
implementation.
While at it, also document that the type of an embedded
field cannot be a type parameter. This restriction has
been in place since the introduction of type parameters
with Go 1.18 and is enforced by the compiler.
Fixes#66540.
For #41687.
Change-Id: If9e6a03d7b84d24a3e6a5ceda1d46bda99bdf1f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/603958
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Axel Wagner <axel.wagner.hh@googlemail.com>
Also add a missing table entry to the language versions section in the
appendix.
Fixes#67977.
Change-Id: I1f98abbbcc34a4ff31f390752635435eaf6120b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/592595
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
For #65236.
Change-Id: I5a11811cc52467ea4446db29c3f86b119f9b2409
Reviewed-on: https://go-review.googlesource.com/c/go/+/592295
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
For #65237.
Change-Id: Id38747efebd46633f453eadaf68d818064faa778
Reviewed-on: https://go-review.googlesource.com/c/go/+/590396
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
For #61405.
Fixes#65237.
Change-Id: Ia7820c0ef089c828ea7ed3d2802c5185c945290e
Reviewed-on: https://go-review.googlesource.com/c/go/+/589397
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Clarify that the range expression of a "for" loop is called *just* once to
rule out that it might be re-evaluated after each iteration.
Change-Id: Iedb61cd29e5238ac0168b8ac01c34d6208cc4312
Reviewed-on: https://go-review.googlesource.com/c/go/+/582775
Reviewed-by: Robert Griesemer <gri@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: Ian Lance Taylor <iant@google.com>
Fixes#66967.
Change-Id: I7b9d62dcb83bad60b2ce74e2e2bf1a36c6a8ae38
Reviewed-on: https://go-review.googlesource.com/c/go/+/581256
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
If the range expression is a numeric constant, the
range expression is also not evaluated.
Change-Id: I97201e5c136d3d1a87ed1500b19b7199b30bc9ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/581298
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
There is no hyphen between the organization and the number.
For example, https://standards.ieee.org/ieee/754/6210/
shows the string "IEEE 754-2019" and not "IEEE-754-2019".
This assists in searching for "IEEE 754" in documentation
and not missing those using "IEEE-754".
Change-Id: I9a50ede807984ff1e2f17390bc1039f6a5d162e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/575438
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Add unclosed HTML tags and remove redundant </a> tags.
Change-Id: I3fffbcfd640001c9cc4f6085150344daa0c4369b
Reviewed-on: https://go-review.googlesource.com/c/go/+/568155
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
While at it, set the date to the Go 1.22 release date.
Change-Id: I03872626e500433eb63786d24c67810c8c6289f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/562337
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Also: report language version (plus date) in spec header.
Fixes#65137.
Change-Id: I4f1d220d5922c40a36264df2d0a7bb7cd0756bac
Reviewed-on: https://go-review.googlesource.com/c/go/+/557596
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Follow-up on CL 551095.
For #56010.
Change-Id: I8913d6ca96c419c81683e88c6286b05ae1323416
Reviewed-on: https://go-review.googlesource.com/c/go/+/552915
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
For #56010.
Change-Id: Icca987a03d80587dd0e901f596ff7788584893ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/551095
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Add a new section to the Appendix describing what features were
changed or added in which language version.
Add short links with references to the required language version
where relevant.
Fixes#63857.
Change-Id: I5250f856d8688a71602076fcc662aa678d96a5d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/549518
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The valid conversions consider the core types of operands, not just
their underlying type.
This also explains the valid arguments for unsafe.Slice which are
explained in terms of unsafe.Pointer conversions.
unsafe.SliceData simply refers to "slice argument" and we use
similar terminology elsewhere in the spec to denote values that
have a core type of slice (or any other type for that matter).
Leaving alone for now.
Fixes#64452.
Change-Id: I0eed3abbc0606f22358835e5d434f026fe0909c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/551379
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
This CL is partly based on CL 510535.
For #61405.
Change-Id: Ic94f6726f9eb34313f11bec7b651921d7e5c18d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/538859
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Fixes#63525.
Change-Id: Ie9aa4dd47c025cd593e576c6e8de1774e1d1e302
Reviewed-on: https://go-review.googlesource.com/c/go/+/535775
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
This CL clarifies the order of evaluation of the binary logical
operators, && and ||. The clarified semantics matches what cmd/compile
and x/tools/go/ssa already implement, and prohibit some optimizations
that are arguably allowed today but risk surprising users.
First, it specifies that the left operand is evaluated before the
right operand. This prohibits "(f() || true) && *p" from evaluating
"*p" before "f()".
Second, it specifies that binary logical operations are also ordered
lexically left-to-right with regard to function calls and receive
operations. This prohibits "h(*p || true || f(), g())" from evaluating
"*p" after "g()".
Finally, the "order of evaluation of [...] is not specified" wording
in the example is clarified to acknowledge that there are still some
other orderings that are implied lexically; e.g., x must be evaluated
and indexed before g(), and z now must be evaluated before h(). (Note:
Whether z is evaluated before or after f() remains unspecified, as
there's no lexical dependency.)
Change-Id: I9d316a7f1fbc83be663e116380a2cc7a4ace623d
Reviewed-on: https://go-review.googlesource.com/c/go/+/522938
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The example text below suggests that []byte("") always evaluates to
the non-nil value []byte{}, but the text proper doesn't explicitly
require that. This CL makes it clear that it must not evaluate to
[]byte(nil), which otherwise was allowed by the wording.
Change-Id: I6564bfd5e2fd0c820d9b55d17406221ff93ce80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/521035
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Change-Id: I40595a3f598483d029473af465c756f8777ecc91
Reviewed-on: https://go-review.googlesource.com/c/go/+/520915
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Irrespective of whether unification is exact or inexact, method
signatures of interfaces must always match exactly: a type never
satisfies/implements an interface if relevant method signatures
are different (i.e., not identical, possibly after substitution).
This change matches the fix https://go.dev/cl/519435.
For #61879.
Change-Id: I28b0a32d32626d85afd32e107efce141235a923d
Reviewed-on: https://go-review.googlesource.com/c/go/+/519455
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Change-Id: I06345199ff16c80be83c345d734caef1714ec089
Reviewed-on: https://go-review.googlesource.com/c/go/+/515338
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Change-Id: I0d4ccbc396c48d565c0cbe93c9558ab330a44d02
Reviewed-on: https://go-review.googlesource.com/c/go/+/513275
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
This leaves the specific unification details out in favor
of a (forthcoming) section in an appendix.
Change-Id: If984c48bdf71c278e1a2759f9a18c51ef58df999
Reviewed-on: https://go-review.googlesource.com/c/go/+/507417
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Change-Id: I9cdb301163b67add39928c8fc7df2b7f3893f45e
Reviewed-on: https://go-review.googlesource.com/c/go/+/511836
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
