aboutsummaryrefslogtreecommitdiff
path: root/doc/go_spec.html
AgeCommit message (Collapse)Author
2024-05-02spec: clarify when range expression is evaluatedOlivier Mengué
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>
2024-04-26spec: clarify prose for range over numeric range expressionsRobert Griesemer
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>
2024-04-25spec: clarify when a range expression is evaluatedRobert Griesemer
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>
2024-04-11all: consistently use "IEEE 754" over "IEEE-754"Joe Tsai
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>
2024-03-04doc: close HTML tagscui fliter
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>
2024-02-07spec: fix typo in year (it's 2024 now)Robert Griesemer
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>
2024-01-30spec: clarify iteration variable type for range over integerRobert Griesemer
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>
2024-01-05doc: s/adjustements/adjustmentsJes Cok
Change-Id: I904b1adee13c63bc7d47d4325b794c1a650eb18d GitHub-Last-Rev: 8eced8db566c4dea433260f87456902542095970 GitHub-Pull-Request: golang/go#64969 Reviewed-on: https://go-review.googlesource.com/c/go/+/554255 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Jes Cok <xigua67damn@gmail.com>
2023-12-27doc: fix typo in example in specRobert Griesemer
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>
2023-12-27doc: document new iteration variable semantics in specRobert Griesemer
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>
2023-12-27doc: document version at which new language features were introduced in specRobert Griesemer
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>
2023-12-20doc: update unsafe.Pointer rule in specRobert Griesemer
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>
2023-12-05doc/go_spec.html: rename golang.org to go.devAlan Donovan
Fixes #64513 Change-Id: I45d6a4ba2170308260f3b8f7965affc9948f3fcf Reviewed-on: https://go-review.googlesource.com/c/go/+/547476 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Alan Donovan <adonovan@google.com>
2023-11-02spec: document range over integer expressionRobert Griesemer
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>
2023-10-17spec: explain eval order of binary operator examples with commentsRobert Griesemer
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>
2023-09-14spec: specify evaluation order for binary logical operationsMatthew Dempsky
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>
2023-08-21spec: clarify that []byte("") must be non-nilMatthew Dempsky
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>
2023-08-18spec: correct type parameter name used in exampleIan Lance Taylor
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>
2023-08-17spec: fix unification rule for inexact interface unificationRobert Griesemer
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>
2023-08-03spec: remove unnecessary sentenceRobert Griesemer
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>
2023-08-03doc: fix html tagscui fliter
Change-Id: I535bec2de8f4f7dd415896a020d71c373c22be56 Reviewed-on: https://go-review.googlesource.com/c/go/+/515155 Run-TryBot: shuang cui <imcusg@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: David Chase <drchase@google.com>
2023-07-31spec: add Appendix with detailed type unification rulesRobert Griesemer
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>
2023-07-26spec: update section on type unification for Go 1.21Robert Griesemer
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>
2023-07-21spec: fix a couple of minor mistakes in type inference sectionRobert Griesemer
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>
2023-07-20spec: update section on type inference for Go 1.21Robert Griesemer
The new section describes type inference as the problem of solving a set of type equations for bound type parameters. The next CL will update the section on unification to match the new inference approach. Change-Id: I2cb49bfb588ccc82d645343034096a82b7d602e2 Reviewed-on: https://go-review.googlesource.com/c/go/+/503920 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>
2023-07-18spec: clarify prose in rule for clear built-inRobert Griesemer
Per feedback on #56351. For #56351. Change-Id: I63dd1713a1efe4d7180d932dbd8e1510cbb32e90 Reviewed-on: https://go-review.googlesource.com/c/go/+/510935 TryBot-Bypass: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2023-06-14spec: explain in which situations function type arguments can be omittedRobert Griesemer
Change-Id: I9f008dba7ba6e30f0e62647482a3ed0b51bc1ad0 Reviewed-on: https://go-review.googlesource.com/c/go/+/502997 Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com>
2023-06-13spec: de-emphasize string(int) conversionsRobert Griesemer
Fixes #60731. Change-Id: I71fad1c8385b13d036bb0ce7ae6bd21e0f596e51 Reviewed-on: https://go-review.googlesource.com/c/go/+/502657 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com>
2023-06-13spec: document new program initialization processRobert Griesemer
For #57411. Change-Id: I94982d939d16ad17174f801cc167cc10ddc8da30 Reviewed-on: https://go-review.googlesource.com/c/go/+/501696 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2023-06-07spec: add temporary note to type inference sectionRobert Griesemer
The section on type inference has not been updated yet for Go 1.21. Add a temporary note so that readers referred to this section from the release notes are not confused. Change-Id: Idc4c74d6d700f891c625289e873ad5aa9c2c5213 Reviewed-on: https://go-review.googlesource.com/c/go/+/501308 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com>
2023-06-06spec: clarify min/max rules for numeric arguments (exclude NaNs)Robert Griesemer
Fixes #60570. Change-Id: I7ef834731ea26ceee5ec9b7438fdd8323aaf828e Reviewed-on: https://go-review.googlesource.com/c/go/+/500416 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>
2023-05-25spec: document min and max built-insRobert Griesemer
For #59488. Change-Id: I50f65216bf02b42c1e0619702833f4a6dbed8925 Reviewed-on: https://go-review.googlesource.com/c/go/+/498136 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com>
2023-05-24spec: re-order built-ins sections alphabetically (more or less)Robert Griesemer
Put the sections for the various built-ins into alphabetical order based on the built-in name, while keeping built-ins that belong together together. The order is now (captialized letter determines order): - Append - Clear - Close - Complex, real, imag - Delete - Len, cap - Make - Min, max (to be inserted here) - New - Panic, recover - Print, println There are some white space adjustments but no changes to the prose of the moved sections. Change-Id: Iaec509918c6bc965df3f28656374de03279bdc9e Reviewed-on: https://go-review.googlesource.com/c/go/+/498135 Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2023-04-13doc: correct spelling on placeholderDaniel Frederick Crisman
"placeholder" (no space) is already used in the spec and seems to be the preferred option. Removed space from "place holder". Change-Id: I9b98f62f0e3f5adb019b99f5271cc9d19abf505e GitHub-Last-Rev: ed5aaf9d02c294e87688066f6218e5d58b0f62bf GitHub-Pull-Request: golang/go#59626 Reviewed-on: https://go-review.googlesource.com/c/go/+/484576 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2023-04-11doc: add missing oxford comma in ConstantsDaniel Frederick Crisman
In the language specification under "Constants" the lists matching default types to untyped contstant types is missing an Oxford comma in the first list. I found a number of other places in the spec and #23442 that use the Oxford comma to support its use. Add missing Oxford comma in Constants default type list. Change-Id: I4562d692610334bc82452db076145d2414617a04 GitHub-Last-Rev: 8acdb60d6e255f73fdeb908d2540d4ee35db3fd7 GitHub-Pull-Request: golang/go#59528 Reviewed-on: https://go-review.googlesource.com/c/go/+/483555 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2023-04-11doc: fix "are" to "or" in core typescui fliter
Fixes #59506 Change-Id: I2f8b92e93b706b061ca0eb0bd52e5cf798ce9ede Reviewed-on: https://go-review.googlesource.com/c/go/+/483358 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
2023-02-20doc: add clear builtin to specCuong Manh Le
Fixes #56351 Change-Id: Ia87bf594553b7d0464b591106840f849571c5f39 Reviewed-on: https://go-review.googlesource.com/c/go/+/467755 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-19doc: do not use "==" in slice examplesCuong Manh Le
There's no slice comparison in Go. Change-Id: I5de1766c2adeb56ed12a577a4c46c12b2582b1c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/469015 Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-02-16doc: add missing builtin functions not permitted in statement contextCuong Manh Le
The typechecker already enforces this semantic, but the spec is not updated when unsafe.{SliceData,String,StringData} were added. Change-Id: I4ee8c564d5681b2a5fd31ff424a31bdf065d9f3b Reviewed-on: https://go-review.googlesource.com/c/go/+/467756 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-02-07doc: fix spec typoOleksandr Redko
Change-Id: I5e3aca2b8fc78f38c9e2cdc67adf86d57ac85b1c GitHub-Last-Rev: 0e5ddffe33f5677449d24e09bdb332e3d5c08aa3 GitHub-Pull-Request: golang/go#58353 Reviewed-on: https://go-review.googlesource.com/c/go/+/465615 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-01-19runtime: replace panic(nil) with panic(new(runtime.PanicNilError))Russ Cox
Long ago we decided that panic(nil) was too unlikely to bother making a special case for purposes of recover. Unfortunately, it has turned out not to be a special case. There are many examples of code in the Go ecosystem where an author has written panic(nil) because they want to panic and don't care about the panic value. Using panic(nil) in this case has the unfortunate behavior of making recover behave as though the goroutine isn't panicking. As a result, code like: func f() { defer func() { if err := recover(); err != nil { log.Fatalf("panicked! %v", err) } }() call1() call2() } looks like it guarantees that call2 has been run any time f returns, but that turns out not to be strictly true. If call1 does panic(nil), then f returns "successfully", having recovered the panic, but without calling call2. Instead you have to write something like: func f() { done := false defer func() { if err := recover(); !done { log.Fatalf("panicked! %v", err) } }() call1() call2() done = true } which defeats nearly the whole point of recover. No one does this, with the result that almost all uses of recover are subtly broken. One specific broken use along these lines is in net/http, which recovers from panics in handlers and sends back an HTTP error. Users discovered in the early days of Go that panic(nil) was a convenient way to jump out of a handler up to the serving loop without sending back an HTTP error. This was a bug, not a feature. Go 1.8 added panic(http.ErrAbortHandler) as a better way to access the feature. Any lingering code that uses panic(nil) to abort an HTTP handler without a failure message should be changed to use http.ErrAbortHandler. Programs that need the old, unintended behavior from net/http or other packages can set GODEBUG=panicnil=1 to stop the run-time error. Uses of recover that want to detect panic(nil) in new programs can check for recover returning a value of type *runtime.PanicNilError. Because the new GODEBUG is used inside the runtime, we can't import internal/godebug, so there is some new machinery to cross-connect those in this CL, to allow a mutable GODEBUG setting. That won't be necessary if we add any other mutable GODEBUG settings in the future. The CL also corrects the handling of defaulted GODEBUG values in the runtime, for #56986. Fixes #25448. Change-Id: I2b39c7e83e4f7aa308777dabf2edae54773e03f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/461956 Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Russ Cox <rsc@golang.org>
2022-12-15spec: fix typoRobert Griesemer
Fixes #57323. Change-Id: I77d3d747aa4746bb9a8cca0c0500ff8fa6ae33a3 Reviewed-on: https://go-review.googlesource.com/c/go/+/457915 Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2022-12-14spec: document which recursive arrays and structs are valid/invalidRobert Griesemer
Fixes #5069. Change-Id: I4bc0f52a9cd1e64a49846dffeb4be5cbecc29a96 Reviewed-on: https://go-review.googlesource.com/c/go/+/457342 TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
2022-12-14spec: document illegal recursive type parameter listsRobert Griesemer
Fixes #40882. Change-Id: I90f99d75e6d66f857b6ab8789c6d436f85d20993 Reviewed-on: https://go-review.googlesource.com/c/go/+/457515 TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
2022-12-14spec: describe new semantics for comparable and constraint satisfactionRobert Griesemer
For #56548. Fixes #57012. Change-Id: I44f850522e52b1811025fb31bcef289da8f8089d Reviewed-on: https://go-review.googlesource.com/c/go/+/457437 TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2022-12-14spec: introduce notion of strict comparabilityRobert Griesemer
- Rephrase the notion of "comparability" from a property of values (operands) to a property of types and adjust dependent prose. - Introduce the notion of "strict comparability". - Fix the definitions of comparability for type interfaces and type parameters. - Define the predeclared identifier "comparable" as stricly comparable. These changes address existing problems in the spec as outlined in the section on "Related spec issues" in issue #56548. For #56548. Change-Id: Ibc8c2f36d92857a5134eadc18358624803d3dd21 Reviewed-on: https://go-review.googlesource.com/c/go/+/457095 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2022-12-08doc: fix typoZhizhen He
Change-Id: Ie639fe39b83336c0d885cdcb2fddc06f2b06c2dd GitHub-Last-Rev: b5cc78ad42ee57d77cf027cc5fb6840eb38a0f1b GitHub-Pull-Request: golang/go#57082 Reviewed-on: https://go-review.googlesource.com/c/go/+/455196 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
2022-11-30spec: document conversion from slice to arrayTim King
Document that a slice can be converted to either an array or a pointer to an array of a matching underlying array type. This was documented in the "Conversions from slice to array or array pointer" subsection, but not in the list of conversion rules. Updates #46505. Change-Id: I16a89a63ef23c33580129952415e977a8f334009 Reviewed-on: https://go-review.googlesource.com/c/go/+/452936 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Tim King <taking@google.com>
2022-11-23spec: add a link to Allocation section in section on append built-inRobert Griesemer
If needed, the built-in function append allocates a new underlying array. While we (probably) don't want to specify exactly how much is allocated (the prose is deliberately vague), if there's more space allocated than needed (cap > len after allocation), that extra space is zeroed. Use an explicit link to the section on Allocation which explicitly states that newly allocated memory is zeroed. Fixes #56684. Change-Id: I9805d37c263b87860ea703ad143f738a0846247e Reviewed-on: https://go-review.googlesource.com/c/go/+/452619 Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-11-23spec: document that trailing comma is valid after index in index expressionsRobert Griesemer
At parse time we don't know if a[i] is an index expression or a type (or function) instantiation. Because instantiations accept a list of type arguments, and argument lists permit a trailing comma, a[i,] is either an instantiation or index expression. Document that a trailing comma is permitted in the syntax for index expressions. For comparison, the same problem arises with conversions which cannot be distinguished from function calls at parse time. The spec also permits a trailing comma for conversions T(x,). The grammar adjustment is the same (see line 5239). Fixes #55007. Change-Id: Ib9101efe52031589eb95a428cc6dff940d939f9e Reviewed-on: https://go-review.googlesource.com/c/go/+/452618 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion