Added a paragraph and examples explaining when an implementation
may use fused floating-point operations (such as FMA) and how to
prevent operation fusion.
For #17895.
Change-Id: I64c9559fc1097e597525caca420cfa7032d67014
Reviewed-on: https://go-review.googlesource.com/40391
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The section on map literals mentions constant map keys but doesn't say
what happens for equal non-constant map keys - that is covered in the
section on evaluation order. Added respective link for clarity.
Fixes#19689.
Change-Id: If9a5368ba02e8250d4bb0a1d60d0de26a1f37bbb
Reviewed-on: https://go-review.googlesource.com/38598
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #17802
Change-Id: I65ea0f4cde973604c04051e7eb25d12e4facecd3
Reviewed-on: https://go-review.googlesource.com/36626
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
POSIX Shell only supports = to compare variables inside '[' tests. But
this is Bash, where == is an alias for =. In practice they're the same,
but the current form is inconsisnent and breaks POSIX for no good
reason.
Change-Id: I38fa7a5a90658dc51acc2acd143049e510424ed8
Reviewed-on: https://go-review.googlesource.com/38031
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The (original) section on "Operators and Delimiters" introduced
superfluous terminology ("delimiter", "special token") which
didn't matter and was used inconsistently.
Removed any mention of "delimiter" or "special token" and now
simply group the special character tokens into "operators"
(clearly defined via links), and "punctuation" (everything else).
Fixes#19450.
Change-Id: Ife31b24b95167ace096f93ed180b7eae41c66808
Reviewed-on: https://go-review.googlesource.com/38073
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Fixes#19223.
Change-Id: I4cc8e81559a1313e1477ee36902e1b653155a888
Reviewed-on: https://go-review.googlesource.com/37374
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This change removes the punitive language and anonymous reporting mechanism
from the Code of Conduct document. Read on for the rationale.
More than a year has passed since the Go Code of Conduct was introduced.
In that time, there have been a small number (<30) of reports to the Working Group.
Some reports we handled well, with positive outcomes for all involved.
A few reports we handled badly, resulting in hurt feelings and a bad
experience for all involved.
On reflection, the reports that had positive outcomes were ones where the
Working Group took the role of advisor/facilitator, listening to complaints and
providing suggestions and advice to the parties involved.
The reports that had negative outcomes were ones where the subject of the
report felt threatened by the Working Group and Code of Conduct.
After some discussion among the Working Group, we saw that we are most
effective as facilitators, rather than disciplinarians. The various Go spaces
already have moderators; this change to the CoC acknowledges their authority
and places the group in a purely advisory role. If an incident is
reported to the group we may provide information to or make a
suggestion the moderators, but the Working Group need not (and should not) have
any authority to take disciplinary action.
In short, we want it to be clear that the Working Group are here to help
resolve conflict, period.
The second change made here is the removal of the anonymous reporting mechanism.
To date, the quality of anonymous reports has been low, and with no way to
reach out to the reporter for more information there is often very little we
can do in response. Removing this one-way reporting mechanism strengthens the
message that the Working Group are here to facilitate a constructive dialogue.
Change-Id: Iee52aff5446accd0dae0c937bb3aa89709ad5fb4
Reviewed-on: https://go-review.googlesource.com/37014
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
CL (change list) pops out of nowhere and confuses the
reader. Use "change" instead to be consistent with the
rest of the document.
Fixes#18989.
Change-Id: I525a63a195dc6bb992c8ad0f10c2f2e1b2b952df
Reviewed-on: https://go-review.googlesource.com/36564
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
To avoid confusion caused by the term "named type" (which now just
means a type with a name, but formerly meant a type declared with
a non-alias type declaration), a type declaration now comes in two
forms: alias declarations and type definitions. Both declare a type
name, but type definitions also define new types.
Replace the use of "named type" with "defined type" elsewhere in
the spec.
For #18130.
Change-Id: I49f5ddacefce90354eb65ee5fbf10ba737221995
Reviewed-on: https://go-review.googlesource.com/36213
Reviewed-by: Rob Pike <r@golang.org>
Dave and Jason have moved on to other things.
Change-Id: I702d11bedfab1f47a33679a48c2309f49021229e
Reviewed-on: https://go-review.googlesource.com/36450
Reviewed-by: Dave Cheney <dave@cheney.net>
For #18130.
f8b4123613 [dev.typealias] spec: use term 'embedded field' rather than 'anonymous field'
9ecc3ee252 [dev.typealias] cmd/compile: avoid false positive cycles from type aliases
49b7af8a30 [dev.typealias] reflect: add test for type aliases
9bbb07ddec [dev.typealias] cmd/compile, reflect: fix struct field names for embedded byte, rune
43c7094386 [dev.typealias] reflect: fix StructOf use of StructField to match StructField docs
9657e0b077 [dev.typealias] cmd/doc: update for type alias
de2e5459ae [dev.typealias] cmd/compile: declare methods after resolving receiver type
9259f3073a [dev.typealias] test: match gccgo error messages on alias2.go
5d92916770 [dev.typealias] cmd/compile: change Func.Shortname to *Sym
a7c884efc1 [dev.typealias] go/internal/gccgoimporter: support for type aliases
5802cfd900 [dev.typealias] cmd/compile: export/import test cases for type aliases
d7cabd40dd [dev.typealias] go/types: clarified doc string
cc2dcce3d7 [dev.typealias] cmd/compile: a few better comments related to alias types
5c160b28ba [dev.typealias] cmd/compile: improved error message for cyles involving type aliases
b2386dffa1 [dev.typealias] cmd/compile: type-check type alias declarations
ac8421f9a5 [dev.typealias] cmd/compile: various minor cleanups
f011e0c6c3 [dev.typealias] cmd/compile, go/types, go/importer: various alias related fixes
49de5f0351 [dev.typealias] cmd/compile, go/importer: define export format and implement importing of type aliases
5ceec42dc0 [dev.typealias] go/types: export TypeName.IsAlias so clients can use it
aa1f0681bc [dev.typealias] go/types: improved Object printing
c80748e389 [dev.typealias] go/types: remove some more vestiges of prior alias implementation
80d8b69e95 [dev.typealias] go/types: implement type aliases
a917097b5e [dev.typealias] go/build: add go1.9 build tag
3e11940437 [dev.typealias] cmd/compile: recognize type aliases but complain for now (not yet supported)
e0a05c274a [dev.typealias] cmd/gofmt: added test cases for alias type declarations
2e5116bd99 [dev.typealias] go/ast, go/parser, go/printer, go/types: initial type alias support
Change-Id: Ia65f2e011fd7195f18e1dce67d4d49b80a261203
First steps towards defining type aliases in the spec.
This is a nomenclature clarification, not a language change.
The spec used all three terms 'embedded type', 'anonymous field',
and 'embedded field'. Users where using the terms inconsistently.
The notion of an 'anonymous' field was always misleading since they
always had a de-facto name. With type aliases that name becomes even
more important because we may have different names for the same type.
Use the term 'embedded field' consistently and remove competing
terminology.
For #18130.
Change-Id: I2083bbc85788cab0b2e2cb1ff58b2f979491f001
Reviewed-on: https://go-review.googlesource.com/35108
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Update docs on correspondence between Go releases and GCC releases.
Update C type that corresponds to Go type `int`.
Drop out of date comments about Ubuntu and RTEMS.
Change-Id: Ic1b5ce9f242789af23ec3b7e7a64c9d257d6913e
Reviewed-on: https://go-review.googlesource.com/35631
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
You have to actually run make.bash (or make.bat).
Update #18771.
Change-Id: Ie6672a4e4abde0150c1ae57cabb1222de2c78716
Reviewed-on: https://go-review.googlesource.com/35632
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: Iac713ae1f322f893c92b3fc47fe9b5719052f9eb
Reviewed-on: https://go-review.googlesource.com/35240
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Symonds <dsymonds@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Also fix a couple of other errors.
Fixes#6877
Change-Id: I94c81c5847cc7b0adab19418e71687bc2ee7fe94
Reviewed-on: https://go-review.googlesource.com/34960
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We are seeing a bad stack map in #18190. In a copystack, it is
mistaking a slot for a pointer.
Presumably this is caused either by our fledgling dynlink support on
darwin, or a consequence of having two copies of the runtime in the
process. But I have been unable to work out which in the 1.8 window,
so pushing darwin support to 1.9 or later.
Change-Id: I7fa4d2dede75033d9a428f24c1837a4613bd2639
Reviewed-on: https://go-review.googlesource.com/34391
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Made many minor changes so that the document is consistent with itself.
Some more noticeable changes:
* CL/34141: Revert "testing: add T.Context method"
* CL/33630: net/http: document restrictions on ETag as expected by ServeContent
Change-Id: I39ae5e55c56e374895c115e6852998c940beae35
Reviewed-on: https://go-review.googlesource.com/34243
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There is nothing notable to mention as far as users are concerned.
Fixes#17929 (another bug tracks the remaining TODO item)
Change-Id: Id39f787581ed9d2ecd493126bb7ca27836816d4b
Reviewed-on: https://go-review.googlesource.com/34145
Reviewed-by: Michael Matloob <matloob@golang.org>
This rolls back https://golang.org/cl/27117 partly, softening it so it
only retries POST/PUT/DELETE etc requests where there's no Body (nil
or NoBody). This is a little useless, since most idempotent requests
have a body (except maybe DELETE), but it's late in the Go 1.8 release
cycle and I want to do the proper fix.
The proper fix will look like what we did for http2 and only retrying
the request if Request.GetBody is defined, and then creating a new request
for the next attempt. See https://golang.org/cl/33971 for the http2 fix.
Updates #15723Fixes#18239
Updates #18241
Change-Id: I6ebaa1fd9b19b5ccb23c8d9e7b3b236e71cf57f3
Reviewed-on: https://go-review.googlesource.com/34134
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Mention that the best-effort race detector on maps
was upgraded to detect write/iterate races.
Fixes#18137
Change-Id: Ib6e0adde47e965126771ea712386031a2a55eba3
Reviewed-on: https://go-review.googlesource.com/33768
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
And link it.
Change-Id: Ic0105468435299fb1638f86522f4f3ce417ec1c2
Reviewed-on: https://go-review.googlesource.com/33871
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reversion CL was 33770.
Change-Id: I119f26796bb2b66d302e132dd118847ac3bd6633
Reviewed-on: https://go-review.googlesource.com/33807
Reviewed-by: Ian Lance Taylor <iant@golang.org>
And reflow paragraph while I'm at it.
Change-Id: Ia13bb364783790fbd9f8b69ef268f8a4b71679cb
Reviewed-on: https://go-review.googlesource.com/33767
Reviewed-by: Chris Broadfoot <cbro@golang.org>
None of them need to be called out in the release notes.
Change-Id: I143a1879b25063574e4107c1e89264434d45d1d5
Reviewed-on: https://go-review.googlesource.com/33676
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 32796 changes the SIGPIPE behaviour for c-archive and c-shared
programs. Add it to go1.8.txt.
Change-Id: I31200187033349c642965a4bb077bcc77d5329a3
Reviewed-on: https://go-review.googlesource.com/33397
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This matches what we already do for switch statements and makes
this large section more visibly organized. No other changes besides
introducing the titles.
Fixes#4486.
Change-Id: I73f274e4fdd27c6cfeaed79090b4553e57a9c479
Reviewed-on: https://go-review.googlesource.com/33410
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
- organize examples better
- add an example illustrating behavior if element type is a named pointer type
- both compilers and go/types (per https://go-review.googlesource.com/33358)
follow this now
See the issue for detailed discussion.
Fixes#17954.
Change-Id: I8d90507ff2347d9493813f75b73233819880d2b4
Reviewed-on: https://go-review.googlesource.com/33361
Reviewed-by: Rob Pike <r@golang.org>
Both automated updates with a few tweaks.
Change-Id: I24579a8dcc32a84a4fff5c2212681ef30dda61d1
Reviewed-on: https://go-review.googlesource.com/33297
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The tree is inconsistent about single l vs double l in those
words in documentation, test messages, and one error value text.
$ git grep -E '[Mm]arshall(|s|er|ers|ed|ing)' | wc -l
42
$ git grep -E '[Mm]arshal(|s|er|ers|ed|ing)' | wc -l
1694
Make it consistently a single l, per earlier decisions. This means
contributors won't be confused by misleading precedence, and it helps
consistency.
Change the spelling in one error value text in newRawAttributes of
crypto/x509 package to be consistent.
This change was generated with:
perl -i -npe 's,([Mm]arshal)l(|s|er|ers|ed|ing),$1$2,' $(git grep -l -E '[Mm]arshall' | grep -v AUTHORS | grep -v CONTRIBUTORS)
Updates #12431.
Follows https://golang.org/cl/14150.
Change-Id: I85d28a2d7692862ccb02d6a09f5d18538b6049a2
Reviewed-on: https://go-review.googlesource.com/33017
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We thought it would at the time, but then Beta 4 changed the ABI
again, so it wasn't true in practice.
Fixes#17643
Change-Id: I36b747bd69a56adc7291fa30d6bffdf67ab8741b
Reviewed-on: https://go-review.googlesource.com/32238
Reviewed-by: Russ Cox <rsc@golang.org>
As agreed upon by the Code of Conduct working group, "race" may refer to
an attempt to classify people based on "defining characteristics",
regardless of how this people view themselves, while "ethnicity" refers
to how people identify themselves.
The Code of Conduct working group believes that the term "ethnicity"
will be more comprehensive and inclusive, and will better serve the Go
community.
Change-Id: I724b72cadb8cf29b4bac8f83017b0303feae3c94
Reviewed-on: https://go-review.googlesource.com/32133
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
For some reason git won't let me write
doc/effective_go.html: reword confusing sentence
or even
doc/effective_go: reword confusing sentence
as the subject line for this CL, but that's not important. The
actual CL just rewrites one sentence and adds an option to grep in
the associated example.
Fixes#15875
Change-Id: Iee159ea751caf4b73eacf3dfc86e29032646373f
Reviewed-on: https://go-review.googlesource.com/32110
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A 16bit binary exponent permits a constant range covering roughly the range
from 7e-9865 to 7e9863 which is more than enough for any practical and
hypothetical constant arithmetic.
Furthermore, until recently cmd/compile could not handle very large exponents
correctly anyway; i.e., the chance that any real programs (but for tests that
explore corner cases) are affected are close to zero.
Finally, restricting the minimum supported range significantly reduces the
implementation complexity in an area that hardly matters in reality for new
or alternative spec-compliant implementations that don't or cannot rely on
pre-existing arbitratry precision arithmetic packages that support a 32bit
exponent range.
This is technically a language change but for the reasons mentioned above
this is unlikely to affect any real programs, and certainly not programs
compiled with the gc or gccgo compilers as they currently support up to
32bit exponents.
Fixes#13572.
Change-Id: I970f919c57fc82c0175844364cf48ea335f17d39
Reviewed-on: https://go-review.googlesource.com/17711
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This clarifies some of the titles so they're more "news" friendly and
less implementation-oriented.
Change-Id: Ied02aa1e6824b04db5d32ecdd58e972515b1f588
Reviewed-on: https://go-review.googlesource.com/29830
Reviewed-by: Rick Hudson <rlh@golang.org>
With help of a new interactive commit classifier tool (tool location
TBD, likely x/build/cmd/writenotes), classify all commits from go1.7
up to 56d35d4.
We can selectively cull this list later. When in doubt, I erred on the
side of inclusion for now.
Change-Id: I458945004e1b1a148fb2f294b454a390ef4f92c2
Reviewed-on: https://go-review.googlesource.com/30696
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This simply documents the status quo accepted by cmd/compile, gccgo,
and go/types. The new language matches the language used for indices
of index expressions for arrays and slices.
Fixes#16679.
Change-Id: I65447889fbda9d222f2a9e6c10334d1b38c555f0
Reviewed-on: https://go-review.googlesource.com/30474
Reviewed-by: Rob Pike <r@golang.org>
This is a backwards-compatible language change.
Per the proposal (#16085), the rules for conversions are relaxed
such that struct tags in any of the structs involved in the conversion
are ignored (recursively).
Because this is loosening the existing rules, code that compiled so
far will continue to compile.
For #16085.
Fixes#6858.
Change-Id: I0feef651582db5f23046a2331fc3f179ae577c45
Reviewed-on: https://go-review.googlesource.com/24190
Reviewed-by: Russ Cox <rsc@golang.org>
Effective Go has references to a function call f(c, req) made by ServeHTTP mixed with f(w,
req). c is dropped in favor of w to maintain consistency
Fixes#17128
Change-Id: I6746fd115ed5a58971fd24e54024d29d18ead1fa
Reviewed-on: https://go-review.googlesource.com/29311
Reviewed-by: Rob Pike <r@golang.org>
The download page says "OS X 10.8 or later", but other pages said 10.7.
Say 10.8 everywhere.
Turns out Go doesn't even compile on OS X 10.7 (details in bug) and we
only run builders for OS X 10.8+, which is likely why 10.7
regressed. Until recently we only had OS X 10.10 builders, even.
We could run 10.7 builders, but there's basically no reason to do so,
especially with 10.12 coming out imminently.
Fixes#16625
Change-Id: Ida6e20fb6c54aea0a3757235b708ac1c053b8c04
Reviewed-on: https://go-review.googlesource.com/28870
Reviewed-by: Chris Broadfoot <cbro@golang.org>
We relay this info in a few places, in a few different ways, but not
consistently everywhere. This led one of our users to start googling
and not find https://golang.org/doc/code.html#Workspaces, of which `go
help gopath` is the most equivalent.
Change-Id: I28a94375739f3aa4f200e145293ca2a5f65101e1
Reviewed-on: https://go-review.googlesource.com/28690
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Currently the footnote says "gcc is required only if you plan to use cgo",
but the footnote was referenced from the text:
"use the clang or gcc† that comes with Xcode‡ for cgo support"
That seems to imply that clang doesn't get you cgo support on OS X,
which isn't true. The update text matches what the install-source.html
page says.
Change-Id: Ib88464a0d138227d357033123f6675a77d5d777f
Reviewed-on: https://go-review.googlesource.com/28786
Reviewed-by: Minux Ma <minux@golang.org>
See the issue below for details.
Fixes#16794.
Change-Id: I7e338089fd80ddcb634fa80bfc658dee2772361c
Reviewed-on: https://go-review.googlesource.com/27356
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This truly is a common point of confusion that deserves
explanation in the FAQ.
Change-Id: Ie624e31a2042ca99626fe7570d9c8c075aae6a84
Reviewed-on: https://go-review.googlesource.com/28275
Reviewed-by: Ian Lance Taylor <iant@golang.org>
