1. 11 Sep, 2019 17 commits
    • Aofei Sheng's avatar
      cmd/go/internal/modconv: use modules to examine instead of using only direct source control entries · 04867cd8
      Aofei Sheng authored
      Since modules now support parsing multiple forms of versions (including
      commit hash and source control tag), I think modconv.ConvertLegacyConfig
      no longer needs modfetch.ImportRepoRev. So I suggest that we use modules
      to convert legacy config instead of using VCS directly. By doing this,
      we can make the module proxy participate in the conversion process and
      benefit from it (such as speeding up "go mod init" or breaking through
      the firewall).
      
      And since modconv.ConvertLegacyConfig is the only caller of
      modfetch.ImportRepoRev, I think modfetch.ImportRepoRev can be removed.
      
      Fixes #33767
      
      Change-Id: Ic79b14fa805ed297ca1735a8498cfed2a5ddeec2
      Reviewed-on: https://go-review.googlesource.com/c/go/+/191218
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      04867cd8
    • William Poussier's avatar
      encoding/json: encode nil encoding.TextMarshaler instance as "null" · cc39d808
      William Poussier authored
      Fixes #34235.
      
      Change-Id: Ia3795fd18860530fa6a4b171545f525e784ffdcb
      GitHub-Last-Rev: 1a319c452857818f7aaf22ef46823b43ca9b2276
      GitHub-Pull-Request: golang/go#34238
      Reviewed-on: https://go-review.googlesource.com/c/go/+/194642Reviewed-by: default avatarDaniel Martí <mvdan@mvdan.cc>
      Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      cc39d808
    • Joel Sing's avatar
      cmd/internal/obj/riscv: fix up instruction groupings · 85c60bd0
      Joel Sing authored
      Some of the instructions were incorrectly grouped - untangle this and
      separate the RV64I instructions, which are under separate sections of
      the RISC-V specification.
      
      Change-Id: I232962ab4054bf0b4745887506f51e74ea73f73d
      Reviewed-on: https://go-review.googlesource.com/c/go/+/194238Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      85c60bd0
    • Bryan C. Mills's avatar
      cmd/go/internal/modload: propagate errors from Query for missing imports · 6f1667ea
      Bryan C. Mills authored
      Updates #30748
      Updates #28459
      
      Change-Id: I1c34b3dae0bf9361dba0dae66bb868901ecafe29
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189780
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      6f1667ea
    • Bryan C. Mills's avatar
      cmd/go/internal/get: propagate server errors if no go-import tags are found · 2a4c0afe
      Bryan C. Mills authored
      Updates #30748
      
      Change-Id: Ic93c68c1c4b2728f383edfdb06371ecc79a6f7b1
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189779
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      2a4c0afe
    • Bryan C. Mills's avatar
      cmd/go/internal/get: propagate parse errors in parseMetaGoImports · 95e1ea45
      Bryan C. Mills authored
      The signature of parseMetaGoImports implies that it can return an error,
      but it has not done so since CL 119675. Restore the missing error check,
      and remove the named return-values to avoid reintroducing this bug in the
      future.
      
      Updates #30748
      Updates #21291
      
      Change-Id: Iab19ade5b1c23c282f3c385a55ed277465526515
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189778
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      95e1ea45
    • Bryan C. Mills's avatar
      cmd/go/internal/get: make the implementation of charsetReader match its comment · 8fb9fa36
      Bryan C. Mills authored
      The doc comment for charsetReader claims that it supports UTF-8,
      but in practice it does not: instead, it is never invoked for UTF-8.
      
      We could update the comment to clarify that fact, but it seems simpler
      to change the implementation to match the comment.
      
      Change-Id: I39b11395ccef3feff96480b9294e8f2a232728dd
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189777
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      8fb9fa36
    • Bryan C. Mills's avatar
      cmd/go/internal/web: log complete URLs · 51be44bf
      Bryan C. Mills authored
      Incoming URLs may omit the scheme to indicate “either HTTP or HTTPS”.
      For such URLs, log the scheme actually used instead of leaving it out.
      
      (This issue was noticed while triaging #34075.)
      
      Updates #34075
      
      Change-Id: I39e5ca83543dd780258d41d5c2c4ba907cd20e5c
      Reviewed-on: https://go-review.googlesource.com/c/go/+/193262
      Run-TryBot: Bryan C. Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      51be44bf
    • fanzha02's avatar
      cmd/go/internal/work: use pie link mode when using MSAN on arm64 · 23f73986
      fanzha02 authored
      Currently, when running the "CC=clang go run -msan misc/cgo/
      testsanitizers/testdata/msan.go" command on arm64, it will
      report an error and the error is reported by llvm/compiler-rt/
      lib/msan and it is "Make sure to compile with -fPIE and to link
      with -pie".
      
      This CL fixes this issue, using PIE link mode when using MSAN
      on arm64.
      
      This CL also updates the related document and go build help message.
      
      Fixes #33712
      
      Change-Id: I0cc9d95f3fa264d6c042c27a40ccbb82826922fb
      Reviewed-on: https://go-review.googlesource.com/c/go/+/190482
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      23f73986
    • Bryan C. Mills's avatar
      cmd/go/internal/modfetch/codehost: treat nonexistent repositories as “not found” · f6c691e0
      Bryan C. Mills authored
      If a go-import directive refers to a nonexistent repository, today we
      treat that as an error fetching a module that actually exists.
      That makes the HTTP server responsible for determining which
      repositories do or do not exist, which may in general depend on
      the user's separately-stored credentials, and imposes significant
      complexity on such a server, which can otherwise be very simple.
      
      Instead, check the repository URL and/or error message to try to
      determine whether the repository exists at all. If the repo does not
      exist, treat its absence as a “not found” error — as if the server had
      not returned it in the first place.
      
      Updates #34094
      
      Change-Id: I142619ff43b96d0de428cdd0b01cca828c9ba234
      Reviewed-on: https://go-review.googlesource.com/c/go/+/194561Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      f6c691e0
    • Lucas Bremgartner's avatar
      encoding/json: fix and optimize marshal for quoted string · 0e015e20
      Lucas Bremgartner authored
      Since Go 1.2 every string can be marshaled to JSON without error even if it
      contains invalid UTF-8 byte sequences. Therefore there is no need to use
      Marshal again for the only reason of enclosing the string in double quotes.
      Not using Marshal here also removes the error check as there has not been a
      way for Marshal to fail anyway.
      
      name          old time/op    new time/op    delta
      Issue34127-4     360ns ± 3%     200ns ± 3%  -44.56%  (p=0.008 n=5+5)
      
      name          old alloc/op   new alloc/op   delta
      Issue34127-4     56.0B ± 0%     40.0B ± 0%  -28.57%  (p=0.008 n=5+5)
      
      name          old allocs/op  new allocs/op  delta
      Issue34127-4      3.00 ± 0%      2.00 ± 0%  -33.33%  (p=0.008 n=5+5)
      
      Fixes #34154
      
      Change-Id: Ib60dc11980f9b20d8bef2982de7168943d632263
      GitHub-Last-Rev: 9b0ac1d4c5318b6bf9ed7930320f2bd755f9939c
      GitHub-Pull-Request: golang/go#34127
      Reviewed-on: https://go-review.googlesource.com/c/go/+/193604Reviewed-by: default avatarDaniel Martí <mvdan@mvdan.cc>
      Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      0e015e20
    • Ruixin(Peter) Bao's avatar
      cmd/compile/internal/s390x: replace 4-byte NOP with a 2-byte NOP on s390x · 11c2411c
      Ruixin(Peter) Bao authored
      Added a new instruction, NOPH, with the encoding [0x0700](i.e: bcr 0, 0) and
      replace the current 4-byte nop that was encoded using the WORD instruction.
      
      This reduces the size of .text section in go binary by around 17KB and make
      generated code easier to read.
      
      Change-Id: I6a756df39e93c4415ea6d038ba4af001b8ccb286
      Reviewed-on: https://go-review.googlesource.com/c/go/+/194344Reviewed-by: default avatarMichael Munday <mike.munday@ibm.com>
      Run-TryBot: Michael Munday <mike.munday@ibm.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      11c2411c
    • Howard Zhang's avatar
      syscall: implement rawVforkSyscall for linux/arm64 · b25ec50b
      Howard Zhang authored
      This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing
      "fork/exec ...: cannot allocate memory" failures from occuring when attempting
      to execute commands from a Go process that has a large memory footprint.
      Additionally, this should reduce the latency of fork/exec on linux/arm64.
      
      With CLONE_VM the child process shares the same memory with the parent
      process. On its own this would lead to conflicting use of the same
      memory, so CLONE_VFORK is used to suspend the parent process until the
      child releases the memory when switching to the new program binary
      via the exec syscall. When the parent process continues to run, one
      has to consider the changes to memory that the child process did,
      namely the return address of the syscall function needs to be restored
      from a register.
      
      exec.Command() callers can start in a faster manner, as child process who
      do exec commands job can be cloned faster via vfork than via fork on arm64.
      
      The same problem was addressed on linux/amd64 via issue #5838.
      
      Updates #31936
      Contributed by Howard Zhang <howard.zhang@arm.com> and Bin Lu <bin.lu@arm.com>
      
      Change-Id: Ia99d81d877f564ec60d19f17e596276836576eaf
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189418
      Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarTobias Klauser <tobias.klauser@gmail.com>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      b25ec50b
    • Yuichi Nishiwaki's avatar
      runtime: fix crash during VDSO calls on arm · 904f046e
      Yuichi Nishiwaki authored
      As discussed in #32912, a crash occurs when go runtime calls a VDSO function (say
      __vdso_clock_gettime) and a signal arrives to that thread.
      Since VDSO functions temporarily destroy the G register (R10),
      Go functions asynchronously executed in that thread (i.e. Go's signal
      handler) can try to load data from the destroyed G, which causes
      segmentation fault.
      
      To fix the issue a guard is inserted in front of sigtrampgo, so that the control escapes from
      signal handlers without touching G in case the signal occurred in the VDSO context.
      The test case included in the patch is take from discussion in a relevant thread on github:
      https://github.com/golang/go/issues/32912#issuecomment-517874531.
      This patch not only fixes the issue on AArch64 but also that on 32bit ARM.
      
      Fixes #32912
      
      Change-Id: I657472e54b7aa3c617fabc5019ce63aa4105624a
      GitHub-Last-Rev: 28ce42c4a02a060f08c1b0dd1c9a392123fd2ee9
      GitHub-Pull-Request: golang/go#34030
      Reviewed-on: https://go-review.googlesource.com/c/go/+/192937
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      904f046e
    • Sven Taute's avatar
      encoding/base32: increase performance and code reuse · 8ef6d6a8
      Sven Taute authored
      Add benchmarks for the Encode/Decode functions operating on []byte and increase decoding performance by removing the calls to strings.Map/bytes.Map and reusing the newline filtering code that is used by NewDecoder.
      Cut allocations in half for DecodeString.
      
      Comparison using the new benchmarks:
      name            old time/op    new time/op     delta
      Encode            16.7µs ± 1%     17.0µs ± 2%    +2.25%  (p=0.000 n=9+9)
      EncodeToString    21.1µs ± 1%     20.9µs ± 1%    -0.96%  (p=0.000 n=10+10)
      Decode             141µs ± 1%       54µs ± 1%   -61.51%  (p=0.000 n=10+10)
      DecodeString      81.4µs ± 0%     54.7µs ± 1%   -32.79%  (p=0.000 n=9+10)
      
      name            old speed      new speed       delta
      Encode           492MB/s ± 1%    481MB/s ± 2%    -2.19%  (p=0.000 n=9+9)
      EncodeToString   389MB/s ± 1%    392MB/s ± 1%    +0.97%  (p=0.000 n=10+10)
      Decode          93.0MB/s ± 1%  241.6MB/s ± 1%  +159.82%  (p=0.000 n=10+10)
      DecodeString     161MB/s ± 0%    240MB/s ± 1%   +48.78%  (p=0.000 n=9+10)
      
      Change-Id: Id53633514a9e14ecd0389d52114b2b8ca64370cb
      GitHub-Last-Rev: f4be3cf55caf5b89d76d14b7f32422faff39e3c3
      GitHub-Pull-Request: golang/go#30376
      Reviewed-on: https://go-review.googlesource.com/c/go/+/163598
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      8ef6d6a8
    • Huan Du's avatar
      reflect: fix panic in DeepEqual when checking a cycle · 4dc11ae2
      Huan Du authored
      Before this change, when DeepEqual checks values with cycle, it may
      panic due to stack overflow.
      
      Here is a sample to reproduce the issue.
      
          makeCycleMap := func() interface{} {
              cycleMap := map[string]interface{}{}
              cycleMap["foo"] = cycleMap
              return cycleMap
          }
      
          m1 := makeCycleMap()
          m2 := makeCycleMap()
          reflect.DeepEqual(m1, m2) // stack overflow
      
      The root cause is that DeepEqual fails to cache interface values
      in visited map, which is used to detect cycle. DeepEqual calls
      CanAddr to check whether a value should be cached or not. However,
      all values referenced by interface don't have flagAddr thus all these
      values are not cached.
      
      THe fix is to remove CanAddr calls and use underlying ptr in value
      directly. As ptr is only read-only in DeepEqual for caching, it's
      safe to do so. We don't use UnsafeAddr this time, because this method
      panics when CanAddr returns false.
      
      Fixes #33907
      
      Change-Id: I2aa88cc060a2c2192b1d34c129c0aad4bd5597e7
      Reviewed-on: https://go-review.googlesource.com/c/go/+/191940
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      4dc11ae2
    • Marko Kungla's avatar
      reflect: enhance docs for IsZero and IsValid · a5026af5
      Marko Kungla authored
      Make it clear that IsValid checks that we have valid
      reflect.Value and not the value of `v`
      
      fixes #34152
      
      Change-Id: Ib3d359eeb3a82bf733b9ed17c777fc4c143bc29c
      Reviewed-on: https://go-review.googlesource.com/c/go/+/193841Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      a5026af5
  2. 10 Sep, 2019 13 commits
  3. 09 Sep, 2019 10 commits