| Age | Commit message (Collapse) | Author |
|---|
|
The old m[x] = 0, false syntax will be deleted
in a month or so, once people have had time to
change their code (there is a gofix in a separate CL).
R=ken2
CC=golang-dev
https://golang.org/cl/5265048
|
|
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5285042
|
|
The map implementation was using the C idiom of using
a pointer just past the end of its table as a limit pointer.
Unfortunately, the garbage collector sees that pointer as
pointing at the block adjacent to the map table, pinning
in memory a block that would otherwise be freed.
Fix by making limit pointer point at last valid entry, not
just past it.
Reviewed by Mike Burrows.
R=golang-dev, bradfitz, lvd, r
CC=golang-dev
https://golang.org/cl/5158045
|
|
The spec has defined nil maps this way for months.
I'm behind.
R=ken2
CC=golang-dev
https://golang.org/cl/4901052
|
|
When rnd is called with a second argument of 1, it simply
returns the first argument anyway.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4820045
|
|
* Reduces malloc counts during gob encoder/decoder test from 6/6 to 3/5.
The current reflect uses Set to mean two subtly different things.
(1) If you have a reflect.Value v, it might just represent
itself (as in v = reflect.NewValue(42)), in which case calling
v.Set only changed v, not any other data in the program.
(2) If you have a reflect Value v derived from a pointer
or a slice (as in x := []int{42}; v = reflect.NewValue(x).Index(0)),
v represents the value held there. Changing x[0] affects the
value returned by v.Int(), and calling v.Set affects x[0].
This was not really by design; it just happened that way.
The motivation for the new reflect implementation was
to remove mallocs. The use case (1) has an implicit malloc
inside it. If you can do:
v := reflect.NewValue(0)
v.Set(42)
i := v.Int() // i = 42
then that implies that v is referring to some underlying
chunk of memory in order to remember the 42; that is,
NewValue must have allocated some memory.
Almost all the time you are using reflect the goal is to
inspect or to change other data, not to manipulate data
stored solely inside a reflect.Value.
This CL removes use case (1), so that an assignable
reflect.Value must always refer to some other piece of data
in the program. Put another way, removing this case would
make
v := reflect.NewValue(0)
v.Set(42)
as illegal as
0 = 42.
It would also make this illegal:
x := 0
v := reflect.NewValue(x)
v.Set(42)
for the same reason. (Note that right now, v.Set(42) "succeeds"
but does not change the value of x.)
If you really wanted to make v refer to x, you'd start with &x
and dereference it:
x := 0
v := reflect.NewValue(&x).Elem() // v = *&x
v.Set(42)
It's pretty rare, except in tests, to want to use NewValue and then
call Set to change the Value itself instead of some other piece of
data in the program. I haven't seen it happen once yet while
making the tree build with this change.
For the same reasons, reflect.Zero (formerly reflect.MakeZero)
would also return an unassignable, unaddressable value.
This invalidates the (awkward) idiom:
pv := ... some Ptr Value we have ...
v := reflect.Zero(pv.Type().Elem())
pv.PointTo(v)
which, when the API changed, turned into:
pv := ... some Ptr Value we have ...
v := reflect.Zero(pv.Type().Elem())
pv.Set(v.Addr())
In both, it is far from clear what the code is trying to do. Now that
it is possible, this CL adds reflect.New(Type) Value that does the
obvious thing (same as Go's new), so this code would be replaced by:
pv := ... some Ptr Value we have ...
pv.Set(reflect.New(pv.Type().Elem()))
The changes just described can be confusing to think about,
but I believe it is because the old API was confusing - it was
conflating two different kinds of Values - and that the new API
by itself is pretty simple: you can only Set (or call Addr on)
a Value if it actually addresses some real piece of data; that is,
only if it is the result of dereferencing a Ptr or indexing a Slice.
If you really want the old behavior, you'd get it by translating:
v := reflect.NewValue(x)
into
v := reflect.New(reflect.Typeof(x)).Elem()
v.Set(reflect.NewValue(x))
Gofix will not be able to help with this, because whether
and how to change the code depends on whether the original
code meant use (1) or use (2), so the developer has to read
and think about the code.
You can see the effect on packages in the tree in
https://golang.org/cl/4423043/.
R=r
CC=golang-dev
https://golang.org/cl/4435042
|
|
R=r, r2
CC=golang-dev
https://golang.org/cl/4173060
|
|
R=rsc, mattn
CC=golang-dev
https://golang.org/cl/4047047
|
|
Prefix all external symbols in runtime by runtime·,
to avoid conflicts with possible symbols of the same
name in linked-in C libraries. The obvious conflicts
are printf, malloc, and free, but hide everything to
avoid future pain.
The symbols left alone are:
** known to cgo **
_cgo_free
_cgo_malloc
libcgo_thread_start
initcgo
ncgocall
** known to linker **
_rt0_$GOARCH
_rt0_$GOARCH_$GOOS
text
etext
data
end
pclntab
epclntab
symtab
esymtab
** known to C compiler **
_divv
_modv
_div64by32
etc (arch specific)
Tested on darwin/386, darwin/amd64, linux/386, linux/amd64.
Built (but not tested) for freebsd/386, freebsd/amd64, linux/arm, windows/386.
R=r, PeterGo
CC=golang-dev
https://golang.org/cl/2899041
|
|
The hash_next_and_deref was a dreg from a
previous large value scheme.
Fixes #1163.
R=r, r2
CC=golang-dev
https://golang.org/cl/2369043
|
|
Fixes #772.
R=ken2
CC=golang-dev
https://golang.org/cl/1206043
|
|
Fixes #589.
R=ken2
CC=golang-dev
https://golang.org/cl/1032044
|
|
R=ken2, r
CC=golang-dev
https://golang.org/cl/871042
|
|
will return the "zero" value
R=rsc
CC=golang-dev
https://golang.org/cl/700041
|
|
check that NOSPLIT functions don't use too much stack.
correct some missing NOSPLITs in the runtime library.
Fixes bug reported in
https://groups.google.com/group/golang-nuts/t/efff68b73941eccf
R=ken2
CC=golang-dev
https://golang.org/cl/236041
|
|
(eliminate assumption of package global name space,
make code easier to move between packages).
R=r
CC=golang-dev
https://golang.org/cl/194072
|
|
in various already expensive routines.
helps keep cpu utilization up when GOMAXPROCS > 1,
but not a full solution.
http://groups.google.com/group/golang-nuts/t/7a9535c4136d3e2
R=r
CC=golang-dev
https://golang.org/cl/184043
|
|
because they are in package runtime.
another step to enforcing package boundaries.
R=r
DELTA=732 (114 added, 93 deleted, 525 changed)
OCL=35811
CL=35824
|
|
they can get the official alignment out of there
instead of guessing.
R=ken
OCL=34450
CL=34450
|
|
R=rsc
DELTA=444 (179 added, 177 deleted, 88 changed)
OCL=33847
CL=33849
|
|
R=r
DELTA=304 (248 added, 34 deleted, 22 changed)
OCL=31345
CL=31347
|
|
R=ken
OCL=31125
CL=31125
|
|
input parameters, move output parameters
into their own struct.
R=ken
OCL=30954
CL=30966
|
|
tests: all.bash passes, gobuild still works, godoc still works.
R=rsc
OCL=30096
CL=30102
|
