Mostly I need to tickle the builders, since I'm working on the
dashboard builders right now.
Change-Id: I833fc22bc942758a58791ed038634cdd812f5411
Reviewed-on: https://go-review.googlesource.com/2261
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Vitess and protobuf has moved to GitHub; update the links.
Change-Id: I2d90bde1a7f2b590c8b7b08ce73d6faa13b51da0
Reviewed-on: https://go-review.googlesource.com/2166
Reviewed-by: Andrew Gerrand <adg@golang.org>
These are the references that affect current Go users.
I left intact references in older release notes;
we can figure out what to do with them later.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/186140043
Conflicts:
doc/go1.4.html
Change-Id: I1032686f2b3ac6dacaf8f114b8c35cdf221330ca
Language clarification.
The existing rules for selector expressions imply
automatic dereferencing of pointers to struct fields.
They also implied automatic dereferencing of selectors
denoting methods. In almost all cases, such automatic
dereferencing does indeed take place for methods but the
reason is not the selector rules but the fact that method
sets include both methods with T and *T receivers; so for
a *T actual receiver, a method expecting a formal T
receiver, also accepts a *T (and the invocation or method
value expression is the reason for the auto-derefering).
However, the rules as stated so far implied that even in
case of a variable p of named pointer type P, a selector
expression p.f would always be shorthand for (*p).f. This
is true for field selectors f, but cannot be true for
method selectors since a named pointer type always has an
empty method set.
Named pointer types may never appear as anonymous field
types (and method receivers, for that matter), so this
only applies to variables declared of a named pointer
type. This is exceedingly rare and perhaps shouldn't be
permitted in the first place (but we cannot change that).
Amended the selector rules to make auto-deref of values
of named pointer types an exception to the general rules
and added corresponding examples with explanations.
Both gc and gccgo have a bug where they do auto-deref
pointers of named types in method selectors where they
should not:
See http://play.golang.org/p/c6VhjcIVdM , line 45.
Fixes#5769.
Fixes#8989.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/168790043
People viewing this locally will not have a /s/ on their local godoc.
tip.golang.org doesn't have one either.
Also change all golang.org links to https, to avoid mixed content
warnings when viewing https://golang.org/.
Fixes#9028.
LGTM=bradfitz, r
R=r, bradfitz
CC=adg, golang-codereviews
https://golang.org/cl/168250043
Add a short introductory section saying what most Go
programmers really need to know, which is that you
shouldn't have to read this document to understand
the behavior of your program.
LGTM=bradfitz, adg, tracey.brendan, iant, rsc, dsymonds
R=golang-codereviews, bradfitz, tracey.brendan, adg, iant, rsc, dsymonds
CC=golang-codereviews
https://golang.org/cl/158500043
Not a language change.
This is simply documenting the status quo which permits
builtin function names to be parenthesized in calls; e.g.,
both
len(s)
and
(((len)))(s)
are accepted by all compilers and go/types.
Changed the grammar by merging the details of BuiltinCall
with ordinary Calls. Also renamed the Call production to
Arguments which more clearly identifies that part of the
grammar and also matches better with its counterpart on
the declaration side (Parameters).
The fact that the first argument can be a type (for builtins)
or cannot be a type (for regular function calls) is expressed
in the prose, no need to make the grammar more complicated.
Fixes#9001.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, dave
CC=golang-codereviews
https://golang.org/cl/160570043
