Skip to content

G
golang
Switch branch/tag
  1. 09 Jan, 2018 6 commits
    • Russ Cox's avatar
      doc: s/tool chain/toolchain/ · b6c871a2
      Russ Cox authored 
      We were not being consistent.
Standardize on toolchain.

Change-Id: Id0e756b5214ce4a1341f733634ed95263f03a61c
Reviewed-on: https://go-review.googlesource.com/87017
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      b6c871a2
    • Russ Cox's avatar
      cmd/go: adjust import config debugging flag · dd806b8b
      Russ Cox authored 
      Change-Id: I3afaefc154f9ccfac353cedac7aefcfb70afe265
Reviewed-on: https://go-review.googlesource.com/86996
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      dd806b8b
    • Russ Cox's avatar
      cmd/link: set runtime.GOROOT default during link · 8396015e
      Russ Cox authored 
      Suppose you build the Go toolchain in directory A,
move the whole thing to directory B, and then use
it from B to build a new program hello.exe, and then
run hello.exe, and hello.exe crashes with a stack
trace into the standard library.

Long ago, you'd have seen hello.exe print file names
in the A directory tree, even though the files had moved
to the B directory tree. About two years ago we changed
the compiler to write down these files with the name
"$GOROOT" (that literal string) instead of A, so that the
final link from B could replace "$GOROOT" with B,
so that hello.exe's crash would show the correct source
file paths in the stack trace. (golang.org/cl/18200)

Now suppose that you do the same thing but hello.exe
doesn't crash: it prints fmt.Println(runtime.GOROOT()).
And you run hello.exe after clearing $GOROOT from the
environment.

Long ago, you'd have seen hello.exe print A instead of B.
Before this CL, you'd still see hello.exe print A instead of B.
This case is the one instance where a moved toolchain
still divulges its origin. Not anymore. After this CL, hello.exe
will print B, because the linker sets runtime/internal/sys.DefaultGoroot
with the effective GOROOT from link time.
This makes the default result of runtime.GOROOT once again
match the file names recorded in the binary, after two years
of divergence.

With that cleared up, we can reintroduce GOROOT into the
link action ID and also reenable TestExecutableGOROOT/RelocatedExe.

When $GOROOT_FINAL is set during link, it is used
in preference to $GOROOT, as always, but it was easier
to explain the behavior above without introducing that
complication.

Fixes #22155.
Fixes #20284.
Fixes #22475.

Change-Id: Ifdaeb77fd4678fdb337cf59ee25b2cd873ec1016
Reviewed-on: https://go-review.googlesource.com/86835
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      8396015e
    • Russ Cox's avatar
      cmd/link: apply -X options after loading symbols · 28639df1
      Russ Cox authored 
      The linker has been applying -X options before loading symbols,
meaning that when it sees -X y=z it creates a symbol named y
and initializes its string data to z. The symbol named y is marked
"DUPOK" so that when the actual packages are loaded, no error is
emitted when the real y is seen. The predefined y's data is used
instead of whatever the real y says.

If we define -X y=z and we never load y, then the predefined symbol
is dropped during dead code elimination, but not in shared library
builds. Shared library builds must include all symbols, so we have to
be more careful about not defining symbols that wouldn't have
appeared anyway.

To be more careful, save the -X settings until after all the symbols
are loaded from the packages, and then apply the string changes
to whatever symbols are known (but ignore the ones that were not
loaded at all). This ends up being simpler anyway, since it doesn't
depend on DUPOK magic.

Makes CL 86835 safe.

Fixes #23273.

Change-Id: Ib4c9b2d5eafa97c5a8114401dbec0134c76be54f
Reviewed-on: https://go-review.googlesource.com/86915
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      28639df1
    • Samuel Tan's avatar
      Revert "html/template: prevent aliasing of parse Trees via AddParseTree" · bf897845
      Samuel Tan authored 
      This reverts commit cd0a5f08, which
unnecessarily restricts the use of AddParseTree.

Change-Id: I1155214a20ba08981d604404e79fff54874fd8e4
Reviewed-on: https://go-review.googlesource.com/83919
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      bf897845
    • Russ Cox's avatar
      cmd/test2json: emit Benchmark name output early · 9044f018
      Russ Cox authored 
      When benchmarks run, they print lines like:

  BenchmarkGenericNoMatch-8   3000000 385 ns/op

The first field, padded by spaces and followed by a tab,
is printed when the benchmark begins running.
The rest of the line is printed when the benchmark ends.
Tools and people can watch the timing of these prints
to see which benchmark is running.

To allow tools consuming json output to continue to be
able to see which benchmark is running, this CL adds a
special case to the usual "line at a time" behavior to flush
the benchmark name if it is observed separately from the
rest of the line.

Fixes #23352.

Change-Id: I7b6410698d78034eec18745d7f57b7d8e9575dbb
Reviewed-on: https://go-review.googlesource.com/86695
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      9044f018
  3. 08 Jan, 2018 1 commit
  5. 06 Jan, 2018 5 commits
  7. 05 Jan, 2018 9 commits
    • Ian Lance Taylor's avatar
      cmd/go: add support for build IDs with gccgo · fc408b62
      Ian Lance Taylor authored 
      This just adds support on ELF systems, which is OK for now since that
is all that gccgo works on.

For the archive file generated by the compiler we add a new file
_buildid.o that has a section .go.buildid containing the build ID.
Using a new file lets us set the SHF_EXCLUDE bit in the section header,
so the linker will discard the section. It would be nicer to use
`objcopy --add-section`, but objcopy doesn't support setting the
SHF_EXCLUDE bit.

For an executable we just use an ordinary GNU build ID. Doing this
required modifying cmd/internal/buildid to look for a GNU build ID,
and use it if there is no other Go-specific note.

This CL fixes a minor bug in gccgoTOolchain.link: it was using .Target
instead of .built, so it failed for a cached file.

This CL fixes a bug reading note segments: the notes are aligned as
reported by the PT_NOTE's alignment field.

Updates #22472

Change-Id: I4d9e9978ef060bafc5b9574d9af16d97c13f3102
Reviewed-on: https://go-review.googlesource.com/85555
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      fc408b62
    • Russ Cox's avatar
      cmd/test2json: fix processing of --- BENCH: output · 65fa5318
      Russ Cox authored 
      If a benchmark calls b.Log without failing (without b.Error/b.Fatal/b.FailNow)
then that turns into output very much like a test passing,
except it says BENCH instead of PASS.
Benchmarks failing say FAIL just like tests failing.

Fixes #23346.

Change-Id: Ib188e695952da78057ab4a13f90d49937aa3c232
Reviewed-on: https://go-review.googlesource.com/86396
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      65fa5318
    • Hana Kim's avatar
      doc/debugging_with_gdb: mention delve as an alternative. · acc1ec9b
      Hana Kim authored 
      Fixes #23108

Change-Id: I9b3d0f0c399c0b4cb488adaf3c002bc55d5d21d9
Reviewed-on: https://go-review.googlesource.com/84795Reviewed-by: 's avatarHeschi Kreinick <heschi@google.com>
      acc1ec9b
    • Russ Cox's avatar
      go/constant: make string addition compute actual string lazily · 010d8948
      Russ Cox authored 
      It is natural for tools to take a large string concatenation like

	"1" + "1" + "1" + ... + "1"

and translate that into a sequence of go/constant calls:

	x := constant.MakeString("1")
	x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
	x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
	x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
	x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
	...

If the underlying representation of a string constant is a Go string,
then this leads to O(N²) memory for the concatenation of N strings,
allocating memory for "1", "11", "111", "1111", and so on.
This makes go/types and in particular cmd/vet run out of memory
(or at least use far too much) on machine-generated string concatenations,
such as those generated by go-bindata.

This CL allows code like the above to operate efficiently, by delaying
the evaluation of the actual string constant value until it is needed.
Now the representation of a string constant is either a string or an
explicit addition expression. The addition expression is turned into
a string the first time it is requested and then cached for future use.
This slows down the use of single strings, but analyses are likely not
dominated by that use anyway. It speeds up string concatenations,
especially large ones, significantly.

On my Mac running 32-bit code:

name               old time/op    new time/op    delta
StringAdd/1-8         160ns ± 2%     183ns ± 1%  +13.98%  (p=0.000 n=10+10)
StringAdd/4-8         650ns ± 1%     927ns ± 4%  +42.73%  (p=0.000 n=10+10)
StringAdd/16-8       3.93µs ± 1%    2.78µs ± 2%  -29.12%  (p=0.000 n=8+9)
StringAdd/64-8       37.3µs ± 9%    10.1µs ± 5%  -73.06%  (p=0.000 n=10+10)
StringAdd/256-8       513µs ± 5%      38µs ± 1%  -92.63%  (p=0.000 n=10+10)
StringAdd/1024-8     5.67ms ± 4%    0.14ms ± 2%  -97.45%  (p=0.000 n=8+10)
StringAdd/4096-8     77.1ms ± 9%     0.7ms ± 2%  -99.10%  (p=0.000 n=10+9)
StringAdd/16384-8     1.33s ± 7%     0.00s ±10%  -99.64%  (p=0.000 n=10+10)
StringAdd/65536-8     21.5s ± 4%      0.0s ± 8%  -99.89%  (p=0.000 n=10+10)

name               old alloc/op   new alloc/op   delta
StringAdd/1-8          232B ± 0%      256B ± 0%  +10.34%  (p=0.000 n=10+10)
StringAdd/4-8        1.20kB ± 0%    1.24kB ± 0%   +3.33%  (p=0.000 n=10+10)
StringAdd/16-8       14.7kB ± 0%     4.6kB ± 0%  -68.87%  (p=0.000 n=10+10)
StringAdd/64-8        223kB ± 0%      16kB ± 0%  -92.66%  (p=0.000 n=10+10)
StringAdd/256-8      3.48MB ± 0%    0.07MB ± 0%  -98.07%  (p=0.000 n=10+10)
StringAdd/1024-8     55.7MB ± 0%     0.3MB ± 0%  -99.53%  (p=0.000 n=10+10)
StringAdd/4096-8      855MB ± 0%       1MB ± 0%  -99.88%  (p=0.000 n=10+10)
StringAdd/16384-8    13.5GB ± 0%     0.0GB ± 0%  -99.97%  (p=0.000 n=9+10)
StringAdd/65536-8     215GB ± 0%       0GB ± 0%  -99.99%  (p=0.000 n=10+10)

name               old allocs/op  new allocs/op  delta
StringAdd/1-8          3.00 ± 0%      3.00 ± 0%     ~     (all equal)
StringAdd/4-8          9.00 ± 0%     11.00 ± 0%  +22.22%  (p=0.000 n=10+10)
StringAdd/16-8         33.0 ± 0%      25.0 ± 0%  -24.24%  (p=0.000 n=10+10)
StringAdd/64-8          129 ± 0%        75 ± 0%  -41.86%  (p=0.000 n=10+10)
StringAdd/256-8         513 ± 0%       269 ± 0%  -47.56%  (p=0.000 n=10+10)
StringAdd/1024-8      2.05k ± 0%     1.04k ± 0%  -49.29%  (p=0.000 n=10+10)
StringAdd/4096-8      8.19k ± 0%     4.12k ± 0%  -49.77%  (p=0.000 n=10+10)
StringAdd/16384-8     32.8k ± 0%     16.4k ± 0%  -49.97%  (p=0.000 n=9+10)
StringAdd/65536-8      131k ± 0%       66k ± 0%  -50.11%  (p=0.000 n=10+10)

https://perf.golang.org/search?q=upload:20180105.2

Fixes #23348 (originally reported as cmd/vet failures in comments on #23222).

This makes constant.Values of Kind String no longer meaningful for ==, which
required fixes in go/types. While there, also fix go/types handling of constant.Values
of Kind Int (for uint64), Float, and Complex.

Change-Id: I80867bc9c4232c5c9b213443ff16645434a68b36
Reviewed-on: https://go-review.googlesource.com/86395
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      010d8948
    • Russ Cox's avatar
      cmd/go: skip long tests in -short mode · 26222ddc
      Russ Cox authored 
      I marked every test that takes more than 0.5 seconds on my machine
as something to run only when not in -short mode, or in -short mode
on the beefy linux/amd64, windows/amd64, and darwin/amd64 builders.

I also shortened a few needlessly-expensive tests where possible.

Cuts the time for go test -short cmd/go from 45s to 15s on my machine.
Should help even more on some of our builders and slower user machines.

Fixes #23287.

Change-Id: I0e36003ef947b0ebe4224a1373731f9fa9216843
Reviewed-on: https://go-review.googlesource.com/86252
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      26222ddc
    • Brad Fitzpatrick's avatar
      net/http: document internal error errServerClosedIdle more · fcdcb194
      Brad Fitzpatrick authored 
      Updates #19943

Change-Id: Iea249be51a7af3264bee9ee2b28dbd91043275fc
Reviewed-on: https://go-review.googlesource.com/86375Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      fcdcb194
    • Brad Fitzpatrick's avatar
      net/http: don't validate WriteHeader code if header's already been sent · 596e3d9c
      Brad Fitzpatrick authored 
      Also vendors x/net/http git rev 42fe2e1c for:

    http2: don't check WriteHeader status if we've already sent the header
    https://golang.org/cl/86255

Fixes #23010

Change-Id: I4f3dd63acb52d5a34a0350aaf847a7a376d6968f
Reviewed-on: https://go-review.googlesource.com/86275Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      596e3d9c
    • Brad Fitzpatrick's avatar
      net/http: document CONNECT more · 301714d8
      Brad Fitzpatrick authored 
      Fixes #22554

Change-Id: I624f2883489a46d7162c11f489c2f0a0ec5a836f
Reviewed-on: https://go-review.googlesource.com/86277Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      301714d8
    • Brad Fitzpatrick's avatar
      net/http: soften wording around when the Transport reuses connections · 3639929d
      Brad Fitzpatrick authored 
      The docs were too specific. Make it vaguer. There are conditions for
which the Transport will try to reuse a connection anyway, even if the
Response Body isn't read to EOF or closed, but we don't need to get
into all the details in the docs.

Fixes #22954

Change-Id: I3b8ae32aeb1a61b396d0026e129552afbfecceec
Reviewed-on: https://go-review.googlesource.com/86276Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      3639929d
  9. 04 Jan, 2018 15 commits
  11. 03 Jan, 2018 4 commits