1. 11 Feb, 2019 4 commits
  2. 10 Feb, 2019 1 commit
    • Daniel Martí's avatar
      doc: remove last pieces of advice to set GOROOT · e1b49ad6
      Daniel Martí authored
      install.html still insisted that GOROOT must be set if a binary install
      of Go is set up in a custom directory. However, since 1.10, this has
      been unnecessary as the GOROOT will be found based on the location of
      the 'go' binary being run.
      
      Likewise, install-source.html includes an 'export GOROOT' line in a
      section that only talks about explicitly setting GOARCH and GOOS, which
      is optional. We don't want to have users think it is recommended to set
      GOROOT here either, so remove the unnecessary line.
      
      Change-Id: I7dfef09f9a1d003e0253b793d63ea40d5cf1837f
      Reviewed-on: https://go-review.googlesource.com/c/161758Reviewed-by: default avatarAndrew Bonventre <andybons@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      e1b49ad6
  3. 09 Feb, 2019 2 commits
  4. 08 Feb, 2019 1 commit
  5. 07 Feb, 2019 3 commits
  6. 06 Feb, 2019 1 commit
  7. 05 Feb, 2019 3 commits
  8. 04 Feb, 2019 3 commits
  9. 01 Feb, 2019 4 commits
  10. 31 Jan, 2019 2 commits
  11. 30 Jan, 2019 7 commits
  12. 29 Jan, 2019 4 commits
  13. 28 Jan, 2019 2 commits
  14. 27 Jan, 2019 3 commits
    • Alex Brainman's avatar
      path/filepath: skip TestIssue29372 on windows, if /tmp has symilinks · 447965d4
      Alex Brainman authored
      TestIssue29372 is broken on windows when temporary directory has
      symlink in its path.
      
      Adjust the test to use filepath.EvalSymlinks of temporary directory,
      instead of temporary directory on windows. This change is not a
      proper fix, but at least it makes TestIssue29372 pass on windows-arm.
      
      See issue for details.
      
      Updates #29746
      
      Change-Id: I2af8ebb89da7cb9daf027a5e49e32ee22dbd0e3d
      Reviewed-on: https://go-review.googlesource.com/c/159578
      Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      447965d4
    • Keith Randall's avatar
      cmd/compile: hide init functions in tracebacks · eafe9a18
      Keith Randall authored
      Treat compiler-generated init functions as wrappers, so they will not
      be shown in tracebacks.
      
      The exception to this rule is that we'd like to show the line number
      of initializers for global variables in tracebacks. In order to
      preserve line numbers for those cases, separate out the code for those
      initializers into a separate function (which is not marked as
      autogenerated).
      
      This CL makes the go binary 0.2% bigger.
      
      Fixes #29919
      
      Change-Id: I0f1fbfc03d10d764ce3a8ddb48fb387ca8453386
      Reviewed-on: https://go-review.googlesource.com/c/159717
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      eafe9a18
    • Ian Lance Taylor's avatar
      cmd/compile: base PPC64 trunc rules on final type, not op type · d585f04f
      Ian Lance Taylor authored
      Whether a truncation should become a MOVWreg or a MOVWZreg doesn't
      depend on the type of the operand, it depends on the type of the final
      result.  If the final result is unsigned, we can use MOVWZreg.  If the
      final result is signed, we can use MOVWreg.  Checking the type of the
      operand does the wrong thing if truncating an unsigned value to a
      signed value, or vice-versa.
      
      Fixes #29943
      
      Change-Id: Ia6fc7d006486fa02cffd0bec4d910bdd5b6365f8
      Reviewed-on: https://go-review.googlesource.com/c/159760
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      d585f04f