Skip to content
Permalink
Branch: master
Commits on Nov 7, 2019
  1. math: test portable FMA even on system with hardware FMA

    rsc committed Nov 5, 2019
    This makes it a little less likely the portable FMA will be
    broken without realizing it.
    
    Change-Id: I7f7f4509b35160a9709f8b8a0e494c09ea6e410a
    Reviewed-on: https://go-review.googlesource.com/c/go/+/205337
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
    Reviewed-by: Keith Randall <khr@golang.org>
  2. math, cmd/compile: rename Fma to FMA

    rsc committed Nov 5, 2019
    This API was added for #25819, where it was discussed as math.FMA.
    The commit adding it used math.Fma, presumably for consistency
    with the rest of the unusual names in package math
    (Sincos, Acosh, Erfcinv, Float32bits, etc).
    
    I believe that using an idiomatic Go name is more important here
    than consistency with these other names, most of which are historical
    baggage from C's standard library.
    
    Early additions like Float32frombits happened before "uppercase for export"
    (so they were originally like "float32frombits") and they were not properly
    reconsidered when we uppercased the symbols to export them.
    That's a mistake we live with.
    
    The names of functions we have added since then, and even a few
    that were legacy, are more properly Go-cased, such as IsNaN, IsInf,
    and RoundToEven, rather than Isnan, Isinf, and Roundtoeven.
    And also constants like MaxFloat32.
    
    For new API, we should keep using proper Go-cased symbols
    instead of minimally-upper-cased-C symbols.
    
    So math.FMA, not math.Fma.
    
    This API has not yet been released, so this change does not break
    the compatibility promise.
    
    This CL also modifies cmd/compile, since the compiler knows
    the name of the function. I could have stopped at changing the
    string constants, but it seemed to make more sense to use a
    consistent casing everywhere.
    
    Change-Id: I0f6f3407f41e99bfa8239467345c33945088896e
    Reviewed-on: https://go-review.googlesource.com/c/go/+/205317
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Commits on Nov 4, 2019
  1. hash/maphash: revise API to be more idiomatic

    rsc committed Nov 4, 2019
    This CL makes these changes to the hash/maphash API to make it fit a bit
    more into the standard library:
    
     - Move some of the package doc onto type Hash, so that `go doc maphash.Hash` shows it.
    
     - Instead of having identical AddBytes and Write methods,
       standardize on Write, the usual name for this function.
       Similarly, AddString -> WriteString, AddByte -> WriteByte.
    
     - Instead of having identical Hash and Sum64 methods,
       standardize on Sum64 (for hash.Hash64). Dropping the "Hash" method
       also helps because Hash is usually reserved to mean the state of a
       hash function (hash.Hash etc), not the hash value itself.
    
     - Make an uninitialized hash.Hash auto-seed with a random seed.
       It is critical that users not use the same seed for all hash functions
       in their program, at least not accidentally. So the Hash implementation
       must either panic if uninitialized or initialize itself.
       Initializing itself is less work for users and can be done lazily.
    
     - Now that the zero hash.Hash is useful, drop maphash.New in favor of
       new(maphash.Hash) or simply declaring a maphash.Hash.
    
     - Add a [0]func()-typed field to the Hash so that Hashes cannot be compared.
       (I considered doing the same for Seed but comparing seeds seems OK.)
    
     - Drop the integer argument from MakeSeed, to match the original design
       in golang.org/issue/28322. There is no point to giving users control
       over the specific seed bits, since we want the interpretation of those
       bits to be different in every different process. The only thing users
       need is to be able to create a new random seed at each call.
       (Fixes a TODO in MakeSeed's public doc comment.)
    
    This API is new in Go 1.14, so these changes do not violate the compatibility promise.
    
    Fixes #35060.
    Fixes #35348.
    
    Change-Id: Ie6fecc441f3f5ef66388c6ead92e875c0871f805
    Reviewed-on: https://go-review.googlesource.com/c/go/+/205069
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Alan Donovan <adonovan@google.com>
    Reviewed-by: Keith Randall <khr@golang.org>
Commits on Sep 26, 2019
  1. context: use fewer goroutines in WithCancel/WithTimeout

    rsc committed Sep 19, 2019
    If the parent context passed to WithCancel or WithTimeout
    is a known context implementation (one created by this package),
    we attach the child to the parent by editing data structures directly;
    otherwise, for unknown parent implementations, we make a
    goroutine that watches for the parent to finish and propagates
    the cancellation.
    
    A common problem with this scheme, before this CL, is that
    users who write custom context implementations to manage
    their value sets cause WithCancel/WithTimeout to start
    goroutines that would have not been started before.
    
    This CL changes the way we map a parent context back to the
    underlying data structure. Instead of walking up through
    known context implementations to reach the *cancelCtx,
    we look up parent.Value(&cancelCtxKey) to return the
    innermost *cancelCtx, which we use if it matches parent.Done().
    
    This way, a custom context implementation wrapping a
    *cancelCtx but not changing Done-ness (and not refusing
    to return wrapped keys) will not require a goroutine anymore
    in WithCancel/WithTimeout.
    
    For #28728.
    
    Change-Id: Idba2f435c81b19fe38d0dbf308458ca87c7381e9
    Reviewed-on: https://go-review.googlesource.com/c/go/+/196521
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Commits on Aug 21, 2019
  1. cmd/go: accept GOSUMDB=sum.golang.google.cn

    rsc committed Aug 21, 2019
    This CL makes the go command understand that
    GOSUMDB=sum.golang.google.cn should connect
    to that domain but expect to find a checksum database
    signed by sum.golang.org there.
    
    The host sum.golang.google.cn is not yet completely
    configured; we hope it will be available in a few weeks.
    
    Change-Id: Ie0fc4323f0c7084dda59bd3b45fc406717fa16d9
    Reviewed-on: https://go-review.googlesource.com/c/go/+/191137
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Andrew Bonventre <andybons@golang.org>
Commits on Jul 8, 2019
  1. net/http: fix Transport.MaxConnsPerHost limits & idle pool races

    rsc committed Jun 28, 2019
    There were at least three races in the implementation of the pool of
    idle HTTP connections before this CL.
    
    The first race is that HTTP/2 connections can be shared for many
    requests, but each requesting goroutine would take the connection out
    of the pool and then immediately return it before using it; this
    created unnecessary, tiny little race windows during which another
    goroutine might dial a second connection instead of reusing the first.
    This CL changes the idle pool to just leave the HTTP/2 connection in
    the pool permanently (until there is reason to close it), instead of
    doing the take-it-out-put-it-back dance race.
    
    The second race is that “is there an idle connection?” and
    “register to wait for an idle connection” were implemented as two
    separate steps, in different critical sections. So a client could end
    up registered to wait for an idle connection and be waiting or perhaps
    dialing, not having noticed the idle connection sitting in the pool
    that arrived between the two steps.
    
    The third race is that t.getIdleConnCh assumes that the inability to
    send on the channel means the client doesn't need the result, when it
    could mean that the client has not yet entered the select.
    That is, the main dial does:
    
    	idleConnCh := t.getIdleConnCh(cm)
    	select {
    	case v := <-dialc:
    		...
    	case pc := <-idleConnCh
    		...
    	...
    	}
    
    But then tryPutIdleConn does:
    
    	waitingDialer := t.idleConnCh[key] // what getIdleConnCh(cm) returned
    	select {
    	case waitingDialer <- pconn:
    		// We're done ...
    		return nil
    	default:
    		if waitingDialer != nil {
    			// They had populated this, but their dial won
    			// first, so we can clean up this map entry.
    			delete(t.idleConnCh, key)
    		}
    	}
    
    If the client has returned from getIdleConnCh but not yet reached the
    select, tryPutIdleConn will be unable to do the send, incorrectly
    conclude that the client does not care anymore, and put the connection
    in the idle pool instead, again leaving the client dialing unnecessarily
    while a connection sits in the idle pool.
    
    (It's also odd that the success case does not clean up the map entry,
    and also that the map has room for only a single waiting goroutine for
    a given host.)
    
    None of these races mattered too much before Go 1.11: at most they
    meant that connections were not reused quite as promptly as possible,
    or a few more than necessary would be created. But Go 1.11 added
    Transport.MaxConnsPerHost, which limited the number of connections
    created for a given host. The default is 0 (unlimited), but if a user
    did explicitly impose a low limit (2 is common), all these misplaced
    conns could easily add up to the entire limit, causing a deadlock.
    This was causing intermittent timeouts in TestTransportMaxConnsPerHost.
    
    The addition of the MaxConnsPerHost support added its own races.
    
    For example, here t.incHostConnCount could increment the count
    and return a channel ready for receiving, and then the client would
    not receive from it nor ever issue the decrement, because the select
    need not evaluate these two cases in order:
    
    	select {
    	case <-t.incHostConnCount(cmKey):
    		// count below conn per host limit; proceed
    	case pc := <-t.getIdleConnCh(cm):
    		if trace != nil && trace.GotConn != nil {
    			trace.GotConn(httptrace.GotConnInfo{Conn: pc.conn, Reused: pc.isReused()})
    		}
    		return pc, nil
    	...
    	}
    
    Obviously, unmatched increments are another way to get to a deadlock.
    TestTransportMaxConnsPerHost deadlocked approximately 100% of
    the time with a small random sleep added between incHostConnCount
    and the select:
    
    	ch := t.incHostConnCount(cmKey):
    	time.Sleep(time.Duration(rand.Intn(10))*time.Millisecond)
    	select {
    	case <-ch
    		// count below conn per host limit; proceed
    	case pc := <-t.getIdleConnCh(cm):
    		...
    	}
    
    The limit also did not properly apply to HTTP/2, because of the
    decrement being attached to the underlying net.Conn.Close
    and net/http not having access to the underlying HTTP/2 conn.
    The alternate decrements for HTTP/2 may also have introduced
    spurious decrements (discussion in #29889). Perhaps those
    spurious decrements or other races caused the other intermittent
    non-deadlock failures in TestTransportMaxConnsPerHost,
    in which the HTTP/2 phase created too many connections (#31982).
    
    This CL replaces the buggy, racy code with new code that is hopefully
    neither buggy nor racy.
    
    Fixes #29889.
    Fixes #31982.
    Fixes #32336.
    
    Change-Id: I0dfac3a6fe8a6cdf5f0853722781fe2ec071ac97
    Reviewed-on: https://go-review.googlesource.com/c/go/+/184262
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>
Commits on Jul 1, 2019
  1. sync: document implementation of Once.Do

    rsc committed Jun 29, 2019
    It's not correct to use atomic.CompareAndSwap to implement Once.Do,
    and we don't, but why we don't is a question that has come up
    twice on golang-dev in the past few months.
    Add a comment to help others with the same question.
    
    Change-Id: Ia89ec9715cc5442c6e7f13e57a49c6cfe664d32c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/184261
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Rob Pike <r@golang.org>
    Reviewed-by: Ingo Oeser <nightlyone@googlemail.com>
Commits on Jun 29, 2019
  1. crypto/tls: deflake localPipe in tests

    rsc committed Jun 28, 2019
    The localPipe implementation assumes that every successful net.Dial
    results in exactly one successful listener.Accept. I don't believe this
    is guaranteed by essentially any operating system. For this test, we're
    seeing flakes on dragonfly (#29583).
    
    But see also #19519, flakes due to the same assumption on FreeBSD
    and macOS in package net's own tests.
    
    This CL rewrites localPipe to try a few times to get a matching pair
    of connections on the dial and accept side.
    
    Fixes #29583.
    
    Change-Id: Idb045b18c404eae457f091df20456c5ae879a291
    Reviewed-on: https://go-review.googlesource.com/c/go/+/184157
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>
Commits on Jun 28, 2019
  1. net: deflake TestVariousDeadlines

    rsc committed Jun 28, 2019
    TestVariousDeadlines starts a client and server.
    The client dials the server, sets a timeout on the connection,
    reads from it, gets a timeout error, closes the connection.
    The server writes an infinite stream of a's to each connection
    it accepts.
    
    The test was trying to run these in lockstep:
    run a client dial+read+timeout+close,
    wait for server to accept+write+error out on write to closed connection,
    repeat.
    
    On FreeBSD 11.2 and less frequently on macOS we see
    the test timeout waiting for the server to do its half of
    the lockstep dance.
    
    I believe the problem is that the client can do its step
    of the dance with such a short timeout that the read,
    timeout, and close happens before the server ever returns
    from the accept(2) system call. For the purposes of testing
    the client-side read timeout, this is fine. But I suspect
    that under some circumstances, the "TCP-accepted"
    connection does not translate into a "socket-layer-accepted"
    connection that triggers a return from accept(2).
    That is, the Go server never sees the connection at all.
    And the test sits there waiting for it to acknowledge
    being done with a connection it never started with.
    
    Fix the problem by not trying to lockstep with the server.
    
    This definitely fixes the flake, since the specific line that
    was calling t.Fatal is now deleted.
    
    This exposes a different flake, seen on a trybot run for an
    early version of this CL, in which the client's io.Copy does
    not stop within the time allotted. The problem now is that
    there is no guarantee that a read beyond the deadline with
    available data returns an error instead of the available data,
    yet the test assumes this guarantee, and in fact the opposite
    is usually true - we don't bother checking the deadline unless
    the read needs to block. That is, deadlines don't cut off a
    flood of available data, yet this test thinks they do.
    
    This CL therefore also changes the server not to send an
    infinite flood of data - don't send any data at all - so that
    the read deadline is guaranteed to be exercised.
    
    Fixes #19519.
    
    Change-Id: I58057c3ed94ac2aebab140ea597f317abae6e65e
    Reviewed-on: https://go-review.googlesource.com/c/go/+/184137
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>
  2. runtime: fix pprof cpu profile corruption on arm/mips/mipsle

    rsc committed Jun 28, 2019
    CL 42652 changed the profile handler for mips/mipsle to
    avoid recording a profile when in atomic functions, for fear
    of interrupting the 32-bit simulation of a 64-bit atomic with
    a lock. The profile logger itself uses 64-bit atomics and might
    deadlock (#20146).
    
    The change was to accumulate a count of dropped profile events
    and then send the count when the next ordinary event was sent:
    
    	if prof.hz != 0 {
    	+	if (GOARCH == "mips" || GOARCH == "mipsle") && lostAtomic64Count > 0 {
    	+		cpuprof.addLostAtomic64(lostAtomic64Count)
    	+		lostAtomic64Count = 0
    	+	}
     		cpuprof.add(gp, stk[:n])
     	}
    
    CL 117057 extended this behavior to include GOARCH == "arm".
    
    Unfortunately, the inserted cpuprof.addLostAtomic64 differs from
    the original cpuprof.add in that it neglects to acquire the lock
    protecting the profile buffer.
    
    This has caused a steady stream of flakes on the arm builders
    for the past 12 months, ever since CL 117057 landed.
    
    This CL moves the lostAtomic count into the profile buffer and
    then lets the existing addExtra calls take care of it, instead of
    duplicating the locking logic.
    
    Fixes #24991.
    
    Change-Id: Ia386c40034fcf46b31f080ce18f2420df4bb8004
    Reviewed-on: https://go-review.googlesource.com/c/go/+/184164
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Cherry Zhang <cherryyz@google.com>
Commits on Jun 12, 2019
  1. cmd/go: add GOPRIVATE environment variable

    rsc committed Jun 11, 2019
    It is too confusing to have to set GONOSUMDB and GONOPROXY
    in common use cases, but one cannot be guaranteed to be a
    subset of the other.
    
    This CL adds GOPRIVATE, which takes the same kind of pattern list
    but is defined as "these patterns are private (non-public) modules".
    Today the implication is that GOPRIVATE is the default setting for
    GONOSUMDB and GONOPROXY. If there are other accommodations
    to make for private packages in the future or in other tools,
    having this clear statement of intent will let us do that.
    (For example maybe an IDE integration would hyperlink an import
    path to godoc.org; consulting GOPRIVATE would be a reasonable
    way to decide not to do that for certain imports. In contrast,
    consulting GONOPROXY or GONOSUMDB clearly would not.)
    
    Fixes #32184.
    
    Change-Id: If54c12d353c7a0a5c0e0273764140cce3c154a02
    Reviewed-on: https://go-review.googlesource.com/c/go/+/181719
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>
    Reviewed-by: Jay Conrod <jayconrod@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
Commits on Jun 6, 2019
  1. net: remove non-cgo macOS resolver code

    rsc committed Jun 5, 2019
    The built-in Go resolver works significantly better.
    In particular, the use of res_search does not support
    CNAME or PTR queries and may not even be thread-safe.
    
    This CL is essentially a revert of CL 166297 plus fixes,
    including CL 180842.
    
    See CL 180842 for additional notes about problems
    with this approach.
    
    Fixes #31705.
    
    Change-Id: I0a30a0de2fbd04f6c461520fd34378c84aadf66c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/180843
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Keith Randall <khr@golang.org>
  2. net: fix non-cgo macOS resolver code

    rsc committed Jun 5, 2019
    This code was added in April in CL 166297, for #12524.
    This CL fixes the following problems in the code:
    
     - The test for failure in the assembly stubs checked for
       64-bit -1 instead of 32-bit -1 to decide to fetch errno.
    
     - These C routines (res_init and res_search) don't set errno anyway,
       so the Go code using errno to decide success is incorrect.
       (The routines set h_errno, which is a racy global variable
       that can't safely be consulted, storing values in a different
       error space.)
    
     - The Go call passed res_search a non-NUL-terminated name.
    
     - The C res_search rejects calls asking for TypeALL as opposed to
       more specific answers like TypeA/TypeAAAA/TypeCNAME,
       breaking cgoLookupHost in all cases and cgoLookupIP
       except with IP-version-specific networks.
    
     - The DNS response packet was parsed twice, once with msg.Unpack
       (discarded), and once with the lower-level dnsmessage.Parser.
       The Parser loop was missing a call to p.SkipAllQuestions, with the
       result that no DNS response packet would ever parse successfully.
    
     - The parsing of the DNS response answers, if reached, behaved as if
       that the AResource and AAAAResource record contained textual
       IP addresses, while in fact they contain binary ones. The calls to
       parseIPv4 and parseIPv6 therefore would always returns nil,
       so that no useful result would be returned from the resolver.
    
    With these fixes, cgoLookupIP can correctly resolve google.com
    and return both the A and AAAA addresses.
    
    Even after fixing all these things, TestGoLookupIP still fails,
    because it is testing that in non-cgo builds the cgo stubs
    correctly report "I can't handle the lookup", and as written the
    code intentionally violates that expectation.
    
    This CL adds new direct tests of the pseudo-cgo routines.
    The direct IP address lookups succeed, but the CNAME query
    causes res_search to hang, and the PTR query fails unconditionally
    (a trivial C program confirms these behaviors are due to res_search itself).
    
    Traditionally, res_search is only intended for single-threaded use.
    It is unclear whether this one is safe for use from multiple goroutines.
    If you run net.test under lldb, that causes syslog messages to be
    printed to standard error suggesting double-free bugs:
    
    	2019-06-05 19:52:43.505246-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD
    	2019-06-05 19:52:43.505274-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD
    	2019-06-05 19:52:43.505303-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD
    	2019-06-05 19:52:43.505329-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD
    
    This res_search is from libsystem_info; a normal C program would
    get res_search (#defined to res_9_search) from libresolv instead.
    It is unclear what the relation between the two is.
    Issue #12524 was about supporting the /etc/resolver directory tree,
    but only libresolv contains code for that; libsystem_info does not.
    So this code probably does not enable use of /etc/resolver.
    
    In short:
    
     - Before this CL, the code clearly had never run successfully.
     - The code appears not to improve upon the usual non-cgo fallback.
     - The code carries with it no tests of improved behavior.
     - The code breaks existing tests.
     - Calling res_search does not work for PTR/CNAME queries,
       so the code breaks existing behavior, even after this CL.
     - It's unclear whether res_search is safe to call from multiple threads.
     - It's unclear whether res_search is used by any other macOS programs.
    
    Given this, it probably makes sense to delete this code rather
    than rejigger the test. This CL fixes the code first, so that there
    is a working copy to bring back later if we find out that it really
    is necessary.
    
    For #31705.
    
    Change-Id: Id2e11e8ade43098b0f90dd4d16a62ca86a7a244a
    Reviewed-on: https://go-review.googlesource.com/c/go/+/180842
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Keith Randall <khr@golang.org>
  3. runtime: document, fix libc error checks on macOS

    rsc committed Jun 5, 2019
    It matters whether we are calling a function that would
    return a 32-bit or 64-bit -1 on error. A few sites were wrong
    and this key detail was omitted from syscall/syscallX docs.
    
    Change-Id: I48a421b6cc4d2d2b5e58f790cc947e3cb2f98940
    Reviewed-on: https://go-review.googlesource.com/c/go/+/180841
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Keith Randall <khr@golang.org>
  4. runtime: fix non-tab indentation in lookup_darwin_*.s

    rsc committed Jun 5, 2019
    Change-Id: Ie00494f098bd2bce9bfd1b18dbf9543cf46faad6
    Reviewed-on: https://go-review.googlesource.com/c/go/+/180840
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  5. runtime: fix scattered non-tab indentation in assembly

    rsc committed Jun 5, 2019
    Change-Id: I6940a4c747f2da871263afa6a4e3386395d5cf54
    Reviewed-on: https://go-review.googlesource.com/c/go/+/180839
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  6. net: fix conf.teardown call in TestGoLookupIPOrderFallbackToFile

    rsc committed Jun 5, 2019
    If the test fails, conf.teardown wouldn't be.
    It doesn't look like it matters much, but clean up anyway.
    
    Change-Id: I45c18095abfd49422975d061be20cbd971a98f8f
    Reviewed-on: https://go-review.googlesource.com/c/go/+/180780
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
  7. runtime: use default system stack size, not 64 kB, on non-cgo macOS

    rsc committed Jun 5, 2019
    At least one libc call we make
    (res_search, which calls _mdns_query and then mdns_item_call)
    pushes a 64 kB stack frame onto the stack.
    Then it faults on the guard page.
    
    Use the default system stack size, under the assumption
    that the C code being called is compatible with that stack size.
    
    For #31705.
    
    Change-Id: I1b0bfc2e54043c49f0709255988ef920ce30ee82
    Reviewed-on: https://go-review.googlesource.com/c/go/+/180779
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commits on May 29, 2019
  1. cmd/go: update docs for GOPROXY default

    rsc committed May 24, 2019
    The default is now "https://proxy.golang.org,direct" not just "https://proxy.golang.org"
    (as of CL 178720).
    
    Change-Id: I47e67602e994332b988ed1b75fa57319f3876cc6
    Reviewed-on: https://go-review.googlesource.com/c/go/+/178725
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>
Commits on May 24, 2019
  1. cmd/go: respect default proxy setting, add direct fallback

    rsc committed May 24, 2019
    Getenv("GOPROXY") says what the environment variable is
    (including looking in the go env file), but it doesn't include
    the default setting. This code needs to use cfg.GOPROXY
    to get the actual default. Fix and test that.
    
    Also, we forgot to include the fallback to direct for when
    the proxy serves a 404. Add and test that too.
    
    Also add HTTP fetch information to -x build flag output.
    (It does not belong in the -v output, despite the GOPATH go get
    command doing this.)
    
    Change-Id: Ieab7ef13cda3e1ad041dbe04921af206e2232c9c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/178720
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>
    Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Commits on May 23, 2019
  1. cmd/go: default to GOPROXY=https://proxy.golang.org and GOSUMDB=sum.g…

    rsc committed May 21, 2019
    …olang.org
    
    This CL changes the default module download and module verification mechanisms
    to use the Go module mirror and Go checksum database run by Google.
    See https://proxy.golang.org/privacy for the services' privacy policy.
    (Today, that URL is a redirect to Google's standard privacy policy,
    which covers these services as well. If we publish a more specific
    privacy policy just for these services, that URL will be updated to
    display or redirect to it.)
    
    See 'go help modules' and 'go help modules-auth' for details (added in this CL).
    
    To disable the mirror and checksum database for non-public modules:
    
    	go env -w GONOPROXY=*.private.net,your.com/*
    	go env -w GONOSUMDB=*.private.net,your.com/*
    
    (If you are using a private module proxy then you'd only do the second.)
    
    If you run into problems with the behavior of the go command when using
    the Go module mirror or the Go checksum database, please file issues at
    https://golang.org/issue/new, so that we can address them for the
    Go 1.13 release.
    
    For #25530.
    
    This CL also documents GONOPROXY.
    Fixes #32056.
    
    Change-Id: I2fde82e071742272b0842efd9580df1a56947fec
    Reviewed-on: https://go-review.googlesource.com/c/go/+/178179
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>
Commits on May 22, 2019
  1. all: shorten some tests

    rsc committed May 16, 2019
    Shorten some of the longest tests that run during all.bash.
    Removes 7r 50u 21s from all.bash.
    
    After this change, all.bash is under 5 minutes again on my laptop.
    
    For #26473.
    
    Change-Id: Ie0460aa935808d65460408feaed210fbaa1d5d79
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177559
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  2. misc/cgo/test: consolidate tests into fewer cgo source files

    rsc committed May 16, 2019
    Each different file that does import "C" must be compiled
    and analyzed separately by cgo. Having fewer files import "C"
    reduces the cost of building the test. This is especially important
    because this test is built and run four different times (with different
    settings) during all.bash.
    
    go test -c in this directory used to take over 20 seconds on my laptop.
    Now it takes under 5 seconds.
    
    Removes 23.4r 29.0u 21.5s from all.bash.
    
    For #26473.
    
    Change-Id: Ie7cb7b0d9d6138ebd2eb548d0d8ea6e409ae10b9
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177558
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commits on May 21, 2019
  1. all: remove PEM-encoded private keys from tests

    rsc committed May 21, 2019
    Gerrit is complaining about pushes that affect these files
    and forcing people to use -o nokeycheck, which defeats
    the point of the check. Hide the keys from this kind of scan
    by marking them explicitly as testing keys.
    
    This is a little annoying but better than training everyone
    who ever edits one of these test files to reflexively override
    the Gerrit check.
    
    The only remaining keys explicitly marked as private instead
    of testing are in examples, and there's not much to do
    about those. Hopefully they are not edited as much.
    
    Change-Id: I4431592b5266cb39fe6a80b40e742d97da803a0b
    Reviewed-on: https://go-review.googlesource.com/c/go/+/178178
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
  2. misc/cgo/errors: consolidate test work

    rsc committed May 16, 2019
    Build a single binary containing all the TestPointerChecks
    instead of building many small binaries,
    each with its own cgo+compile+link invocation.
    This cuts 'go test -run=TestPointerChecks'
    from 6.7r 35.5u 26.1s to 2.1r 2.1u 1.4s.
    
    Move as many cgo checks as possible into fewer test files
    for TestReportsTypeErrors too.
    This cuts 'go test -run=TestReportsTypeErrors'
    from 2.1r 6.7u 6.7s to 1.5r 2.5u 2.5s.
    
    After this change, all.bash runs in ~4:30 on my laptop.
    
    For #26473.
    
    Change-Id: I3787448b03689a1f62dd810957ab6013bb75582f
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177599
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  3. cmd/api: read std package info once, not per goos-goarch-cgo

    rsc committed May 16, 2019
    Cuts api test time from 12.7r 26.2u 14.2s to 7.5r 12.1u 2.2s.
    
    After this change, all.bash runs in ~4:36 on my laptop.
    
    For #26473.
    
    Change-Id: I4211e6afcd7ab61a4ed2c9a2aa5ac1ea04982695
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177597
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
  4. test: skip cross-arch codegen tests in all.bash

    rsc committed May 16, 2019
    The test/codegen tests check all architectures
    mentioned in the test file, but this requires
    building at least the runtime for that architecture.
    This CL changes the test to only check the local
    architecture, leaving checking of other architectures
    to the relevant builders, as usual.
    
    This cuts 'go run run.go codegen' by 12r 78u 21s.
    
    After this change, all.bash runs in ~4:40 on my laptop.
    
    For #26473.
    
    Change-Id: Ia0354d1aff2df2949f838528c8171410bc42dc8b
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177577
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commits on May 16, 2019
  1. testing: shorten go test -short testing

    rsc committed May 15, 2019
    This cuts the time for 'go test -short testing' from 0.9s to < 0.1s.
    
    Change-Id: Ib8402f80239e1e96ea5221dfd5cd0db08170d85b
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177420
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
  2. testing: panic on calls to Short/Verbose before Parse

    rsc committed May 15, 2019
    CL 121936 added this diagnostic to avoid a panic accessing *short.
    (Hence the "This shouldn't really be a panic" comment.)
    
    That CL was right to produce a clearer error than a plain memory fault,
    but I think wrong to print+exit instead of panicking. I just ran into
    one of these in a real program, and there is no indication anywhere
    of how the program reached this point. The panic will show that.
    So change print+exit to a panic with a helpful message, in contrast
    to the original panic with an unhelpful message and the current
    helpful message without stack trace.
    
    Change-Id: Ib2bae1dead4ccde92f00fa3a34c05241ff7690c6
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177419
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  3. cmd/dist: say 'go test .' instead of 'go test' in a few places for cl…

    rsc committed May 15, 2019
    …eaner output
    
    This just makes all.bash a bit less chatty.
    
    Change-Id: I7d2ecabf0c7d8df2065d7052718f611bb2907801
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177418
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  4. misc/cgo: disable testcarchive, testplugin during -short test (includ…

    rsc committed May 15, 2019
    …ing all.bash)
    
    These tests take 20 seconds each to rebuild the entire world
    in their respective modes. That's too much for short mode,
    including all.bash on developer machines.
    
    Keep doing it on builders and if someone runs 'go test' by hand
    in that directory.
    
    For #26473.
    
    Change-Id: I3dc6955bc3aa7a20fd170efcde72a7d19b37bdbf
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177417
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
  5. runtime: disable some tests in -quick mode

    rsc committed May 15, 2019
    Speeds up the "go test runtime -cpu=1,2,4 -short -quick" phase of all.bash.
    
    For #26473.
    
    Change-Id: I090f5a5aa754462b3253a2156dc31fa67ce7af2a
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177399
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
    Reviewed-by: Austin Clements <austin@google.com>
  6. cmd/go: cut 'go test -short cmd/go' time by about half

    rsc committed May 15, 2019
    Was 50 seconds on unloaded Mac laptop; now 27.
    Still longer than I would like, but every little bit helps.
    
    For #26473.
    
    Change-Id: Id4be016ee1555cbc3512eca0ae10236d7f06bd02
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177398
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
  7. cmd/go: rename renamed testing import

    rsc committed May 14, 2019
    _go_testing is equally unlikely and much less concerning
    than testing_xxxxxxxxxxxx if it appears in an error message
    (as it does, for example, in https://storage.googleapis.com/go-build-log/0d543f89/linux-amd64_3467a10e.log).
    
    Change-Id: I45dc3ebe2d3b6c9e53273cd21782ee11a53f5edb
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177197
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
  8. cmd/go: add more information to -debug-actiongraph

    rsc committed May 10, 2019
    Add information about action and build IDs,
    commands run, time spent in commands,
    and overall time to -debug-actiongraph output.
    
    Also avoid a terrible outcome in:
    
    	go build -debug-actiongraph x.go
    
    Change-Id: I7a3a638f4848d75f2bdc997517f4ab23656da4f1
    Reviewed-on: https://go-review.googlesource.com/c/go/+/177138
    Run-TryBot: Russ Cox <rsc@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>
Older
You can’t perform that action at this time.