- 20 Apr, 2011 12 commits
-
-
Rob Pike authored
to regularize the errors. R=rsc CC=golang-dev https://golang.org/cl/4446055
-
Russ Cox authored
TBR=r CC=golang-dev https://golang.org/cl/4425059
-
Rob Pike authored
to improve the code and removea TODO. R=rsc CC=golang-dev https://golang.org/cl/4443054
-
Brad Fitzpatrick authored
Fixes #1589 R=rsc CC=golang-dev https://golang.org/cl/4443053
-
Russ Cox authored
Fixes #1571. R=ken2 CC=golang-dev https://golang.org/cl/4443052
-
Russ Cox authored
This CL makes reflect require that values be assignable to the target type in exactly the same places where that is the rule in Go. It also adds the Implements and AssignableTo methods so that callers can check the types themselves so as to avoid a panic. Before this CL, reflect required strict type identity. This CL expands Call to accept and correctly marshal arbitrary argument lists for variadic functions; it introduces CallSlice for use in the case where the slice for the variadic argument is already known. Fixes #327. Fixes #1212. R=r, dsymonds CC=golang-dev https://golang.org/cl/4439058
-
Russ Cox authored
Fixes #1710. R=ken2 CC=golang-dev https://golang.org/cl/4444054
-
Russ Cox authored
This CL makes it possible to resolve DNS names on OS X without offending the Application-Level Firewall. It also means that cross-compiling from one operating system to another is no longer possible when using package net, because cgo needs to be able to sniff around the local C libraries. We could special-case this one use and check in generated files, but it seems more trouble than it's worth. Cross compiling is dead anyway. It is still possible to use either GOARCH=amd64 or GOARCH=386 on typical Linux and OS X x86 systems. It is also still possible to build GOOS=linux GOARCH=arm on any system, because arm is for now excluded from this change (there is no cgo for arm yet). R=iant, r, mikioh CC=golang-dev https://golang.org/cl/4437053
-
Russ Cox authored
CanAddr was wrong, out of date; CanSet was incomplete. R=r CC=golang-dev https://golang.org/cl/4442066
-
Robert Griesemer authored
gofmt: also fix a typo in gofmt.go R=rsc, r CC=golang-dev https://golang.org/cl/4431055
-
David Crawshaw authored
Some code duplication with gofix. R=rsc, gri, bradfitzgo, r2, adg, peterGo, r, brainman CC=golang-dev https://golang.org/cl/4430054
-
Andrew Gerrand authored
This CL gives goinstall the ability to build commands, not just packages. "goinstall foo.googlecode.com/hg/bar" will build the command named "bar" and install it to GOBIN. "goinstall ." will use the name of the local directory as the command name. R=rsc, niemeyer CC=golang-dev https://golang.org/cl/4426045
-
- 19 Apr, 2011 9 commits
-
-
Nigel Tao authored
R=rsc CC=golang-dev https://golang.org/cl/4442064
-
Robert Griesemer authored
Specifically, fix a wrong comment. Fixes #1717. R=r, rsc CC=golang-dev https://golang.org/cl/4445050
-
Rob Pike authored
Forgot to send key/value types. R=rsc CC=golang-dev, hmc2you https://golang.org/cl/4434058
-
Russ Cox authored
R=golang-dev, bradfitzgo CC=golang-dev https://golang.org/cl/4425054
-
Adam Langley authored
* Accept armored private key blocks * If an armored block is missing, return an InvalidArgumentError, rather than ignoring it. * If every key in a block is skipped due to being unsupported, return the last unsupported error. * Include the numeric type of unsupported public keys. * Don't assume that the self-signature comes immediately after the user id packet. R=bradfitzgo CC=golang-dev https://golang.org/cl/4434048
-
Adam Langley authored
This pulls in changes that should have been in 3faf9d0c10c0, but weren't because x509.go was part of another changelist. TBR=bradfitzgo R=bradfitzgo CC=golang-dev https://golang.org/cl/4433056
-
Adam Langley authored
People have a need to verify certificates in situations other than TLS client handshaking. Thus this CL moves certificate verification into x509 and expands its abilities. R=bradfitzgo CC=golang-dev https://golang.org/cl/4407046
-
Nigel Tao authored
It is based on changeset 4186064 by Raph Levien <raph@google.com>. R=r, nigeltao_gnome CC=golang-dev https://golang.org/cl/4435051
-
Russ Cox authored
R=r CC=golang-dev https://golang.org/cl/4444049
-
- 18 Apr, 2011 11 commits
-
-
Russ Cox authored
I should have done this a year ago in: changeset: 5137:686b18098944 user: Russ Cox <rsc@golang.org> date: Thu Mar 25 14:05:54 2010 -0700 files: src/cmd/8c/swt.c description: make alignment rules match 8g, just like 6c matches 6g. R=ken2 CC=golang-dev https://golang.org/cl/760042 R=ken2 CC=golang-dev https://golang.org/cl/4437054
-
Russ Cox authored
Don't assume that localhost == 127.0.0.1. It might be ::1. R=bradfitzgo CC=golang-dev https://golang.org/cl/4430055
-
Russ Cox authored
R=golang-dev, r CC=golang-dev https://golang.org/cl/4423043
-
Russ Cox authored
* 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
-
Brad Fitzpatrick authored
R=r, rsc1 CC=golang-dev https://golang.org/cl/4440054
-
Brad Fitzpatrick authored
Fixes #1119. R=rsc, r CC=golang-dev https://golang.org/cl/4437052
-
Rob Pike authored
R=golang-dev, iant CC=golang-dev https://golang.org/cl/4446053
-
Russ Cox authored
R=ken2 CC=golang-dev https://golang.org/cl/4443047
-
Rob Pike authored
Interesting comparisons between old and new machine, and relationship between gccgo and gc. R=golang-dev, rsc1 CC=golang-dev https://golang.org/cl/4430045
-
Quan Yong Zhai authored
~$ nslookup www.google.com Server: 8.8.8.8 cannonical name = www-g-com-chn.l.google.com. R=adg, rsc CC=golang-dev https://golang.org/cl/4445045
-
Nigel Tao authored
R=adg CC=golang-dev, raph https://golang.org/cl/4443046
-
- 17 Apr, 2011 3 commits
-
-
Russ Cox authored
R=dfc, ken2, rsc CC=golang-dev https://golang.org/cl/4446043
-
Russ Cox authored
R=adg, r CC=golang-dev https://golang.org/cl/4423045
-
Dave Cheney authored
Possibly fixes issue 1694. R=bradfitzgo CC=golang-dev https://golang.org/cl/4427049
-
- 16 Apr, 2011 1 commit
-
-
Dmitry Chestnykh authored
Fixes #1633. R=adg, dsymonds CC=golang-dev https://golang.org/cl/4439042
-
- 15 Apr, 2011 4 commits
-
-
Brad Fitzpatrick authored
Working towards issue 1119 Using test data from http://greenbytes.de/tech/tc2231/ R=r CC=golang-dev https://golang.org/cl/4430049
-
Russ Cox authored
cannot use regalloc with floating point on 386. will redo some other way. R=ken2 CC=golang-dev https://golang.org/cl/4439045
-
Ross Light authored
R=bradfitzgo, rsc, bradfitzwork CC=golang-dev https://golang.org/cl/4406046
-
Russ Cox authored
R=ken2 CC=golang-dev https://golang.org/cl/4439044
-