They are not constant if their arguments have types that are variable size.
Fixes#53921
Change-Id: I2d46754c27f55a281331c099a11ea3cd85ec4e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/417917
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
[This CL is part of a sequence implementing the proposal #51082.
The design doc is at https://go.dev/s/godocfmt-design.]
Run the updated gofmt, which reformats doc comments,
on the main repository. Vendored files are excluded.
For #51082.
Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407
Reviewed-on: https://go-review.googlesource.com/c/go/+/384268
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A future change to gofmt will rewrite
// Doc comment.
//
func f()
to
// Doc comment.
func f()
Apply that change preemptively to all doc comments.
For #51082.
Change-Id: I4023e16cfb0729b64a8590f071cd92f17343081d
Reviewed-on: https://go-review.googlesource.com/c/go/+/384259
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
A long time ago, gofmt insisted on inserting tabs in /* */ comments
at the top level of the file, like this:
/*
Package doc comment.
*/
package p
Gofmt still insists on the tab for comments not at top level,
but it has relaxed the rules about top-level comments.
A few very old doc comments are indented, left over from the old rule.
We are considering formatting doc comments, and so to make
everything consistent, standardize on unindented doc comments
by removing tabs in the few doc comments that are still indented this way.
Also update some cmd/gofmt testdata to match.
Change-Id: I293742e39b52f8a48ec41f72ca4acdafa7ce43bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/384261
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
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>
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>
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>
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>
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
Ian Lance Taylor
Russ Cox
Matthew Dempsky
Keith Randall
Rob Pike
Daniel Martí
Josh Bleecher Snyder
Brad Fitzpatrick
Rahul Chaudhry
Robert Griesemer