Setenv("AN_ENV_VAR", "") deletes AN_ENV_VAR instead of setting it
to "" at this moment. Also Getenv("AN_ENV_VAR") returns "not found",
if AN_ENV_VAR is "". Change it, so they behave like unix.
Fixes#5610
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10594043
Makes it easy to ask the simple question, what is the hash of this data?
Also fix the commentary and prints in Sum256.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10630043
With this CL, go test -short -cover std successfully builds and
runs all the standard package tests. The tests that look a file
line numbers (log and runtime/debug) fail, because cover is
not inserting //line directives. Everything else passes.
ok cmd/api 0.038s coverage: 66.6% of statements
? cmd/cgo [no test files]
ok cmd/fix 0.043s coverage: 27.2% of statements
ok cmd/go 0.063s coverage: 2.4% of statements
? cmd/godoc [no test files]
ok cmd/gofmt 0.085s coverage: 61.3% of statements
? cmd/yacc [no test files]
ok archive/tar 0.023s coverage: 74.2% of statements
ok archive/zip 0.075s coverage: 71.8% of statements
ok bufio 0.149s coverage: 88.2% of statements
ok bytes 0.135s coverage: 90.4% of statements
ok compress/bzip2 0.087s coverage: 85.1% of statements
ok compress/flate 0.632s coverage: 79.3% of statements
ok compress/gzip 0.027s coverage: 76.7% of statements
ok compress/lzw 0.141s coverage: 71.2% of statements
ok compress/zlib 1.123s coverage: 77.2% of statements
ok container/heap 0.020s coverage: 85.8% of statements
ok container/list 0.021s coverage: 92.5% of statements
ok container/ring 0.030s coverage: 86.5% of statements
? crypto [no test files]
ok crypto/aes 0.054s coverage: 54.3% of statements
ok crypto/cipher 0.027s coverage: 68.8% of statements
ok crypto/des 0.041s coverage: 83.8% of statements
ok crypto/dsa 0.027s coverage: 33.1% of statements
ok crypto/ecdsa 0.048s coverage: 48.7% of statements
ok crypto/elliptic 0.030s coverage: 91.6% of statements
ok crypto/hmac 0.019s coverage: 83.3% of statements
ok crypto/md5 0.020s coverage: 78.7% of statements
ok crypto/rand 0.057s coverage: 20.8% of statements
ok crypto/rc4 0.092s coverage: 70.8% of statements
ok crypto/rsa 0.261s coverage: 80.8% of statements
ok crypto/sha1 0.019s coverage: 83.9% of statements
ok crypto/sha256 0.021s coverage: 89.0% of statements
ok crypto/sha512 0.023s coverage: 88.7% of statements
ok crypto/subtle 0.027s coverage: 83.9% of statements
ok crypto/tls 0.833s coverage: 79.7% of statements
ok crypto/x509 0.961s coverage: 74.9% of statements
? crypto/x509/pkix [no test files]
ok database/sql 0.033s coverage: 75.0% of statements
ok database/sql/driver 0.020s coverage: 46.2% of statements
ok debug/dwarf 0.023s coverage: 71.5% of statements
ok debug/elf 0.035s coverage: 58.2% of statements
ok debug/gosym 0.022s coverage: 1.8% of statements
ok debug/macho 0.023s coverage: 63.7% of statements
ok debug/pe 0.024s coverage: 50.5% of statements
ok encoding/ascii85 0.021s coverage: 89.7% of statements
ok encoding/asn1 0.022s coverage: 77.9% of statements
ok encoding/base32 0.022s coverage: 91.4% of statements
ok encoding/base64 0.020s coverage: 90.7% of statements
ok encoding/binary 0.022s coverage: 66.2% of statements
ok encoding/csv 0.022s coverage: 88.5% of statements
ok encoding/gob 0.064s coverage: 82.2% of statements
ok encoding/hex 0.019s coverage: 86.3% of statements
ok encoding/json 0.047s coverage: 77.3% of statements
ok encoding/pem 0.026s coverage: 80.5% of statements
ok encoding/xml 0.039s coverage: 85.0% of statements
ok errors 0.022s coverage: 100.0% of statements
ok expvar 0.048s coverage: 72.0% of statements
ok flag 0.019s coverage: 86.9% of statements
ok fmt 0.062s coverage: 91.2% of statements
ok go/ast 0.028s coverage: 46.3% of statements
ok go/build 0.190s coverage: 75.4% of statements
ok go/doc 0.095s coverage: 76.7% of statements
ok go/format 0.036s coverage: 79.8% of statements
ok go/parser 0.075s coverage: 82.0% of statements
ok go/printer 0.733s coverage: 88.6% of statements
ok go/scanner 0.031s coverage: 86.5% of statements
ok go/token 0.062s coverage: 79.7% of statements
? hash [no test files]
ok hash/adler32 0.029s coverage: 49.0% of statements
ok hash/crc32 0.020s coverage: 64.2% of statements
ok hash/crc64 0.021s coverage: 53.5% of statements
ok hash/fnv 0.018s coverage: 75.5% of statements
ok html 0.022s coverage: 4.5% of statements
ok html/template 0.087s coverage: 83.9% of statements
ok image 0.108s coverage: 67.1% of statements
ok image/color 0.026s coverage: 20.1% of statements
ok image/draw 0.049s coverage: 69.6% of statements
ok image/gif 0.019s coverage: 65.2% of statements
ok image/jpeg 0.197s coverage: 78.6% of statements
ok image/png 0.055s coverage: 56.5% of statements
ok index/suffixarray 0.027s coverage: 82.4% of statements
ok io 0.037s coverage: 83.4% of statements
ok io/ioutil 0.022s coverage: 70.1% of statements
FAIL log 0.020s
ok log/syslog 2.063s coverage: 71.1% of statements
ok math 0.023s coverage: 76.5% of statements
ok math/big 0.235s coverage: 79.2% of statements
ok math/cmplx 0.020s coverage: 66.5% of statements
ok math/rand 0.031s coverage: 69.9% of statements
ok mime 0.022s coverage: 83.0% of statements
ok mime/multipart 0.389s coverage: 76.1% of statements
ok net 2.219s coverage: 58.0% of statements
ok net/http 4.744s coverage: 82.9% of statements
ok net/http/cgi 0.593s coverage: 68.5% of statements
ok net/http/cookiejar 0.038s coverage: 90.3% of statements
ok net/http/fcgi 0.047s coverage: 37.6% of statements
ok net/http/httptest 0.068s coverage: 68.9% of statements
ok net/http/httputil 0.058s coverage: 52.8% of statements
? net/http/pprof [no test files]
ok net/mail 0.025s coverage: 80.3% of statements
ok net/rpc 0.063s coverage: 71.5% of statements
ok net/rpc/jsonrpc 0.047s coverage: 81.3% of statements
ok net/smtp 0.032s coverage: 74.1% of statements
ok net/textproto 0.023s coverage: 66.0% of statements
ok net/url 0.020s coverage: 78.2% of statements
ok os 4.729s coverage: 73.3% of statements
ok os/exec 39.620s coverage: 65.1% of statements
ok os/signal 0.541s coverage: 89.9% of statements
ok os/user 0.022s coverage: 62.2% of statements
ok path 0.018s coverage: 90.8% of statements
ok path/filepath 10.834s coverage: 88.4% of statements
ok reflect 0.055s coverage: 83.2% of statements
ok regexp 0.084s coverage: 75.5% of statements
ok regexp/syntax 0.547s coverage: 85.2% of statements
ok runtime 4.755s coverage: 75.9% of statements
? runtime/cgo [no test files]
FAIL runtime/debug 0.018s
ok runtime/pprof 0.368s coverage: 8.5% of statements
? runtime/race [no test files]
ok sort 0.059s coverage: 97.7% of statements
ok strconv 0.315s coverage: 95.6% of statements
ok strings 0.147s coverage: 96.1% of statements
ok sync 0.083s coverage: 56.7% of statements
ok sync/atomic 0.035s coverage: 0.0% of statements
ok syscall 0.043s coverage: 24.0% of statements
ok testing 0.018s coverage: 24.0% of statements
? testing/iotest [no test files]
ok testing/quick 0.062s coverage: 83.2% of statements
ok text/scanner 0.020s coverage: 91.5% of statements
ok text/tabwriter 0.021s coverage: 90.4% of statements
ok text/template 0.052s coverage: 81.1% of statements
ok text/template/parse 0.024s coverage: 86.1% of statements
ok time 2.431s coverage: 88.8% of statements
ok unicode 0.024s coverage: 92.1% of statements
ok unicode/utf16 0.017s coverage: 97.3% of statements
ok unicode/utf8 0.019s coverage: 97.4% of statements
? unsafe [no test files]
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10586043
Makes it easy to ask the simple question, what is the hash of this data?
Also mark block as non-escaping.
R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/10624044
Before, some packages disappear silently if the package cannot be imported,
such as if the import statement is unparseable.
Before:
% ls src
foo issue
% go list ./...
_/home/r/bug/src/foo
%
After:
% go list ./...
src/issue/issue.go:3:5: expected 'STRING', found newline
_/home/r/bug/src/foo
%
R=rsc
CC=golang-dev
https://golang.org/cl/10568043
race is more important than arch (moreover race implies x64)
don't know how to test it
R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/10484046
Functions without bodies were excluded from the ordering logic,
because when I wrote the ordering logic there was no reason to
analyze them.
But then we added //go:noescape tags that need analysis, and we
didn't update the ordering logic.
So in the absence of good ordering, //go:noescape only worked
if it appeared before the use in the source code.
Fixes#5773.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10570043
USEFIELD is a special kind of NOP, so treat it like a NOP
when generating the pc-ln table.
There are more invasive fixes that could be applied here.
I am going for minimum number of lines changed.
The smallest test case we know of is five distinct Go files
in four packages, and the bug only happens with
GOEXPERIMENT=fieldtrack enabled, which we don't
normally build with, so the test would never run
meaningfully anyway.
Fixes#5762.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10495044
If you hg update your client to an earlier CL, then
hg sync will move you back to tip if it pulls anything in,
but it will leave you where you are if it doesn't pull anything in.
That's confusing: make hg sync always update to tip.
R=golang-dev, bradfitz, r, dsymonds
CC=golang-dev
https://golang.org/cl/10456044
Built after adding -Wconversion to the list of compiler
arguments used when building. I believe these are all OK
assuming we will not change the API. There is no effort to
detect overflow due to very long strings.
R=golang-dev, dave, rsc, r
CC=golang-dev
https://golang.org/cl/10195044
Currently more than 1 gorutine can execute raceWrite() in Wait()
in the following scenario:
1. goroutine 1 executes first check of wg.counter, sees that it's == 0
2. goroutine 2 executes first check of wg.counter, sees that it's == 0
3. goroutine 2 locks the mutex, sees that he is the first waiter and executes raceWrite()
4. goroutine 2 block on the semaphore
5. goroutine 3 executes Done() and unblocks goroutine 2
6. goroutine 1 lock the mutex, sees that he is the first waiter and executes raceWrite()
It produces the following false report:
WARNING: DATA RACE
Write by goroutine 35:
sync.raceWrite()
src/pkg/sync/race.go:41 +0x33
sync.(*WaitGroup).Wait()
src/pkg/sync/waitgroup.go:103 +0xae
command-line-arguments_test.TestNoRaceWaitGroupMultipleWait2()
src/pkg/runtime/race/testdata/waitgroup_test.go:156 +0x19a
testing.tRunner()
src/pkg/testing/testing.go:361 +0x108
Previous write by goroutine 36:
sync.raceWrite()
src/pkg/sync/race.go:41 +0x33
sync.(*WaitGroup).Wait()
src/pkg/sync/waitgroup.go:103 +0xae
command-line-arguments_test.func·012()
src/pkg/runtime/race/testdata/waitgroup_test.go:148 +0x4d
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10424043
Resubmit 3c2cddfbdaec now that windows callbacks
are not generated during runtime.
Fixes#5494
R=golang-dev, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/10487043
- change runtime_pollWait so it does not return
closed or timeout if IO is ready - windows must
know if IO has completed or not even after
interruption;
- add (*pollDesc).Prepare(mode int) that can be
used for both read and write, same for Wait;
- introduce runtime_pollWaitCanceled and expose
it in net as (*pollDesc).WaitCanceled(mode int);
Full windows netpoll changes are
here https://golang.org/cl/8670044/.
R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/10485043
The compiler still gets the escape analysis wrong, but the annotation here is correct.
R=golang-dev, dave, bradfitz
CC=golang-dev
https://golang.org/cl/10514046
No semantic change.
I found the wording distracting in a couple of instances and was moved to improve it.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10478048
If a server response contains a Content-Length and the body is short,
the Transport should end in io.ErrUnexpectedEOF, not io.EOF.
Fixes#5738
R=golang-dev, kevlar, r
CC=golang-dev
https://golang.org/cl/10237050
In general the description should describe what is added or fixed,
not how it was done (the code does this), but in this case the cause
was delete was missing, so the fix is to add it.
Fixes issue 5765.
R=golang-dev, iant, r
CC=golang-dev
https://golang.org/cl/10496043
until we decide what to do with issues 5659/5736.
Profiling with race detector is not very useful in general,
and now it makes race builders red.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10523043
Time is a tiny struct, so the compiler copies a Time by
copying each of the three fields.
The layout of a time on amd64 is [ptr int32 gap32 ptr].
Copying a Time onto a location that formerly held a pointer in the
second word changes only the low 32 bits, creating a different
but still plausible pointer. This confuses the garbage collector
when it appears in argument or result frames.
To avoid this problem, declare nsec as uintptr, so that there is
no gap on amd64 anymore, and therefore no partial pointers.
Note that rearranging the fields to put the int32 last still leaves
a gap - [ptr ptr int32 gap32] - because Time must have a total
size that is ptr-width aligned.
Update #5749
This CL is enough to fix the problem, but we should still do
the other actions listed in the initial report. We're not too far
from completely precise collection.
R=golang-dev, dvyukov, r
CC=golang-dev
https://golang.org/cl/10504043
In general the description should describe what is added or fixed,
not how it was done (the code does this), but in this
case the cause were "/ /= ;" was missing,
so the fix is to add it.
Fixes#5761.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/10479043
In general the description should describe what is added or fixed, not how it was done (the code does this), but in this case the cause was delete was missing, so the fix is to add it.
Fixes#5759.
R=adg
CC=dave, dominik.honnef, gobot, golang-dev
https://golang.org/cl/10476043
The tradition is to use _posix when the platform extends beyond unix variants. As windows has its own file, rename to the more usual _unix.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10320043
If time.Sub results in a value that won't fit in a Duration (int64),
return either the min or max int64 value as appropriate.
Fixes#5011.
R=golang-dev, bradfitz, r, rsc
CC=golang-dev
https://golang.org/cl/10328043
The existing compilers convert empty strings to empty
but non-nil byte and rune slices. The spec required
a nil byte and rune slice in those cases. That seems
an odd additional requirement. Adjust the spec to
match the reality.
Also, removed over-specification for conversions of
nil []byte and []rune: such nil slices already act
like empty slices and thus don't need extra language.
Added extra examples instead.
Fixes#5704.
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/10440045
trivial: it is not a serious problem to leak a fd in a short lived process, but it was obscuring my investigation of issue 5593.
R=golang-dev, iant, bradfitz
CC=golang-dev
https://golang.org/cl/10391043
The old code worked, somewhat on accident, but was confusing,
and had a useless assignment to the inner err. It worked
because url.Parse parses just about anything, so the outer err
was always nil, so it always fell through to the bottom return
statement, even without the "err = nil" line.
Instead, just have two return statements, and add a comment.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10448044
