Previously we allowed drivers to modify the row buffer used to scan
values when closing Rows. This is no longer acceptable and can lead
to data races.
Fixes#23519
Change-Id: I91820a6266ffe52f95f40bb47307d375727715af
Reviewed-on: https://go-review.googlesource.com/89936
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
When we introduced the notion of alias type declarations, we renamed
"named type" to "defined type" to avoid confusion with types denoted
by aliases and thus are also types with names, or "named types".
Some of the old uses of "named types" remained; this change removes
them.
Now the spec consistently uses the terms:
- "defined type" for a type declared via a type definition
- "type name" for any name denoting an (alias or defined) type
- "alias" for a type name declared in an alias declaration
New prose is encouraged to avoid the term "named type" to counter-
act further confusion.
Fixes#23474.
Change-Id: I5fb59f1208baf958da79cf51ed3eb1411cd18e03
Reviewed-on: https://go-review.googlesource.com/89115
Reviewed-by: Rob Pike <r@golang.org>
Except for removing the DRAFT marker, I think these are now ready to go.
Change-Id: I20604f5b135616189a24990db463c7bb5e7d48f1
Reviewed-on: https://go-review.googlesource.com/88975
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#23443.
Change-Id: If60c39b582ee5308e9fa902f93c1b6ae7890346c
Reviewed-on: https://go-review.googlesource.com/87975
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Every few months we get a new error report claiming that there
is a typo in the spec related to this specific example. Clearly,
the fact that two types with the same identifier are identical
seems exceedingly obvious to readers; thus the example seems not
worth the trouble. Removing it.
For #9226.
For #22202.
For #22495.
For #23096.
For #23409.
There may be more.
Change-Id: I003ba79dc460ffb028a4ecb5f29efd60f2551912
Reviewed-on: https://go-review.googlesource.com/87417
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Type values being comparable implies that Type is a valid map key type.
As previously written, they sound unrelated.
Change-Id: I8e2235275d62898bfb47de850e8257b51ab5cbd6
Reviewed-on: https://go-review.googlesource.com/87021
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Don't suggest that it's always necessary to disable optimizations.
(The text can be misread that way, even if it's not what was meant.)
Change-Id: I9a2dff6a75ce4a3f9210cdf4f5bad6aaaeae9b29
Reviewed-on: https://go-review.googlesource.com/87018
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We were not being consistent.
Standardize on toolchain.
Change-Id: Id0e756b5214ce4a1341f733634ed95263f03a61c
Reviewed-on: https://go-review.googlesource.com/87017
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
No longer needs to be done.
Updates #23009
Updates #21255
Change-Id: I78e9e29a923dc03dea89ff3a5bf60f2e0bd0c0aa
Reviewed-on: https://go-review.googlesource.com/86476
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The spec refers to a map's key and element types; thus the respective
values are "keys" and "elements". Also, a map value is the value of
the entire map.
Similar fix for channels, where appropriate.
Fixes#23254.
Change-Id: I6f03ea6d86586c7b0b3e84f0c2e9446b8109fa53
Reviewed-on: https://go-review.googlesource.com/85999
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
After 1.10, gcflags apply to only the immediate target.
Change-Id: I3bf331c76041e7b533076cb2f3274e44aafff58a
Reviewed-on: https://go-review.googlesource.com/84775
Reviewed-by: Heschi Kreinick <heschi@google.com>
After go1.10, compiler/linker option flags apply only to the packages
listed directly on the command line unless the matching pattern is
specified. For debugging, we want to apply the flags to all packages.
Change-Id: Ic69eee1491b1080fc140592f200c59a6e03d87ac
Reviewed-on: https://go-review.googlesource.com/84135
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use Brendan Gregg's FlameGraphs page link.
Mention the flame graph is available from the upstream pprof.
Change-Id: Ife1d5a5f4f93f20cd5952a09083f798b77d25a60
Reviewed-on: https://go-review.googlesource.com/83798
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
By the time Go 1.11 is released, OS X 10.9 Mavericks will have gone
two years with no security updates.
For #23011.
Change-Id: I6482852a14477985769b72c45c92416aae8be100
Reviewed-on: https://go-review.googlesource.com/83795
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Use “substantial”, which is believed to be the correct word.
Additionally, this change strips trailing whitespace from the file.
Change-Id: I5b6b718fc09e4b8b911b95e8be0733abd58e165d
Reviewed-on: https://go-review.googlesource.com/83356
Reviewed-by: Andrew Gerrand <adg@golang.org>
It's 32-bit binaries that fail for reasons unknown on 64-bit kernels.
Change-Id: Ib410af0491160e3ed8d32118966142516123db2c
Reviewed-on: https://go-review.googlesource.com/82655
Reviewed-by: Andrew Bonventre <andybons@golang.org>
GOMIPS is a GOARCH=mips{,le} specific option, for a choice between
hard-float and soft-float. Valid values are 'hardfloat' (default) and
'softfloat'. It is passed to the assembler as
'GOMIPS_{hardfloat,softfloat}'.
Note: GOMIPS will later also be used for a choice of MIPS instruction
set (mips32/mips32r2).
Updates #18162
Change-Id: I35417db8625695f09d6ccc3042431dd2eaa756a6
Reviewed-on: https://go-review.googlesource.com/37954
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The note about the single change workflow is included in the
git-codereview installation instructions, but it has nothing to do with
installing git-codereview. This note is more relevant for when a change
is actually being made.
Change-Id: Iccb90f3b7da87fab863fa4808438cd69a21a2fce
Reviewed-on: https://go-review.googlesource.com/76317
Reviewed-by: Steve Francia <spf@golang.org>
There were too many changes of direction. Tidy up the intro a little
for better flow, and delete some unnecessary comments.
Change-Id: Ib5d85c0992626bd3152f86a51585884d3e0cab72
Reviewed-on: https://go-review.googlesource.com/80495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change drops the support for FreeBSD 9 or below and simplifies
platform-dependent code for the sake of maintenance.
Updates #7187.
Fixes#11412.
Updates #16064.
Updates #18854.
Fixes#19072.
Change-Id: I9129130aafbfc7d0d7e9b674b6fc6cb31b7381be
Reviewed-on: https://go-review.googlesource.com/64910
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Only a last sentence of A Tour of Go is shifting to the left.
I fixed a HTML tag order according to other sentences it.
Change-Id: I6a301178d15db893f596b8da80a4d98721160386
Reviewed-on: https://go-review.googlesource.com/79856
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This updates the name of the IDE and the capability it has.
Fixes#22784
Change-Id: Ief261324c86bc77a03071629f496f4d4d9df1b44
Reviewed-on: https://go-review.googlesource.com/79255
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The section about custom pprof paths referenced the wrong path.
This also fixes a couple minor grammatical issues elsewhere in the doc.
Fixes#22832
Change-Id: I890cceb53a13c1958d9cf958c658ccfcbb6863d5
Reviewed-on: https://go-review.googlesource.com/79035
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Apparently we maintain this list by hand (for example, CL 52351).
Change-Id: I0a0b346cf2b7b547729cb1d0fa1642de447f7bba
Reviewed-on: https://go-review.googlesource.com/78117
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
GDB 7.5 recognizes DWARF4 by default.
GDB 7.5 release note does not explicitly mention DWARF4 support
but according to GCC 4.8 release note
https://gcc.gnu.org/gcc-4.8/changes.html
"DWARF4 is now the default when generating DWARF debug
information. ...
GDB 7.5, Valgrind 3.8.0 and elfutils 0.154 debug information
consumers support DWARF4 by default."
Change-Id: I56b011c7c38fbc103bbd366ceaea3b709c66ab7f
Reviewed-on: https://go-review.googlesource.com/77570
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
If people are interested in contributing to Go, but not sure what
change they'd like to make just yet, we can point them to the scratch
repo, so they can go through the process of submitting and merging
something now, and make more useful contributions later.
My evidence that sending people to the scratch repo would encourage
future contributions is that a number of people who went through the
workshop at Gophercon have continued to send CL's after submitting to
the scratch repo, even though I doubt they planned to before going
through the workshop.
Change-Id: Ieb48415773c0ee7dc400f8bf6f57f752eca8eeb5
Reviewed-on: https://go-review.googlesource.com/49970
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A method expression is of the form T.m where T is a type and m
is a method of that type. The spec restricted T essentially to
a type name. Both cmd/compile and go/types accepted any type
syntactically, and a method expression was really just a form
of a selector expression x.f where x denotes a type.
This CL removes the spec syntax restriction from MethodExpr
to match the actual implementation. It also moves MethodExpr
from Operand to PrimaryExpr, because that's what it is.
It still keeps the separate notion of MethodExpr even though
it looks just like a selector expresion, since a MethodExpr
must start with a type rather than a value, and the spec's
syntax expresses this bit of semantics via distinct productions
(e.g., conversions look like calls but also must start with
a type).
Fixes#9060.
Change-Id: Idd84655b5b4f85d7ee53ebf749f73f0414a05f4a
Reviewed-on: https://go-review.googlesource.com/73233
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
https://golang.org/cl/71750 specifies iota values as indices,
thus making them independent from nested constant declarations.
This CL removes some of the comments in the examples that were
still referring to the old notion of iotas being incremented
and reset.
As an aside, please note that the spec still permits the use
of iota in a nested function (like before). Specifically, the
following cases are permitted by the spec (as before):
1) const _ = len([iota]int{})
2) const _ = unsafe.Sizeof(func(){ _ = iota })
For #15550.
Change-Id: I9e5fec75daf7b628b1e08d970512397e9c348923
Reviewed-on: https://go-review.googlesource.com/71912
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Issue #15550 is clearly an esoteric case but the spec was silent
about it and we had diverging implementations. By making `iota`
and index that is relative to the respective constant declaration,
nested const declarations won't affect outer values of `iota`.
cmd/compile and go/types already follow this semantics.
Fixes#15550.
Change-Id: If138189e3ea4373f8ba50ac6fb1d219b481f8698
Reviewed-on: https://go-review.googlesource.com/71750
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#22258.
Change-Id: I43e68f1cf3163e1a041ebff2734ff2cb7943f695
Reviewed-on: https://go-review.googlesource.com/71431
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Nowhere in the spec did we mention the import path for package
unsafe. Now we do.
Fixes#22308.
Change-Id: Ifd42c873188e898c597cdee4284e7a9d234a9282
Reviewed-on: https://go-review.googlesource.com/71373
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Fixes#21054
Change-Id: I016486dc62c04a80727f8da7d1dcec52f2c7f344
Reviewed-on: https://go-review.googlesource.com/62291
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Update golang/go#22120
Change-Id: Ie7dbd0e7b01b116c960243a8cd3fa9fd121f317d
Reviewed-on: https://go-review.googlesource.com/68021
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Updated page to Page to match with the sample code
Fixes#21773
Change-Id: Ia884a22fd587860c7a6148103b2b474425e45284
Reviewed-on: https://go-review.googlesource.com/66790
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we introduced the distinction between "defined" and "alias" types
we retained the notion of a "named" type (any type with a name). The
predeclared types (which all have names) simply remained named types.
This CL clarifies the spec by stating excplicitly which predeclared
types are defined types (or at least "act" like defined types), and
which ones are alias types.
Fixes#21785.
Change-Id: Ia8ae133509eb5d738e6757b3442c9992355e3535
Reviewed-on: https://go-review.googlesource.com/64591
Reviewed-by: Russ Cox <rsc@golang.org>
Unify colons (outside of <strong></strong>) and add a missing space in
the list of groups of diagnostics solutions.
Change-Id: Icbcd94427d4905dd88c4ea82aaa5dbf064c00990
Reviewed-on: https://go-review.googlesource.com/63111
Reviewed-by: JBD <jbd@google.com>
Diagnostics guide lists various dimensions of
diagnostics tools and libraries available in Go.
As a follow-up, I will add an entry section where
we navigate user to the right tool depending on
the type of problem they are willing to improve
or understand better.
Change-Id: I4e94b4b834014f51c988103457da84200c7827d9
Reviewed-on: https://go-review.googlesource.com/61693
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The spec is not conclusive about whether a non-constant shift of
certain untyped constant left operands is valid when the shift
expression appears as an index in an index or slice expression,
or as a size in a `make` function call.
Despite identical spec rules in all these cases, cmd/compile accepts
make([]byte, 1.0 << s)
but pronounces an error for
a[1.0 << s]
(go/types accepts both).
This change clarifies the spec by explicitly stating that an
untyped constant left operand in a non-constant shift (1.0 in
the above examples) will be given type `int` in these contexts.
A separate issue #21693 addresses the cmd/compile bug.
Fixes#14844.
Change-Id: I4b52125e487a607fae377fcbed55463cdce9836c
Reviewed-on: https://go-review.googlesource.com/60230
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, cgo supports only macros which can be reduced to constants
or variables. The CL addresses remaining parts, macros which can be
represented as niladic functions.
The basic idea is simple:
1. make a thin wrapper function per macros.
2. replace macro expansions with function calls.
Fixes#10715Fixes#18720
Change-Id: I150b4fb48e9dc4cc34466ef6417c04ac93d4bc1a
Reviewed-on: https://go-review.googlesource.com/43970
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The last sentence in the section on slice expressions could be read
as if it might apply to strings. Changed the sentence a bit to
emphasize its applicability to slices only. See also the issue for
more background.
Fixes#19220.
Change-Id: I8551f34230e4ed93f951e7b871cc81f54a5874a9
Reviewed-on: https://go-review.googlesource.com/59890
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Throughout the spec we use the notion of a constant x being
representable by a value of type T. While intuitively clear,
at least for floating-point and complex constants types, the
concept was not well-defined. In the section on Conversions
there was an extra rule for floating-point types only and it
missed the case of floating-point values overflowing to an
infinity after rounding.
Since the concept is important to Go, and a compiler most
certainly will have a function to test "representability",
it seems warranted to define the term explicitly in the spec.
This change introduces a new entry "Representability" under
the section on "Properties of types and values", and defines
the term explicitly, together with examples.
The phrase used is "representable by" rather than "representable as"
because the former use is prevalent in the spec.
Additionally, it clarifies that a floating-point constant
that overflows to an infinity after rounding is never
representable by a value of a floating-point type, even though
infinities are valid values of IEEE floating point types.
This is required because there are not infinite value constants
in the language (like there is also no -0.0) and representability
also matters for constant conversions. This is not a language
change, and type-checkers have been following this rule before.
The change also introduces links throughout the spec to the new
section as appropriate and removes duplicate text and examples
elsewhere (Constants and Conversions sections), leading to
simplifications in the relevant paragraphs.
Fixes#15389.
Change-Id: I8be0e071552df0f18998ef4c5ef521f64ffe8c44
Reviewed-on: https://go-review.googlesource.com/57530
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
