Age | Commit message (Collapse) | Author |
|
For #19367
Change-Id: If0ff8ddba3b6b48e2e198cf3653e73284c7572a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/332409
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Updates #46742.
Change-Id: I044933a657cd1a5cdb29863e49751df5fe9c258a
Reviewed-on: https://go-review.googlesource.com/c/go/+/331069
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Updates #19367.
Updates #40481.
Change-Id: I578066ad68d2cd6bea50df1a534cf799e4404a7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312212
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
I've never seen a case where unsafe arithmetic is used to generate a nil.
(Something like var x uintptr; unsafe.Pointer(x - x).)
We can assume that if someone is doing arithmetic with pointers, the
result will be non-nil. Our unsafe rules already forbid this, although
we should be more explicit.
RELNOTE=It is invalid to convert a nil unsafe.Pointer to uintptr and back, with arithmetic.
(This was already invalid, but this statement has been added for clarification.)
Fixes #27180
Change-Id: I1880b7725a9fd99e4613799930fdad9aaa99e8f0
Reviewed-on: https://go-review.googlesource.com/c/146058
Reviewed-by: Austin Clements <austin@google.com>
|
|
Nothing is changing but the documentation, which did not mention
this property of these functions.
Fixes #27587.
Change-Id: I75bcee4a1dd9ec8cd82826c9a6e02ba7d599f719
Reviewed-on: https://go-review.googlesource.com/c/141377
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Fixes #24115
Change-Id: I89d3d5a9c0916fd2e21fe5930549c4129de8ab48
Reviewed-on: https://go-review.googlesource.com/96983
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Went mainly for the ones that make no sense, such as the ones
mid-sentence or after commas.
Change-Id: Ie245d2c19cc7428a06295635cf6a9482ade25ff0
Reviewed-on: https://go-review.googlesource.com/57293
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martà <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fixes #17818.
Change-Id: Id7242b0bdd5e1db254b44ae29900fc4f3362c743
Reviewed-on: https://go-review.googlesource.com/32828
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Follow-up to CL 27156
Change-Id: I4f1cfced2dced9c9fc8a05bbc00ec4229e85c5c9
Reviewed-on: https://go-review.googlesource.com/27314
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: Ib669d5241372326a46361ee096570e960b7a957f
Reviewed-on: https://go-review.googlesource.com/19082
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: I595379d2f02b0a43735f0375758e4997ce3b64a7
Reviewed-on: https://go-review.googlesource.com/18986
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Also document the special behavior of Alignof(s.f), and mention the
correspondence between Alignof and reflect.Type.{Align,FieldAlign}.
Change-Id: I6f81047a04c86887f1b1164473225616cae45a26
Reviewed-on: https://go-review.googlesource.com/18949
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Add docs for valid uses of Pointer.
Then document change made for #13372 in CL 18584.
Fixes #8994.
Change-Id: Ifba71e5aeafd11f684aed0b7ddacf3c8ec07c580
Reviewed-on: https://go-review.googlesource.com/18640
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
|
|
Change-Id: I369723c7a65f9a72c60b55704cebf40d78cf4f75
Reviewed-on: https://go-review.googlesource.com/3444
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
Change-Id: I73a416291a2374dbb8ce8586f24059f8dce56529
Reviewed-on: https://go-review.googlesource.com/3360
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
The compatibility guideline needs to be clear about this even
though it means adding a clause that was not there from the
beginning. It has always been understood, so this isn't really
a change in policy, just in its expression.
LGTM=bradfitz, gri, rsc
R=golang-codereviews, bradfitz, gri, rsc
CC=golang-codereviews
https://golang.org/cl/162060043
|
|
Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.
|