Putting it before the Index (where it is now) is wrong:
we don't even know what's in the package yet.
Fixes#4484.
R=adg, dsymonds
CC=golang-dev
https://golang.org/cl/6868071
We have been using all three terms "indices", "indexes",
and "index expressions" indiscriminatly for index values.
With this change, "index" refers to an index value,
"indices" is the plural of "index", and "index expression"
refers to an array, slice, or map indexed by an index: a[x].
R=r, rsc, iant, ken, mtj
CC=golang-dev
https://golang.org/cl/6912056
Can happen in both request and response.
Also use it in one place that wasn't.
Fixes#3997.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6903057
Fixes#4492.
% go version
go version devel +6b602ab487d6 Sat Dec 08 14:43:00 2012 +0100 linux/amd64
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6906058
New in Go 1 will be nanosecond precision in the result of time.Now on Linux.
This will break code that stores time in external formats at microsecond
precision, reads it back, and expects to get exactly the same time.
Code like that can be fixed by using time.Now().Round(time.Microsecond)
instead of time.Now() in those contexts.
R=golang-dev, bradfitz, iant, remyoudompheng
CC=golang-dev
https://golang.org/cl/6903050
This changes the output of
rand.Seed(0)
perm := rand.Perm(100)
When giving the same seeds to Go 1.0 and Go 1.1 programs
I would like them to generate the same random numbers.
««« original CL description
math/rand: remove noop iteration in Perm
The first iteration always do `m[0], m[0] = m[0], m[0]`, because
`rand.Intn(1)` is 0.
fun note: IIRC in TAOCP version of this algorithm, `i` goes
backward (n-1->1), meaning that the "already" shuffled part of the
array is never altered betweens iterations, while in the current
implementation the "not-yet" shuffled part of the array is
conserved between iterations.
R=golang-dev
CC=golang-dev
https://golang.org/cl/6845121
»»»
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6905049
gotype can now handle much of the standard library.
- marked packages which have type checker issues
- this CL depends on CL 6846131
R=rsc
CC=golang-dev
https://golang.org/cl/6850130
Also:
- better handling of type assertions
- implemented built-in error type
- first cut at handling variadic function signatures
- several bug fixes
R=rsc, rogpeppe
CC=golang-dev
https://golang.org/cl/6846131
The spec didn't preclude invalid type assertions and
type switches, i.e., cases where a concrete type doesn't
implement the interface type in the assertion in the first
place. Both, the gc and gccgo compiler exclude these cases.
This is documenting the status quo.
Also:
- minor clean up of respective examples
- added sentence about default case in select statements
Fixes#4472.
R=rsc, iant, r, ken
CC=golang-dev
https://golang.org/cl/6869050
The fixjmp step eliminates redundant chains of JMP
instructions that are produced by the compiler during
code generation.
It is already implemented in gc, and can be adapted to 6c/8c with
the exception that JMPs refer to destination by pc instead of by
pointer. The algorithm is modified to operate on Regs instead of Progs
for this reason. The pcs are already restored later by regopt.
R=goalng-dev, rsc
CC=golang-dev
https://golang.org/cl/6865046
Add missing file that should have been included in CL 6854063 / 5eac1a2d6fc3
R=remyoudompheng, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6891049
The 0-length part is fine, but some callers that write 0 bytes
also pass nil as the data pointer, and the Plan 9 kernel kills the
process with 'invalid address in sys call' in that case.
R=ken2
CC=golang-dev
https://golang.org/cl/6862051
Per the curl man page, the http_proxy configuration can be
of the form:
[protocol://]<host>[:port]
And we had a test that <ip>:<port> worked, but if
the host began with a letter, url.Parse parsed the hostname
as the scheme instead, confusing ProxyFromEnvironment.
R=golang-dev
CC=golang-dev
https://golang.org/cl/6875060
Used to say:
issue4251.go:12: inverted slice range
issue4251.go:12: constant -1 overflows uint64
issue4251.go:16: inverted slice range
issue4251.go:16: constant -1 overflows uint64
issue4251.go:20: inverted slice range
issue4251.go:20: constant -1 overflows uint64
With this patch, only gives the "inverted slice range" errors.
R=golang-dev, daniel.morsing
CC=golang-dev
https://golang.org/cl/6871058
Fixes#4396.
For fixed arrays larger than the unmapped page, agenr would general a nil check by loading the first word of the array. However there is no requirement for the first element of a byte array to be word aligned, so this check causes a trap on ARMv5 hardware (ARMv6 since relaxed that restriction, but it probably still comes at a cost).
Switching the check to MOVB ensures alignment is not an issue. This check is only invoked in a few places in the code where large fixed arrays are embedded into structs, compress/lzw is the biggest offender, and switching to MOVB has no observable performance penalty.
Thanks to Rémy and Daniel Morsing for helping me debug this on IRC last night.
R=remyoudompheng, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6854063
The current spec says that when calling make, if both len and
cap are constant, it is an error if len > cap. The gc
compiler does not yet implement that, but when it does this
will need to change. Changing it now for the benefit of
gccgo.
R=gri
CC=golang-dev
https://golang.org/cl/6867064
Using append simplifies the code and makes it work if
the initial capacity of the slice is smaller than the
number of items pushed.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/6869060
