1. 26 Feb, 2016 15 commits
    • Ian Lance Taylor's avatar
      runtime: more deflaking of TestCgoCheckBytes · 8d94b9b8
      Ian Lance Taylor authored
      Fixes #14519.
      
      Change-Id: I8f78f67a463e6467e09df90446f7ebd28789d6c9
      Reviewed-on: https://go-review.googlesource.com/19933Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      8d94b9b8
    • Derek Shockey's avatar
      misc/git: Fix non-literal period in pre-commit grep · 90fea9d0
      Derek Shockey authored
      Looks like this was intended to match a literal period to restrict
      this to `.go` files, but in POSIX grep, the unescaped period matches
      any character.
      
      Change-Id: I20e00323baa9e9631792eff5035966297665bbee
      Reviewed-on: https://go-review.googlesource.com/19880Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      90fea9d0
    • Caio Marcelo de Oliveira Filho's avatar
      cmd/go: better error for test functions with wrong signature · c2d3e112
      Caio Marcelo de Oliveira Filho authored
      Check the function types before compiling the tests. Extend the same
      approach taken by the type check used for TestMain function.
      
      To keep existing behavior, wrong arguments for TestMain are ignored
      instead of causing an error.
      
      Fixes #14226.
      
      Change-Id: I488a2555cddb273d35c1a8c4645bb5435c9eb91d
      Reviewed-on: https://go-review.googlesource.com/19763
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      c2d3e112
    • Dmitry Vyukov's avatar
      sync/atomic: reduce test in short mode · e1035c5e
      Dmitry Vyukov authored
      In normal mode the test runs for 9+ seconds on my machine (48 cores).
      But the real problem is race mode, in race mode it hits 10m test timeout.
      Reduce test size in short mode. Now it runs for 100ms without race.
      
      Change-Id: I9493a0e84f630b930af8f958e2920025df37c268
      Reviewed-on: https://go-review.googlesource.com/19956Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      e1035c5e
    • Rick Arnold's avatar
      net/url: support query string without values · 9f26170a
      Rick Arnold authored
      Previously, RawQuery was used to indicate the presence of a query
      string in url.URL. However, this approach was not able to differentiate
      between URLs that have no query string at all (http://foo.bar/) and
      those that have a query with no values (http://foo.bar/?).
      
      Add a ForceQuery field to indicate the latter form of URL and use it
      in URL.String to create a matching URL with a trailing '?'.
      
      Fixes #13488
      
      Change-Id: Ifac663c73d35759bc6c33a00f84ab116b9b81684
      Reviewed-on: https://go-review.googlesource.com/19931Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      9f26170a
    • Dmitry Vyukov's avatar
      runtime: unwire g/m in dropg always · bdc14698
      Dmitry Vyukov authored
      Currently dropg does not unwire locked g/m.
      This is unnecessary distiction between locked and non-locked g/m.
      We always restart goroutines with execute which re-wires g/m.
      
      First, this produces false sense that this distinction is necessary.
      Second, it can confuse some sanity and cross checks. For example,
      if we check that g/m are unwired before we wire them in execute,
      the check will fail for locked g/m. I've hit this while doing some
      race detector changes, When we deschedule a goroutine and run
      scheduler code, m.curg is generally nil, but not for locked ms.
      
      Remove the distinction.
      
      Change-Id: I3b87a28ff343baa1d564aab1f821b582a84dee07
      Reviewed-on: https://go-review.googlesource.com/19950Reviewed-by: default avatarAustin Clements <austin@google.com>
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      bdc14698
    • Austin Clements's avatar
      runtime: remove workbuf logging · 3b3d58e1
      Austin Clements authored
      Early in Go 1.5 we had bugs with ownership of workbufs, so we added a
      system for tracing their ownership to help debug these issues.
      However, this system has both CPU and space overhead even when
      disabled, it clutters up the workbuf API, the higher level gcWork
      abstraction makes it very difficult to mess up the ownership of
      workbufs in practice, and the tracing hasn't been enabled or needed
      since 5b66e5d0 nine months ago. Hence, remove it.
      
      Benchmarks show the usual noise from changes at this level, but little
      overall movement.
      
      name              old time/op  new time/op  delta
      XBenchGarbage-12  2.48ms ± 1%  2.47ms ± 0%  -0.68%  (p=0.000 n=21+21)
      
      name                      old time/op    new time/op    delta
      BinaryTree17-12              2.98s ± 7%     2.98s ± 6%    ~     (p=0.799 n=20+20)
      Fannkuch11-12                2.61s ± 3%     2.55s ± 5%  -2.55%  (p=0.003 n=20+20)
      FmtFprintfEmpty-12          52.8ns ± 6%    53.6ns ± 6%    ~     (p=0.228 n=20+20)
      FmtFprintfString-12          177ns ± 4%     177ns ± 4%    ~     (p=0.280 n=20+20)
      FmtFprintfInt-12             162ns ± 5%     162ns ± 3%    ~     (p=0.347 n=20+20)
      FmtFprintfIntInt-12          277ns ± 7%     273ns ± 4%  -1.62%  (p=0.005 n=20+20)
      FmtFprintfPrefixedInt-12     237ns ± 4%     242ns ± 4%  +2.13%  (p=0.005 n=20+20)
      FmtFprintfFloat-12           315ns ± 4%     312ns ± 4%  -0.97%  (p=0.001 n=20+20)
      FmtManyArgs-12              1.11µs ± 3%    1.15µs ± 4%  +3.41%  (p=0.004 n=20+20)
      GobDecode-12                8.50ms ± 7%    8.53ms ± 7%    ~     (p=0.429 n=20+20)
      GobEncode-12                6.86ms ± 9%    6.93ms ± 7%  +0.93%  (p=0.030 n=20+20)
      Gzip-12                      326ms ± 4%     329ms ± 4%  +0.98%  (p=0.020 n=20+20)
      Gunzip-12                   43.3ms ± 3%    43.8ms ± 9%  +1.25%  (p=0.003 n=20+20)
      HTTPClientServer-12         72.0µs ± 3%    71.5µs ± 3%    ~     (p=0.053 n=20+20)
      JSONEncode-12               17.0ms ± 6%    17.3ms ± 7%  +1.32%  (p=0.006 n=20+20)
      JSONDecode-12               64.2ms ± 4%    63.5ms ± 3%  -1.05%  (p=0.005 n=20+20)
      Mandelbrot200-12            4.00ms ± 3%    3.99ms ± 3%    ~     (p=0.121 n=20+20)
      GoParse-12                  3.74ms ± 5%    3.75ms ± 9%    ~     (p=0.383 n=20+20)
      RegexpMatchEasy0_32-12       104ns ± 4%     104ns ± 6%    ~     (p=0.392 n=20+20)
      RegexpMatchEasy0_1K-12       358ns ± 3%     361ns ± 4%  +0.95%  (p=0.003 n=20+20)
      RegexpMatchEasy1_32-12      86.3ns ± 5%    86.1ns ± 6%    ~     (p=0.614 n=20+20)
      RegexpMatchEasy1_1K-12       523ns ± 4%     518ns ± 3%  -1.14%  (p=0.008 n=20+20)
      RegexpMatchMedium_32-12      137ns ± 3%     134ns ± 4%  -1.90%  (p=0.005 n=20+20)
      RegexpMatchMedium_1K-12     41.0µs ± 3%    40.6µs ± 4%  -1.11%  (p=0.004 n=20+20)
      RegexpMatchHard_32-12       2.13µs ± 4%    2.11µs ± 5%  -1.31%  (p=0.014 n=20+20)
      RegexpMatchHard_1K-12       64.1µs ± 3%    63.2µs ± 5%  -1.38%  (p=0.005 n=20+20)
      Revcomp-12                   555ms ±10%     548ms ± 7%  -1.17%  (p=0.011 n=20+20)
      Template-12                 84.2ms ± 5%    88.2ms ± 4%  +4.73%  (p=0.000 n=20+20)
      TimeParse-12                 365ns ± 4%     371ns ± 5%  +1.77%  (p=0.002 n=20+20)
      TimeFormat-12                361ns ± 4%     365ns ± 3%  +1.08%  (p=0.002 n=20+20)
      [Geo mean]                  64.7µs         64.8µs       +0.19%
      
      Change-Id: Ib043a7a0d18b588b298873d60913d44cd19f3b44
      Reviewed-on: https://go-review.googlesource.com/19887
      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>
      3b3d58e1
    • David Crawshaw's avatar
      cmd/compile: remove uncommonType.name · 0231f542
      David Crawshaw authored
      Reduces binary size of cmd/go by 0.5%.
      For #6853.
      
      Change-Id: I5a4b814049580ab5098ad252d979f80b70d8a5f9
      Reviewed-on: https://go-review.googlesource.com/19694Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      0231f542
    • Datong Sun's avatar
      crypto/x509: better documentation for ParsePKIXPublicKey · c8ae2e82
      Datong Sun authored
      The existing documentation for ParsePKIXPublicKey is difficult to understand
      and the return type of the parsed public key are not mentioned explicitly.
      
      Descriptions about types of public key supported, as well as an example on
      how to use type assertions to determine return type of a parsed public key
      has been added.
      
      Fixes #14355
      
      Change-Id: Ib9561efb34255292735742c0b3e835c4b97ac589
      Reviewed-on: https://go-review.googlesource.com/19757Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      c8ae2e82
    • Matthew Dempsky's avatar
      cmd/compile, go/parser: simpler binary expression parsing · 49d1e307
      Matthew Dempsky authored
      The existing nested loops are too tricky for me to grok and don't seem
      necessary.
      
      Change-Id: I75c65c8470b799d6f4cfb05bb1b4796c5d7d32e7
      Reviewed-on: https://go-review.googlesource.com/19927
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      49d1e307
    • Shenghou Ma's avatar
      build: use go tool dist list · c8579e57
      Shenghou Ma authored
      Change-Id: I9b79bd301d0b75ca1f16d4a05e3cb687a8428c14
      Reviewed-on: https://go-review.googlesource.com/19884
      Run-TryBot: Minux Ma <minux@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      c8579e57
    • Andrew Gerrand's avatar
      doc: add issue and pull request templates · 7b74921d
      Andrew Gerrand authored
      Fixes #14365
      
      Change-Id: I082329fe7a1e06c774a32e0e24e5c8736bb5a037
      Reviewed-on: https://go-review.googlesource.com/19877Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      7b74921d
    • Matthew Dempsky's avatar
      cmd/compile: simplify error sorting · a5b7a8d6
      Matthew Dempsky authored
      Errors have unique seq values (their index within the errors slice),
      so errcmp never needs to fallback to sorting by message text.
      Moreover, comparing by original index is exactly the purpose of using
      a stable sort algorithm (and sort.Stable was added in Go 1.2), so we
      really only need to compare by lineno.
      
      Change-Id: I7f534b72a05d899ae9788dc7ef0541dd92a8b578
      Reviewed-on: https://go-review.googlesource.com/19929
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      a5b7a8d6
    • Matthew Dempsky's avatar
      cmd/compile: rationalize (lex)?lineno handling · e0fa809f
      Matthew Dempsky authored
      Previously, many error messages inconsistantly used either lexlineno
      and lineno.  In general this works out okay because they're almost
      always the same.  The only exceptional case is after lexing a
      multi-line raw string literal, where lineno will be the line number of
      the opening quote and lexlineno is the line number of the closing
      quote.
      
      This CL makes the compiler's error message more consistent:
      
      - Lexer error messages related to invalid byte sequences (i.e., NUL
      bytes, bad UTF-8 sequences, and non-initial BOMs) are emitted at
      lexlineno (i.e., the source line that contains the invalid byte
      sequence).
      
      - All other error messages (notably the parser's "syntax errors") now
      use lineno.  The minor change from this is that bogus input like:
      
          package `
          bogus`
      
      will emit "syntax error: unexpected string literal, expecting name"
      error at line 1, instead of line 2.
      
      - Instead of maintaining prevlineno all the time, just record it
      when/where actually needed and not already available elsewhere (which
      turns out to be just one function).
      
      - Lastly, we remove the legacy "syntax error near ..." fallback in
      Yerror, now that the parser always emits more detailed syntax error
      messages.
      
      Change-Id: Iaf5f784223d0385fa3a5b09ef2b2ad447feab02f
      Reviewed-on: https://go-review.googlesource.com/19925Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      e0fa809f
    • Keith Randall's avatar
      runtime: avoid using REP prefix for IndexByte · 687abca1
      Keith Randall authored
      REP-prefixed instructions have a large startup cost.
      Avoid them like the plague.
      
      benchmark                  old ns/op     new ns/op     delta
      BenchmarkIndexByte10-8     22.4          5.34          -76.16%
      
      Fixes #13983
      
      Change-Id: I857e956e240fc9681d053f2584ccf24c1b272bb3
      Reviewed-on: https://go-review.googlesource.com/18703Reviewed-by: default avatarMinux Ma <minux@golang.org>
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      687abca1
  2. 25 Feb, 2016 25 commits