1. 16 Sep, 2013 22 commits
  2. 15 Sep, 2013 4 commits
  3. 14 Sep, 2013 1 commit
    • Rémy Oudompheng's avatar
      cmd/gc: don't generate algs for internal map types. · 04c40c97
      Rémy Oudompheng authored
      Fake types describing the internal structure of hashmaps are
      generated for use by precise GC.
      
      Generating hash and eq functions for these fake types slows down
      the build and wastes space: the go tool binary size is 13MB
      instead of 12MB, and the package size on amd64 is 48.7MB instead
      of 45.3MB.
      
      R=golang-dev, daniel.morsing, r, khr, rsc, iant
      CC=golang-dev
      https://golang.org/cl/13698043
      04c40c97
  4. 13 Sep, 2013 10 commits
  5. 12 Sep, 2013 3 commits
    • Russ Cox's avatar
      encoding/xml: add Encoder.Flush · 3c11dd8e
      Russ Cox authored
      Fixes #6365.
      
      R=golang-dev, bradfitz
      CC=golang-dev
      https://golang.org/cl/13627046
      3c11dd8e
    • Russ Cox's avatar
      runtime, cmd/gc, cmd/ld: ignore method wrappers in recover · 7276c02b
      Russ Cox authored
      Bug #1:
      
      Issue 5406 identified an interesting case:
              defer iface.M()
      may end up calling a wrapper that copies an indirect receiver
      from the iface value and then calls the real M method. That's
      two calls down, not just one, and so recover() == nil always
      in the real M method, even during a panic.
      
      [For the purposes of this entire discussion, a wrapper's
      implementation is a function containing an ordinary call, not
      the optimized tail call form that is somtimes possible. The
      tail call does not create a second frame, so it is already
      handled correctly.]
      
      Fix this bug by introducing g->panicwrap, which counts the
      number of bytes on current stack segment that are due to
      wrapper calls that should not count against the recover
      check. All wrapper functions must now adjust g->panicwrap up
      on entry and back down on exit. This adds slightly to their
      expense; on the x86 it is a single instruction at entry and
      exit; on the ARM it is three. However, the alternative is to
      make a call to recover depend on being able to walk the stack,
      which I very much want to avoid. We have enough problems
      walking the stack for garbage collection and profiling.
      Also, if performance is critical in a specific case, it is already
      faster to use a pointer receiver and avoid this kind of wrapper
      entirely.
      
      Bug #2:
      
      The old code, which did not consider the possibility of two
      calls, already contained a check to see if the call had split
      its stack and so the panic-created segment was one behind the
      current segment. In the wrapper case, both of the two calls
      might split their stacks, so the panic-created segment can be
      two behind the current segment.
      
      Fix this by propagating the Stktop.panic flag forward during
      stack splits instead of looking backward during recover.
      
      Fixes #5406.
      
      R=golang-dev, iant
      CC=golang-dev
      https://golang.org/cl/13367052
      7276c02b
    • Josh Bleecher Snyder's avatar
      go/token: rename RemoveLine to MergeLine, improve documentation · 1ea0c480
      Josh Bleecher Snyder authored
      This is a follow-up to feedback from gri in
      https://golang.org/cl/12837044/. Most of the wording
      and naming improvements are lifted shamelessly from him.
      
      R=gri
      CC=golang-dev
      https://golang.org/cl/13670043
      1ea0c480