1. 14 Jun, 2017 11 commits
    • Samuel Tan's avatar
      html/template: only search identifier nodes for predefined escapers · 882a6404
      Samuel Tan authored
      Predefined escapers (i.e. "html" and "urlquery") should only occur in
      Identifier nodes, and never in Field or Chain nodes, since these are
      global functions that return string values (see inline comments for more
      details). Therefore, skip Chain and Field nodes when searching for
      predefined escapers in template pipelines.
      
      Also, make a non-functional change two existing test cases to avoid
      giving the impression that it is valid to reference a field of a
      predefined escaper.
      
      Fixes #20323
      
      Change-Id: I34f722f443c778699fcdd575dc3e0fd1fd6f2eb3
      Reviewed-on: https://go-review.googlesource.com/43296Reviewed-by: default avatarSamuel Tan <samueltan@google.com>
      Reviewed-by: default avatarMike Samuel <mikesamuel@gmail.com>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      882a6404
    • Alberto Donizetti's avatar
      doc: list html/template and text/template changes in 1.9 relnotes · 2c3c8c42
      Alberto Donizetti authored
      Updates #20587
      
      Change-Id: I3d65a0124157990b302db8879ee1a4941124ea11
      Reviewed-on: https://go-review.googlesource.com/45730Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      2c3c8c42
    • Austin Clements's avatar
      runtime: record mutex event before readying · b067ad93
      Austin Clements authored
      Currently, semrelease1 readies the next waiter before recording a
      mutex event. However, if the next waiter is expecting to look at the
      mutex profile, as is the case in TestMutexProfile, this may delay
      recording the event too much.
      
      Swap the order of these operations so semrelease1 records the mutex
      event before readying the next waiter. This also means readying the
      next waiter is the very last thing semrelease1 does, which seems
      appropriate.
      
      Fixes #19139.
      
      Change-Id: I1a62063599fdb5d49bd86061a180c0a2d659474b
      Reviewed-on: https://go-review.googlesource.com/45751
      Run-TryBot: Austin Clements <austin@google.com>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarPeter Weinberger <pjw@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      b067ad93
    • Lynn Boger's avatar
      cmd/link: implement trampolines for ppc64le with ext linking · 738739f5
      Lynn Boger authored
      When using golang on ppc64le there have been issues
      when building executables that generate extremely large text
      sections.  This is due to the call instruction and the limitation
      on the offset field, which is smaller than most platforms.  If the
      size of the call target offset is too big for the offset field in
      the call instruction, then link errors can occur.
      
      The original solution to this problem in golang was to split the
      text section when it became too large, allowing the external (GNU)
      linker to insert the necessary stub to handle the long call.  That
      worked fine until the another size limit for the program size was hit,
      where a plt_branch was created instead of a long branch.  In that case
      the plt_branch code sequence expects r2 to contain the address of the
      TOC, but when golang creates dynamic executables by default
      (-buildmode=exe) r2 does not always contain the address of the TOC
      and as a result when building programs that reach this extremely
      large size, a runtime SEGV or SIGILL can occur due to branching to a bad
      address.
      
      When using internal linking, trampolines are generated to handle the
      long calls but the text sections are not split.  With this change,
      text sections will still be split approrpriately with external linking
      but if the buildmode being used does not maintain r2 as the TOC
      addresses, then trampolines will be created for those calls.
      
      Fixes #20497
      
      Change-Id: If5400b0f86c2c08e106b332be6db0b259b07d93d
      Reviewed-on: https://go-review.googlesource.com/45130
      Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      738739f5
    • Ian Lance Taylor's avatar
      runtime, syscall: reset signal handlers to default in child · df0892cb
      Ian Lance Taylor authored
      Block all signals during a fork. In the parent process, after the
      fork, restore the signal mask. In the child process, reset all
      currently handled signals to the default handler, and then restore the
      signal mask.
      
      The effect of this is that the child will be operating using the same
      signal regime as the program it is about to exec, as exec resets all
      non-ignored signals to the default, and preserves the signal mask.
      
      We do this so that in the case of a signal sent to the process group,
      the child process will not try to run a signal handler while in the
      precarious state after a fork.
      
      Fixes #18600.
      
      Change-Id: I9f39aaa3884035908d687ee323c975f349d5faaa
      Reviewed-on: https://go-review.googlesource.com/45471
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      df0892cb
    • Alan Donovan's avatar
      go/token: use fine-grained locking in FileSet · 17ba830f
      Alan Donovan authored
      Before, all accesses to the lines and infos tables of each File were
      serialized by the lock of the owning FileSet, causing parsers running
      in parallel to contend.  Now, each File has its own mutex.
      
      This fixes a data race in (*File).PositionFor, which used to call
      f.position then f.unpack without holding the mutex's lock.
      
      Fixes golang/go#18348
      
      Change-Id: Iaa5989b2eba88a7fb2e91c1a0a8bc1e7f6497f2b
      Reviewed-on: https://go-review.googlesource.com/34591Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      17ba830f
    • Brad Fitzpatrick's avatar
      doc: add more Go 1.9 notes · 76319222
      Brad Fitzpatrick authored
      Updates #20587
      
      Change-Id: I7effe922242db45f3ce74882d07511aaaac2f634
      Reviewed-on: https://go-review.googlesource.com/45613Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      76319222
    • Josh Bleecher Snyder's avatar
      runtime: speed up stack copying · aafd9640
      Josh Bleecher Snyder authored
      I was surprised to see readvarint show up in a cpu profile.
      
      Use a few simple optimizations to speed up stack copying:
      
      * Avoid making a copy of the cache.entries array or any of its elements.
      * Use a shift instead of a signed division in stackmapdata.
      * Change readvarint to return the number of bytes consumed
        rather than an updated slice.
      * Make some minor optimizations to readvarint to help the compiler.
      * Avoid called readvarint when the value fits in a single byte.
      
      The first and last optimizations are the most significant,
      although they all contribute a little.
      
      Add a benchmark for stack copying that includes lots of different
      functions in a recursive loop, to bust the cache.
      
      This might speed up other runtime operations as well;
      I only benchmarked stack copying.
      
      name                old time/op  new time/op  delta
      StackCopy-8         96.4ms ± 2%  82.7ms ± 1%  -14.24%  (p=0.000 n=20+19)
      StackCopyNoCache-8   167ms ± 1%   131ms ± 1%  -21.58%  (p=0.000 n=20+20)
      
      Change-Id: I13d5c455c65073c73b656acad86cf8e8e3c9807b
      Reviewed-on: https://go-review.googlesource.com/43150
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      aafd9640
    • Brad Fitzpatrick's avatar
      path, path/filepath: clarify and cross-reference packages · 2f7fbf88
      Brad Fitzpatrick authored
      The path package has a reference to the path/filepath package, so add
      a reverse reference.
      
      And clarify the path package doesn't do Windows paths.
      
      Fixes #20117
      
      Change-Id: I65c5ce24e600b32ea20c5821b744bd89f6aff98c
      Reviewed-on: https://go-review.googlesource.com/45653Reviewed-by: default avatarJaana Burcu Dogan <jbd@google.com>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      2f7fbf88
    • Austin Clements's avatar
      runtime: move pdesc into p · f4f01851
      Austin Clements authored
      There are currently two arrays indexed by P ID: allp and pdesc.
      Consolidate these by moving the pdesc fields into type p so they can
      be indexed off allp along with all other per-P state.
      
      For #15131.
      
      Change-Id: Ib6c4e6e7612281a1171ba4a0d62e52fd59e960b4
      Reviewed-on: https://go-review.googlesource.com/45572
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      f4f01851
    • Hiroshi Ioka's avatar
      go/printer: handle associated comments for CommentedNode · 0253299a
      Hiroshi Ioka authored
      Current CommentedNode cannot handle associated comments which satisfy
          node.End() < comment.Pos()
      
      This CL solves it.
      
      Fixes #20635
      
      Change-Id: I58e2e3703999bb38a6ce37112e986c4b1b2eace0
      Reviewed-on: https://go-review.googlesource.com/45292
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      0253299a
  2. 13 Jun, 2017 16 commits
  3. 12 Jun, 2017 6 commits
  4. 11 Jun, 2017 1 commit
  5. 09 Jun, 2017 6 commits