Signed-off-by: Steven Phillips <steve@tryingtobeawesome.com>
Change-Id: Ie7c3253a5e1cd43be8fa12bad340204cc6c5ca76
Reviewed-on: https://go-review.googlesource.com/23677
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We say "cancelation," not "cancellation."
Fixes#15928.
Change-Id: I66d545404665948a27281133cb9050eebf1debbb
Reviewed-on: https://go-review.googlesource.com/23673
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Both compilers and also go/types don't permit duplicate types in
type switches; i.e., this spec change is documenting a status quo
that has existed for some time.
Furthermore, duplicate nils are not accepted by gccgo or go/types;
and more recently started causing a compiler error in gc. Permitting
them is inconsistent with the existing status quo.
Rather than making it an implementation restriction (as we have for
expression switches), this is a hard requirement since it was enforced
from the beginning (except for duplicate nils); it is also a well
specified requirement that does not pose a significant burden for
an implementation.
Fixes#15896.
Change-Id: If12db5bafa87598b323ea84418cb05421e657dd8
Reviewed-on: https://go-review.googlesource.com/23584
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The original draft mentioned support for json.Marshaler, but that's
not the case. JSON supports only string keys (not arbitrary JSON)
so only encoding.TextMarshaller is supported.
Change-Id: I7788fc23ac357da88e92aa0ca17b513260840cee
Reviewed-on: https://go-review.googlesource.com/23529
Reviewed-by: Andrew Gerrand <adg@golang.org>
Document the following:
* That the algorithmic changes are still compliant with RFC 1951. I remember
people having questions regarding this issue, and it would be good to re-assure
them that it is still standards compliant.
* io.EOF can now be returned early (c27efce66b)
* Use the term "decompress" when referred to as an action. The term "uncompressed"
or "decompressed" are both valid as ways to represent the current state of the data.
Change-Id: Ie29ebce709357359e7c36d3e7f3d53b260eaadfa
Reviewed-on: https://go-review.googlesource.com/23552
Reviewed-by: Andrew Gerrand <adg@golang.org>
Document new behavior about signal name printing
in panics as per CL golang.org/cl/22753.
For #15810
Change-Id: I9c677d5dd779b41e82afa25e3c797d8e739600d3
Reviewed-on: https://go-review.googlesource.com/23493
Reviewed-by: Russ Cox <rsc@golang.org>
Mostly complete but a few TODOs remain for future CLs.
For #15810.
Change-Id: I81ee19d1088d192cf709a5f7e6b7bcc44ad892ac
Reviewed-on: https://go-review.googlesource.com/23379
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Current number was out-of-date since adding MIPS.
Change-Id: I565342a92de3893b75cdfb76fa39f7fdf15672da
Reviewed-on: https://go-review.googlesource.com/22952
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Note that the spec already makes that point with a comment in the very first
example for struct field tags. This change is simply stating this explicitly
in the actual spec prose.
- gccgo and go/types already follow this rule
- the current reflect package API doesn't distinguish between absent tags
and empty tags (i.e., there is no discoverable difference)
Fixes#15412.
Change-Id: I92f9c283064137b4c8651630cee0343720717a02
Reviewed-on: https://go-review.googlesource.com/22391
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
A late response to CL 22163.
Change-Id: I5275a22af7081875af0256da296811f4fe9832dc
Reviewed-on: https://go-review.googlesource.com/22296
Reviewed-by: David Symonds <dsymonds@golang.org>
Per a suggestion from mdempsky.
Both gc and gccgo consider a statement list as terminating if the
last _non_empty_ statement is terminating; i.e., trailing semis are
ok. Only gotype followed the current stricter rule in the spec.
This change adjusts the spec to match gc and gccgo behavior. In
support of this change, the spec has a matching rule for fallthrough,
which in valid positions may be followed by trailing semis as well.
For details and examples, see the issue below.
Fixes#14422.
Change-Id: Ie17c282e216fc40ecb54623445c17be111e17ade
Reviewed-on: https://go-review.googlesource.com/19981
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This will allow us to mechanically substitute these strings
using javascript (in a forthcoming change to x/tools/godoc).
Updates #14371
Change-Id: I96e876283060ffbc9f3eabaf55d6b880685453e1
Reviewed-on: https://go-review.googlesource.com/22055
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Named returned values should only be used on public funcs and methods
when it contributes to the documentation.
Named return values should not be used if they're only saving the
programmer a few lines of code inside the body of the function,
especially if that means there's stutter in the documentation or it
was only there so the programmer could use a naked return
statement. (Naked returns should not be used except in very small
functions)
This change is a manual audit & cleanup of public func signatures.
Signatures were not changed if:
* the func was private (wouldn't be in public godoc)
* the documentation referenced it
* the named return value was an interesting name. (i.e. it wasn't
simply stutter, repeating the name of the type)
There should be no changes in behavior. (At least: none intended)
Change-Id: I3472ef49619678fe786e5e0994bdf2d9de76d109
Reviewed-on: https://go-review.googlesource.com/20024
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
The () parentheses grouped wrongly. Removed them completely in
favor of separate 2- and 3-index slice alternatives which is
clearer.
Fixes#14477.
Change-Id: I0b7521ac912130d9ea8740b8793b3b88e2609418
Reviewed-on: https://go-review.googlesource.com/19853
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The Go 1.6 release notes say that Go 1.7 will remove support
for the GO15VENDOREXPERIMENT environment variable,
making vendoring always on. Do that.
Change-Id: Iba8b79532455828869c1a8076a82edce84259468
Reviewed-on: https://go-review.googlesource.com/19615
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The Go 1.6 release notes say we'll remove the “-X name value” form
(in favor of the “-X name=value” form) in Go 1.7.
Do that.
Also establish the doc/go1.7.txt file.
Change-Id: Ie4565a6bc5dbcf155181754d8d92bfbb23c75338
Reviewed-on: https://go-review.googlesource.com/19614
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Go 1.6 is soon (but not yet).
Fixes#14301.
Change-Id: I85e329b643adcb5d4fa680c5333fbc1f928d4d9d
Reviewed-on: https://go-review.googlesource.com/19550
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Fixes#13651.
Change-Id: I1d21b49e2b5bc6c507eb084d6d2553e5a9c607cf
Reviewed-on: https://go-review.googlesource.com/19552
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Go 1.6 significantly improves pause times for large heaps, but it
improves them in many other situations as well, such as when goroutine
churn is high, allocation rate is high, or when there are many
finalizers. Hence, make the statement about pause times a bit more
general.
Change-Id: Ic034b1c904c39dd1d966ee7fa96ca8bbb3614e53
Reviewed-on: https://go-review.googlesource.com/19504
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently we use "Section's" as the plural of the debug/elf Section
struct. Change this to "Sections" because it's not possessive and
doesn't seem to fall in to any special cases were the apostrophe is
acceptable.
Change-Id: Id5d3abbd748502a67ead3f483182ee7729db94a2
Reviewed-on: https://go-review.googlesource.com/19505
Reviewed-by: Russ Cox <rsc@golang.org>
The plan9.bell-labs.com site has fallen into disrepair.
We'll instead use the site maintained by contributor David du Colombier.
Fixes#14233
Change-Id: I0c702e5d3b091cccd42b288ea32f34d507a4733d
Reviewed-on: https://go-review.googlesource.com/19240
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Also fix a few bad links.
Change-Id: If04cdd312db24a827a3c958a9974c50ab148656c
Reviewed-on: https://go-review.googlesource.com/18979
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes#13954
Change-Id: I4c01e9bb3fb08e8b9fa14d4c59b7ea824ba3f0c9
Reviewed-on: https://go-review.googlesource.com/18937
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Consider this code:
func f(*int)
func g() {
p := new(int)
f(p)
}
where f is an assembly function.
In general liveness analysis assumes that during the call to f, p is dead
in this frame. If f has retained p, p will be found alive in f's frame and keep
the new(int) from being garbage collected. This is all correct and works.
We use the Go func declaration for f to give the assembly function
liveness information (the arguments are assumed live for the entire call).
Now consider this code:
func h1() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
}
Here syscall.Syscall is taking the place of f, but because its arguments
are uintptr, the liveness analysis and the garbage collector ignore them.
Since p is no longer live in h once the call starts, if the garbage collector
scans the stack while the system call is blocked, it will find no reference
to the new(int) and reclaim it. If the kernel is going to write to *p once
the call finishes, reclaiming the memory is a mistake.
We can't change the arguments or the liveness information for
syscall.Syscall itself, both for compatibility and because sometimes the
arguments really are integers, and the garbage collector will get quite upset
if it finds an integer where it expects a pointer. The problem is that
these arguments are fundamentally untyped.
The solution we have taken in the syscall package's wrappers in past
releases is to insert a call to a dummy function named "use", to make
it look like the argument is live during the call to syscall.Syscall:
func h2() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
use(unsafe.Pointer(p))
}
Keeping p alive during the call means that if the garbage collector
scans the stack during the system call now, it will find the reference to p.
Unfortunately, this approach is not available to users outside syscall,
because 'use' is unexported, and people also have to realize they need
to use it and do so. There is much existing code using syscall.Syscall
without a 'use'-like function. That code will fail very occasionally in
mysterious ways (see #13372).
This CL fixes all that existing code by making the compiler do the right
thing automatically, without any code modifications. That is, it takes h1
above, which is incorrect code today, and makes it correct code.
Specifically, if the compiler sees a foreign func definition (one
without a body) that has uintptr arguments, it marks those arguments
as "unsafe uintptrs". If it later sees the function being called
with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
as having escaped, and it makes sure to hold x in a live temporary
variable until the call returns, so that the garbage collector cannot
reclaim whatever heap memory x points to.
For now I am leaving the explicit calls to use in package syscall,
but they can be removed early in a future cycle (likely Go 1.7).
The rule has no effect on escape analysis, only on liveness analysis.
Fixes#13372.
Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
Reviewed-on: https://go-review.googlesource.com/18584
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Now there are ARM downloads too.
Change-Id: I236381508c69d56748e672d184b92caa715e81ae
Reviewed-on: https://go-review.googlesource.com/18342
Reviewed-by: Andrew Gerrand <adg@golang.org>
The old link died; replace with an archive.org copy.
Fixes#13345.
Change-Id: Ic4a7fdcf258e1ff3b4a02ecb4f237ae7db2686c7
Reviewed-on: https://go-review.googlesource.com/18335
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also reference the new Transport.ExpectContinueTimeout after the
mention of 100-continue.
Fixes#13721
Change-Id: I3445c011ed20f29128092c801c7a4bb4dd2b8351
Reviewed-on: https://go-review.googlesource.com/18281
Reviewed-by: Andrew Gerrand <adg@golang.org>
Slightly rephrased sentence to emphasize the contents of the
Unicode categories w/o repeating the full category name each
time.
Fixes#13414.
Change-Id: Icd32ff1547fa81e866c5937a631c3344bb6087c6
Reviewed-on: https://go-review.googlesource.com/18265
Reviewed-by: Rob Pike <r@golang.org>
The proper term is "untyped boolean".
Change-Id: Id871164190a03c64a8a8987b1ad5d8653a21d96e
Reviewed-on: https://go-review.googlesource.com/16135
Reviewed-by: Robert Griesemer <gri@golang.org>
The spec defines precise numeric constants which do not overflow.
Consequently, +/-Inf and NaN values were excluded. The case was not
clear for -0.0 but they are mostly of interest to determine the sign
of infinities which don't exist.
That said, the conversion rules explicitly say that T(x) (for a numeric
x and floating-point type T) is the value after rounding per IEEE-754.
The result is constant if x is constant. Rounding per IEEE-754 can
produce a -0.0 which we cannot represent as a constant.
Thus, the spec is inconsistent. Attempt to fix the inconsistency by
adjusting the rounding rule rather than letting -0.0 into the language.
For more details, see the issue below.
Open to discussion.
Fixes#12576.
Change-Id: Ibe3c676372ab16d9229f1f9daaf316f761e074ee
Reviewed-on: https://go-review.googlesource.com/14727
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The prose discussing composite literals referred to the composite
literal type with 'LiteralType', denoting the literal type's EBNF
production explicitly. Changed 'LiteralType' to 'literal type' to
remove the literal (no pun intended) connection and instead mean
the underlying type. Seems a simpler and more readable change
than referring to the underlying type everywhere explicitly.
Fixes#12717.
Change-Id: I225df95f9ece2664b19068525ea8bda5ca05a44a
Reviewed-on: https://go-review.googlesource.com/14851
Reviewed-by: Rob Pike <r@golang.org>
Fixes#12288.
For inclusion in the 1.5.1 release.
Change-Id: I9354b7eaa76000498465c4a5cbab7246de9ecb7c
Reviewed-on: https://go-review.googlesource.com/14382
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Start go1.6.txt with a note that nacl ports are no longer
restricted to pepper_41 and a record of the text/template change.
Change-Id: I21dda64aec113c35caf1d565f29e3aac8171480a
Reviewed-on: https://go-review.googlesource.com/14004
Reviewed-by: Rob Pike <r@golang.org>
This makes sure the release page in the release will mention the release.
Fixes#12102.
Change-Id: I36befd7dba7ba9e70ae3335e21c8841179ac4eff
Reviewed-on: https://go-review.googlesource.com/13490
Reviewed-by: Rob Pike <r@golang.org>
Saying "Power 64" was wrong for reasons I don't remember.
(Those reasons are why we stopped using GOARCH=power64.)
Change-Id: Ifaac78d5733bfc780df01b1a66da766af0b17726
Reviewed-on: https://go-review.googlesource.com/13675
Reviewed-by: Rob Pike <r@golang.org>
Make clear that this list is the list of supported systems
for binary distributions, and that other systems may be
able to build the distribution from source, in addition
to using gccgo.
Drop freebsd/arm from the list on this page.
We have never issued a binary distribution for freebsd/arm,
and we're not going to start in Go 1.5, since we don't even
have a working builder for it.
Drop freebsd/386 from the list on the page,
because we are unable to build binary distributions, per adg.
I think the wording here should probably be revised further,
but not now.
Change-Id: Ib43b6b64f5c438bfb9aa4d3daa43393f1e33b71f
Reviewed-on: https://go-review.googlesource.com/13690
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The SetOutput function has been there since Go 1.
Fixes#12162.
Change-Id: I66210374877581e42689f9943532141659a55ca7
Reviewed-on: https://go-review.googlesource.com/13637
Reviewed-by: Rob Pike <r@golang.org>
Fixes#12062
Updates #11961
The sRPC nameservice was removed in pepper 42. For Go 1.5 stipulate
that NaCl requires pepper 41 only.
Change-Id: Ic88ba342d41f673391efaa96fb581712fa10a0fd
Reviewed-on: https://go-review.googlesource.com/13341
Reviewed-by: Andrew Gerrand <adg@golang.org>
First step towards cleaning up the operator section - no language
changes. Specifically:
- Grouped arithmetic operations by types (integer, floating-point,
string), with corresponding h4 headings.
- Changed Operator precedence title from h3 to h4.
- Moved Integer Overflow section after integer operations and changed
its title from h3 to h4.
This puts things that belong together closer. No heading id's were
lost (in case of references from outside the spec).
Change-Id: I6b349ba8d86a6ae29b596beb297cc45c81e69399
Reviewed-on: https://go-review.googlesource.com/13143
Reviewed-by: Rob Pike <r@golang.org>
Missed in CL 13074.
Change-Id: Ic0600341abbc423cd8d7b2201bf50e3b0bf398a7
Reviewed-on: https://go-review.googlesource.com/13167
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tracing functionality was moved from runtime/pprof to runtime/trace.
Change-Id: I694e0f209d043c7ffecb113f1825175bf963dde3
Reviewed-on: https://go-review.googlesource.com/13074
Reviewed-by: Rob Pike <r@golang.org>
This change allows the download page to redirect the user to
/doc/install?download=filename so the user can see installation
instructions specific to the file they are downloading.
This change also expands the "Test your Go installation" section
to instruct the user to create a workspace, hopefully leading
to less confusion down the line.
It also changes the front page download link to go directly
to the downloads page, which will in turn take them to the
installation instructions (the original destination).
This is related to this change to the tools repo:
https://golang.org/cl/13180
Change-Id: I658327bdb93ad228fb1846e389b281b15da91b1d
Reviewed-on: https://go-review.googlesource.com/13151
Reviewed-by: Chris Broadfoot <cbro@golang.org>
I walked through the steps for a contribution but ended up
with an error when doing "git mail" because I didn't have a
signed agreement.
Added a section to check for or create one through Gerrit right
after the user has created the account and logged in.
Moved some info from copyright section to the new section.
Change-Id: I79bbd3e18fc3a742fa59a242085da14be9e19ba0
Reviewed-on: https://go-review.googlesource.com/13062
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
The spec didn't specify several aspects of expression switches:
- The switch expression is evaluated exactly once.
- Switch expressions evaluating to an untyped value are converted
to the respective default type before use.
- An (untyped) nil value is not permitted as expression switch
value. (We could permit it relatively easily, but gc doesn't,
and disallowing it is in symmetry with the rules for var decls
without explicit type and untyped initializer expressions.)
- The comparison x == t between each case expression x and
switch expression value t must be valid.
- (Some) duplicate constant case expressions are not permitted.
This change also clarifies the following issues:
4524: mult. equal int const switch case values should be illegal
-> spec issue fixed
6398: switch w/ no value uses bool rather than untyped bool
-> spec issue fixed
11578: allows duplicate switch cases -> go/types bug
11667: int overflow in switch expression -> go/types bug
11668: use of untyped nil in switch -> not a gc bug
Fixes#4524.
Fixes#6398.
Fixes#11668.
Change-Id: Iae4ab3e714575a5d11c92c9b8fbf027aa706b370
Reviewed-on: https://go-review.googlesource.com/12711
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Also make the spelling consistent in asm.html
Change-Id: Ifa751eee288fe0634cd317eb827f3e408b199620
Reviewed-on: https://go-review.googlesource.com/12501
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This is a corner case but it is suggested we call it out.
Fixes#11798.
Change-Id: I2ddb5b363cd2921666dbf03bbf98107697ca40e5
Reviewed-on: https://go-review.googlesource.com/12460
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The document `doc/go_spec.html` uses "preceeding" instead of the word
"preceding" in one place.
Fixed another occurrence in `src/go/types/typexpr.go`.
Change-Id: Ic67f62026b5c9d002c5c5632299f14ecac8b02ae
Reviewed-on: https://go-review.googlesource.com/12354
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also add a link to a couple of the talks from GopherCon 2015.
Change-Id: I11e1c550e999553163d3fb5e900f167c849ce33f
Reviewed-on: https://go-review.googlesource.com/12287
Reviewed-by: Andrew Gerrand <adg@golang.org>
Also use more consistent language for the new build options.
Change-Id: I88cbe200c13f452713be73d2e00337ddb793b8c6
Reviewed-on: https://go-review.googlesource.com/12172
Reviewed-by: Rob Pike <r@golang.org>
This is the first mention of the fmt package in the changes list.
Change-Id: I5d378d8707e6735e0e590527db4196b517fefd72
Reviewed-on: https://go-review.googlesource.com/12198
Reviewed-by: Andrew Gerrand <adg@golang.org>
Still to do: ARM64 and PPC64. These architectures are woefully underdocumented.
Change-Id: Iedcf767a7e0e1c931812351940bc08f0c3821212
Reviewed-on: https://go-review.googlesource.com/12110
Reviewed-by: Russ Cox <rsc@golang.org>
The previous commit (git 2ae77376) just did golang.org. This one
includes golang.org subdomains like blog, play, and build.
Change-Id: I4469f7b307ae2a12ea89323422044e604c5133ae
Reviewed-on: https://go-review.googlesource.com/12071
Reviewed-by: Rob Pike <r@golang.org>
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
The architecture-specific details will be updated and expanded in
a subsequent CL (or series thereof).
Update #10096
Change-Id: I59c6be1fcc123fe8626ce2130e6ffe71152c87af
Reviewed-on: https://go-review.googlesource.com/11954
Reviewed-by: Russ Cox <rsc@golang.org>
Don't know why, but git deleted the previous version of this change.
This is the same change as https://go-review.googlesource.com/11884,
which I will now abandon, with a couple of fixes.
Almost all done now. Could use help with the TODOs.
Major missing piece is the trace command. Vendoring
section is also weak, but it's also undocumented elsewhere.
Change-Id: I5d8556b23aa6628eb7bf0e330d4dd8d4ac2157c5
Reviewed-on: https://go-review.googlesource.com/11887
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also add words about the assembler.
Change-Id: I9bd8cc88076f06b0eef36a07f57d1ad5d9261d8d
Reviewed-on: https://go-review.googlesource.com/11853
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Everything in the library but crypto and net.
Change-Id: I89b21b9621e6d338fa1891da0eabba5d7d2fe349
Reviewed-on: https://go-review.googlesource.com/11820
Reviewed-by: Russ Cox <rsc@golang.org>
No need to update the date; this is not a spec change.
Change-Id: I10a31234ed985c59e5d9b5328664a36661cef31e
Reviewed-on: https://go-review.googlesource.com/11531
Reviewed-by: Andrew Gerrand <adg@golang.org>
Just a copy, other than adding a header, preparatory to preparing the release notes.
Change-Id: Ia4dc27777b96b1e898d9873e7d38e6e795057698
Reviewed-on: https://go-review.googlesource.com/11474
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This sometime worries new contributors.
Hopefully mentioning it here will help.
Fixes#11300.
Change-Id: Ica7f10d749731704ac6a2c39c7dcba389996011e
Reviewed-on: https://go-review.googlesource.com/11236
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This also includes some other minor updates to the documentation.
Change-Id: Iafab353727d7622d125b97fbdeaa81525b7a92aa
Reviewed-on: https://go-review.googlesource.com/11123
Reviewed-by: Yves Junqueira <yves.junqueira@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
When reading along the article, the extra code added in the final
version is not explained. The main function calls flag.Parse(), for
example, which will cause an error, unless the readers looks at the
entirety of final.go to see the import added.
The file shown to the users no longer has the extra flags. The testing
code is now in a patch that gets applied to final.go in order to create
final-test.go. This is the file that will be used to test the code,
matching final.go as much as possible.
Change-Id: I022f5f6c88e107c8ba5623661d74a8d260d05266
Reviewed-on: https://go-review.googlesource.com/11061
Reviewed-by: Andrew Gerrand <adg@golang.org>
Suggested by mdempsky (see also issue #11161).
Change-Id: I1ab28febe19b7a092029499015073ce8749b4d99
Reviewed-on: https://go-review.googlesource.com/10960
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These were found by grepping the comments from the go code and feeding
the output to aspell.
Change-Id: Id734d6c8d1938ec3c36bd94a4dbbad577e3ad395
Reviewed-on: https://go-review.googlesource.com/10941
Reviewed-by: Aamir Khan <syst3m.w0rm@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reflect the process changes where AUTHORS and CONTRIBUTORS
files are updated automatically based on commit logs
and Google committers no longer need to do it manually
on the first contributors.
The documentation update will help to avoid requests to be
added from new contributors.
Change-Id: I67daae5bd21246cf79fe3724838889b929bc5e66
Reviewed-on: https://go-review.googlesource.com/10824
Reviewed-by: Rob Pike <r@golang.org>
I think it's worth mentioning.
But the final decision is up to you.
Change-Id: I3959132600ecc554988524ede73a7f6e8eac8353
Reviewed-on: https://go-review.googlesource.com/10551
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
- no "visible" change to spec but for updated date
- retired several outdated TODO items
- filed non-urgent issues 10953, 10954, 10955 for current TODOs
Change-Id: If87ad0fb546c6955a6d4b5801e06e5c7d5695ea2
Reviewed-on: https://go-review.googlesource.com/10382
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL removes the remaining visible uses of the "architecture letter" concept.
(They are no longer in tool names nor in source directory names.)
Because the architecture letter concept is now gone, delete GOCHAR
from "go env" output, and change go/build.ArchChar to return an
error always.
The architecture letter is still used in the compiler and linker sources
as a clumsy architecture enumeration, but that use is not visible to
Go users and can be cleaned up separately.
Change-Id: I4d97a38f372003fb610c9c5241bea440d9dbeb8d
Reviewed-on: https://go-review.googlesource.com/10289
Reviewed-by: Rob Pike <r@golang.org>
This is a duplicate of CL 9491.
That CL broke the build due to pprof shortcomings
and was reverted in CL 9565.
CL 9623 fixed pprof, so this can go in again.
Fixes#10659.
Change-Id: If470fc90b3db2ade1d161b4417abd2f5c6c330b8
Reviewed-on: https://go-review.googlesource.com/10212
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The spec explains later in the "Operator precedence" section that *
has a higher precedence than +, but the current production rule
requires that "1 + 2 * 3" be parsed as "(1 + 2) * 3", instead of the
intended "1 + (2 * 3)".
The new production rule better matches cmd/internal/gc/go.y's grammar:
expr:
uexpr
| expr LOROR expr
| expr LANDAND expr
| ...
Fixes#10151.
Change-Id: I13c9635d6ddf1263cafe7cc63e68f3e5779e24ba
Reviewed-on: https://go-review.googlesource.com/9163
Reviewed-by: Robert Griesemer <gri@golang.org>
In the Slices section of Effective Go, the os package's File.Read
function is used as an example. Unfortunately the function signature
does not match the function's code in the example, nor the os package's
documentation. This change updates the function signature to match
the os package and the pre-existing function code.
Change-Id: Iae9f30c898d3a1ff8d47558ca104dfb3ff07112c
Reviewed-on: https://go-review.googlesource.com/9845
Reviewed-by: Rob Pike <r@golang.org>
Change-Id: I70dfc2bad13c513c376c7c41058774b40af73dce
Reviewed-on: https://go-review.googlesource.com/9775
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Solaris, like Windows, NetBSD and OpenBSD, uses macros for stdin, stdout,
and stderr. Cgo can't access them without getters/setters written in
C. Because of this we disable affected tests like for the other platforms.
Updates #10715.
Change-Id: I3d33a5554b5ba209273dbdff992925a38a281b42
Reviewed-on: https://go-review.googlesource.com/8264
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This reverts commit c26fc88d56.
This broke pprof. See the comments at 9491.
Change-Id: Ic99ce026e86040c050a9bf0ea3024a1a42274ad1
Reviewed-on: https://go-review.googlesource.com/9565
Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Package time already has enough inherently flaky tests covering its
behavior. No need for more of them.
Fixes#10632.
Change-Id: I1229e9fcc2e28ba2c9b0b79f73638e35dbbe8bbf
Reviewed-on: https://go-review.googlesource.com/9517
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The heap statistics were only written if asked for a profile with debug > 0,
but that also prints a stack trace for each profile line, which is comparatively
much noisier. The statistics are short enough and separate enough
(they only appear at the end) and useful enough that we can print them
always.
This means that people using -test.memprofile in tests will get a memory
profile with statistics included now. Pprof won't care, but if people care to
look, the numbers will be there.
This avoids the need for hacks like using -memprofilerate=1 to find
the number of allocations.
Change-Id: I10a4f593403d0315aad11b37c6e554b734caa73f
Reviewed-on: https://go-review.googlesource.com/9491
Reviewed-by: David Chase <drchase@google.com>
github.com/kr/goven says it's deprecated and anyway
it would be preferable to point users to a standard Go tool.
Change-Id: Iac4a0d13233604a36538748d498f5770b2afce19
Reviewed-on: https://go-review.googlesource.com/8969
Reviewed-by: Minux Ma <minux@golang.org>
This avoids a race condition with go1.go wanting to examine files in
the current directory with filepath.Walk(".", walkFn).
Fixes#10497.
Change-Id: I2159f40a08d1a768195dbb7ea3c27e38cf9740bb
Reviewed-on: https://go-review.googlesource.com/9110
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The tests in doc/progs appear to have been originally written
for use with the old test driver. At some later point,
they acquired their own test driver.
Both ran tests in serial.
This CL rewrites the current test driver in Go,
runs tests concurrently, and cleans up
historical artifacts from the old drivers.
The primary motivation is to speed up all.bash.
On my laptop, using tip, this CL reduces doc/progs test
wall time from 26s to 7s. The savings will remain
even when the compiler gets faster. Using Go 1.4,
this CL reduces test wall time from 15s to 4s.
Change-Id: Iae945a8490222beee76e8a2118a0d7956092f543
Reviewed-on: https://go-review.googlesource.com/8410
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
to map element keys
Composite literals containing element values that are themselves composite
literals may leave away the element's literal types if they are identical
to the enclosing composite literal's element type.
(http://golang.org/ref/spec#Composite_literals)
When we made this change, we forgot to apply the analogous rule to map
literal keys. This change generalizes that rule. Added more examples,
including one showing the recursive application of the elision rules.
This is a fully backward-compatible language change. It was discussed
some time back.
Fixes#8589.
To be submitted once all compilers accept the extension.
Change-Id: I4d45b64b5970f0d5501572945d5a097e64a9458b
Reviewed-on: https://go-review.googlesource.com/2591
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
While we're here, also fix two HTML issues.
Fixes#9235.
Change-Id: I6e2f50931c0f387881271484a726ac2308518cf4
Reviewed-on: https://go-review.googlesource.com/7602
Reviewed-by: Rob Pike <r@golang.org>
When printing the type of the function there was no newline printed in
case of unexpected type.
Change-Id: I5946413f0864f712a1b955f488b436793018e0e0
Reviewed-on: https://go-review.googlesource.com/7480
Reviewed-by: Minux Ma <minux@golang.org>
- Fixed term in preceding section: submitted -> merged.
- Clear transitions between web sites.
- Clarify "types" of G Accounts.
- Less verbose "Configure Git" instructions. [l10n]
- Google uses the term "sign in".
- Mention .gitcookie file created.
Update "Register with Gerrit".
- Link directly to gerrit /login/ .
HTML
- Removed non-ascii "hidden characters".
- Encoded some & and >.
Change-Id: I0d99102def6b32e09b8e42fa40e20227ad5e7568
Reviewed-on: https://go-review.googlesource.com/5892
Reviewed-by: Andrew Gerrand <adg@golang.org>
- added a new field ast.EmptyStmt.Implicit to indicate explicit
or implicit semicolon
- fix ast.EmptyStmt.End() accordingly
- adjusted parser and added test case
Fixes#9979.
Change-Id: I72b0983b3a0cabea085598e1bf6c8df629776b57
Reviewed-on: https://go-review.googlesource.com/5720
Reviewed-by: Russ Cox <rsc@golang.org>
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
The proposed text in the last CL had a comma that was missing from the submitted spec.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/150720043
This CL adjusts code referring to src/pkg to refer to src.
Immediately after submitting this CL, I will submit
a change doing 'hg mv src/pkg/* src'.
That change will be too large to review with Rietveld
but will contain only the 'hg mv'.
This CL will break the build.
The followup 'hg mv' will fix it.
For more about the move, see golang.org/s/go14nopkg.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/134570043
Preparation for fixing issue 5769 (method selectors
do not auto-dereference): The actual fix may require
some cleanups in all these sections, and syntactically,
method expressions and method values are selector
expressions. Moving them next to each other so that
it's easy to see the actual changes (next CL).
No content changes besides the section moves.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/132300043
The file is used by assembly code to define symbols like NOSPLIT.
Having it hidden inside the cmd directory makes it hard to access
outside the standard repository.
Solution: As with a couple of other files used by cgo, copy the
file into the pkg directory and add a -I argument to the assembler
to access it. Thus one can write just
#include "textflag.h"
in .s files.
The names in runtime are not updated because in the boot sequence the
file has not been copied yet when runtime is built. All other .s files
in the repository are updated.
Changes to doc/asm.html, src/cmd/dist/build.c, and src/cmd/go/build.go
are hand-made. The rest are just the renaming done by a global
substitution. (Yay sam).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/128050043
You talked me into it. This and other links should be updated
once the new import paths for the subrepos are established.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/124260043
Add a clause to the doc comment for the package and a
paragraph in the compatibility document explaining the
situation.
LGTM=bradfitz, adg, rsc
R=golang-codereviews, adg, bradfitz, minux, rsc
CC=golang-codereviews
https://golang.org/cl/129820043
Technically a language change, this cleanup is a completely
backward compatible change that brings the boolean results
of comma-ok expressions in line with the boolean results of
comparisons: they are now all untyped booleans.
The implementation effort should be minimal (less than a
handfull lines of code, depending how well factored the
implementation of comma-ok expressions is).
Fixes#8189.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/112320045
golang.org now serves HTTPS with a valid cert, so it's reasonable
that users should click through to the HTTPS versions of *.golang.org
and other known sites.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/112650043
I've found this very useful for generating
good test case lists for -short mode for
the disassemblers.
Fixes#7959.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/98150043
This is a fully backward-compatible language change.
There are not a lot of cases in the std library, but
there are some. Arguably this makes the syntax a bit
more regular - any trailing index variable that is _
can be left away, and there's some analogy to type
switches where the temporary can be left away.
Implementation-wise the change should be trivial as
it can be done completely syntactically. For instance,
the respective change in go/parser is a dozen lines
(see https://golang.org/cl/112970044 ).
Fixes#6102.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/104680043
The runtime has historically held two dedicated values g (current goroutine)
and m (current thread) in 'extern register' slots (TLS on x86, real registers
backed by TLS on ARM).
This CL removes the extern register m; code now uses g->m.
On ARM, this frees up the register that formerly held m (R9).
This is important for NaCl, because NaCl ARM code cannot use R9 at all.
The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected:
BenchmarkBinaryTree17 5491374955 5471024381 -0.37%
BenchmarkFannkuch11 4357101311 4275174828 -1.88%
BenchmarkGobDecode 11029957 11364184 +3.03%
BenchmarkGobEncode 6852205 6784822 -0.98%
BenchmarkGzip 650795967 650152275 -0.10%
BenchmarkGunzip 140962363 141041670 +0.06%
BenchmarkHTTPClientServer 71581 73081 +2.10%
BenchmarkJSONEncode 31928079 31913356 -0.05%
BenchmarkJSONDecode 117470065 113689916 -3.22%
BenchmarkMandelbrot200 6008923 5998712 -0.17%
BenchmarkGoParse 6310917 6327487 +0.26%
BenchmarkRegexpMatchMedium_1K 114568 114763 +0.17%
BenchmarkRegexpMatchHard_1K 168977 169244 +0.16%
BenchmarkRevcomp 935294971 914060918 -2.27%
BenchmarkTemplate 145917123 148186096 +1.55%
Minux previous reported larger variations, but these were caused by
run-to-run noise, not repeatable slowdowns.
Actual code changes by Minux.
I only did the docs and the benchmarking.
LGTM=dvyukov, iant, minux
R=minux, josharian, iant, dave, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/109050043
This CL removes the special syntax for method receivers and
makes it just like other parameters. Instead, the crucial
receiver-specific rules (exactly one receiver, receiver type
must be of the form T or *T) are specified verbally instead
of syntactically.
This is a fully backward-compatible (and minor) syntax
relaxation. As a result, the following syntactic restrictions
(which are completely irrelevant) and which were only in place
for receivers are removed:
a) receiver types cannot be parenthesized
b) receiver parameter lists cannot have a trailing comma
The result of this CL is a simplication of the spec and the
implementation, with no impact on existing (or future) code.
Noteworthy:
- gc already permits a trailing comma at the end of a receiver
declaration:
func (recv T,) m() {}
This is technically a bug with the current spec; this CL will
legalize this notation.
- gccgo produces a misleading error when a trailing comma is used:
error: method has multiple receivers
(even though there's only one receiver)
- Compilers and type-checkers won't need to report errors anymore
if receiver types are parenthesized.
Fixes#4496.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/101500044
This is a clone of 101370043, which I accidentally applied to the
release branch first.
No big deal, it needed to be applied there anyway.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/108090043
The current wording is reversed in 2 places.
Not sure how it got 4 LGTMs (mine was there as well).
Update #6242.
LGTM=dan.kortschak, r, rsc
R=golang-codereviews, 0xjnml, dan.kortschak, r, rsc
CC=golang-codereviews
https://golang.org/cl/101980047
For incomplete struct S, C.T and C.struct_S were interchangeable in Go 1.2
and earlier, because all incomplete types were interchangeable
(even C.struct_S1 and C.struct_S2).
CL 76450043, which fixed issue 7409, made different incomplete types
different from Go's point of view, so that they were no longer completely
interchangeable.
However, imprecision about C.T and C.struct_S - really the same
underlying C type - is the one behavior enabled by the bug that
is most likely to be depended on by existing cgo code.
Explicitly allow it, to keep that code working.
Fixes#7786.
LGTM=iant, r
R=golang-codereviews, iant, r
CC=golang-codereviews
https://golang.org/cl/98580046
Also made it extra clear for goto statements (even though label scopes
are already limited to the function defining a label).
Fixes#8040.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/99550043
The spec was unclear about whether blank methods should be
permitted in interface types. gccgo permits at most one, gc
crashes if there are more than one, go/types permits at most
one.
Discussion:
Since method sets of non-interface types never contain methods
with blank names (blank methods are never declared), it is impossible
to satisfy an interface with a blank method.
It is possible to declare variables of assignable interface types
(but not necessarily identical types) containing blank methods, and
assign those variables to each other, but the values of those
variables can only be nil.
There appear to be two "reasonable" alternatives:
1) Permit at most one blank method (since method names must be unique),
and consider it part of the interface. This is what appears to happen
now, with corner-case bugs. Such interfaces can never be implemented.
2) Permit arbitrary many blank methods but ignore them. This appears
to be closer to the handling of blank identifiers in declarations.
However, an interface type literal is not a declaration (it's a type
literal). Also, for struct types, blank identifiers are not ignored;
so the analogy with declarations is flawed.
Both these alternatives don't seem to add any benefit and are likely
(if only slightly) more complicated to explain and implement than
disallowing blank methods in interfaces altogether.
Fixes#6604.
LGTM=r, rsc, iant
R=r, rsc, ken, iant
CC=golang-codereviews
https://golang.org/cl/99410046
The key property here is what the bit pattern represents,
not what its type is. Storing 5 into a pointer is the problem.
Storing a uintptr that holds pointer bits back into a pointer
is not as much of a problem, and not what we are claiming
the runtime will detect.
Longer discussion at
https://groups.google.com/d/msg/golang-nuts/dIGISmr9hw0/0jO4ce85Eh0J
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/98370045
