e.g. ·Name instead of package·Name for automatic stack map to
be applied from its Go prototype.
The underlying reason is that liblink look up name with suffix
".args_stackmap" for the stackmap coming from its Go prototype,
but all the Go functions are named "".Name as this stage. Thus
an assembly function named package·Name will never find its
stackmap, which is named "".package.Name.args_stackmap.
Perhaps cmd/vet should give a warning for this.
Change-Id: I10d154a73ec969d574d20af877f747424350fbd1
Reviewed-on: https://go-review.googlesource.com/2588
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Only documentation / comment changes. Update references to
point to golang.org permalinks or go.googlesource.com/go.
References in historical release notes under doc are left as is.
Change-Id: Icfc14e4998723e2c2d48f9877a91c5abef6794ea
Reviewed-on: https://go-review.googlesource.com/4060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#9756.
Change-Id: If4ee6fe10f8f90294ff9c5e7480371494094b111
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/3740
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
These are no longer used by anything.
Change-Id: I50c971418b07cafc983242833a196ba2028a2723
Reviewed-on: https://go-review.googlesource.com/3603
Reviewed-by: Rob Pike <r@golang.org>
This manually reverts 555da73 from #6372 which implies a
minimum FreeBSD version of 8-STABLE.
Updates docs to mention new minimum requirement.
Fixes#9627
Change-Id: I40ae64be3682d79dd55024e32581e3e5e2be8aa7
Reviewed-on: https://go-review.googlesource.com/3020
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing go code document did not link to the GOPATH documentation.
This will link to it, in hopes of making it more discoverable.
Change-Id: Ie4ded2fdce08f412e4acbcc93acdd76f5791b84a
Reviewed-on: https://go-review.googlesource.com/2265
Reviewed-by: Andrew Gerrand <adg@golang.org>
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
Move the release notes into an HTML file.
Start writing the text.
LGTM=rsc
R=golang-codereviews, bradfitz, kamil.kisiel, tracey.brendan, rsc
CC=golang-codereviews
https://golang.org/cl/161350043
Wrong article, one stylistic point that bothers someone (but not me).
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/156680043
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
Per suggestion from rsc as a result of the dicussion of
(abandoned) CL 153110044.
Fixes#7192.
LGTM=r, rsc, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/163050043
This new text won't stop the whining but it might focus the whining a little more.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/146680044
Not a language change.
Several inaccuracies were fixed:
1) A variable declaration may declare more than just one
variable.
2) Variable initialization follows the rules of assignments,
including n:1 assignments. The existing wording implied a 1:1
or n:n rule and generally was somewhat unspecific.
3) The rules for variable declarations with no types and
untyped initialization expressions had minor holes (issue 8088).
4) Clarified the special cases of assignments of untyped values
(we don't just have untyped constants, but also untyped bools,
e.g. from comparisons). The new wording is more direct.
To that end, introduced the notion of an untyped constant's
"default type" so that the same concept doesn't have to be
repeatedly introduced.
Fixes#8088.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/142320043
The existing spec rules on package initialization were
contradictory: They specified that 1) dependent variables
are initialized in dependency order, and 2) independent
variables are initialized in declaration order. This 2nd
rule cannot be satisfied in general. For instance, for
var (
c = b + 2
a = 0
b = 1
)
because of its dependency on b, c must be initialized after b,
leading to the partial order b, c. Because a is independent of
b but is declared before b, we end up with the order: a, b, c.
But a is also independent of c and is declared after c, so the
order b, c, a should also be valid in contradiction to a, b, c.
The new rules are given in form of an algorithm which outlines
initialization order explicitly.
gccgo and go/types already follow these rules.
Fixes#8485.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://golang.org/cl/142880043
