vet's buildtag check looks for malformed build tag comments. Since these
can appear in Go files as well as non-Go files (such as assembly files),
it must read the file line by line instead of using go/token or go/ast
directly.

However, this method runs into false positives if there are any lines in
the code that look like comments, but are not. For example:

	$ cat f.go
	package main
	const foo = `
	//+build ignore
	`
	$ go vet f.go
	./f.go:3: +build comment must appear before package clause and be followed by a blank line

This bug has been popping up more frequently since vet started being run
with go test, so it is important to make the check as precise as
possible.

To avoid the false positive, when checking a Go file, cross-check that a
line that looks like a comment actually corresponds to a comment in the
go/ast syntax tree. Since vet already obtains the syntax trees for all
the Go files, it checks, this change means very little extra work for
the check.

While at it, add a badf helper function to simplify the code that
reports warnings in the buildtag check.

Fixes #13533.

Change-Id: I484a16da01363b409ec418c313634171bf85250b
Reviewed-on: https://go-review.googlesource.com/111415
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Extend stack frame limit of 1GB to include large argument/return areas.
Argument/return areas are part of the parent frame, not the frame itself,
so they need to be handled separately.

Fixes #25507.

Change-Id: I309298a58faee3e7c1dac80bd2f1166c82460087
Reviewed-on: https://go-review.googlesource.com/115036
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change cgo to follow https://golang.org/s/generatedcode.

For the C code we continue to use /* */ comments, so they don't follow
the format exactly. It doesn't really matter since the format is only
for Go code anyhow. This CL changes the C code to be similar for
consistency.

Fixes #25623

Change-Id: Idcfee53ec4069924d173ab8cedeb7bcfb7312863
Reviewed-on: https://go-review.googlesource.com/115035
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>

Change-Id: Ie19e0354f813b042c995c0221072568eaa473bea
Reviewed-on: https://go-review.googlesource.com/114995
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: Ibdd1ca7bfc6fb2419621338f1f8e37c876ba89c0
Reviewed-on: https://go-review.googlesource.com/114976Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>

This is a simple but everyday use case in image libraries. Currently,
there is one example in this library and it is lengthy and involved.

This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.

Change-Id: Idca527d97c095af88755446e1548fa2b8ace7eb0
GitHub-Last-Rev: f5743c8ef337a8b7a5126db21d784593f4f53c8a
GitHub-Pull-Request: golang/go#25616
Reviewed-on: https://go-review.googlesource.com/114939
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I04880d87e317a1140ec12da6ec5e788991719760
Reviewed-on: https://go-review.googlesource.com/114936Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I8b462e20064658120afc8eb1cbac926254d1e24e
Reviewed-on: https://go-review.googlesource.com/114937
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #25611

Change-Id: I487463584e4d9d99cf5d8db0c9a4b4e66464ecd8
Reviewed-on: https://go-review.googlesource.com/114935
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

* Fix typos in the comments in the assembly code for the crypto package.

Change-Id: Iac146a7d8bee4a680a8d4d3af533fbc1b259482d
GitHub-Last-Rev: 65090a38956df4c14bf55df4881c76e8c3d32447
GitHub-Pull-Request: golang/go#25606
Reviewed-on: https://go-review.googlesource.com/114803Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This change uses errorCheck and wantedErrors functions copied from
the test/run.go to eliminate use of the test/errchk perl script.

Tests' error messages that contained full filenames were changed to
have base filenames because the errorCheck function processes output
from "go vet" in the same way.

Fixes #20032.

Change-Id: Ieb7be67c2d7281b9648171c698398449b7e2d4dd
Reviewed-on: https://go-review.googlesource.com/114176
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

If a span of coverable code is empty (e.g. an empty select clause)
then there will be two Boundary values with the same offset. In that
case, the starting Boundary needs to come first so that the generated
HTML output will open the <span> tag before it tries to close it.

Change-Id: Ib44a8b7c36ae57757c18b6cceb7a88ffa4e95394
Reviewed-on: https://go-review.googlesource.com/114855Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

We look for "-o /dev/null", and, if found, pretend that there was no
"-o" option and don't generate an action to create the final executable.

We look for "go build x.go", and, if found, and if -o was not used,
pretend that the user specified "-o x".

Unfortunately, we were doing those in the wrong order, so that "go
build -o /dev/null x.go" would first clear the "-o" option and then
set it to "-o x".

This CL flips the order so that the right thing happens.

Fixes #25579

Change-Id: Ic9556ac0a57f7b45b685951bc96ba5ea4633b860
Reviewed-on: https://go-review.googlesource.com/114715
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

I don't know why these files were not formatted. Perhaps because
their changes came from Github PRs?

Change-Id: Ida8d7b9a36f0d1064caf74ca1911696a247a9bbe
Reviewed-on: https://go-review.googlesource.com/114824
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

In golang.org/cl/102355 I mistakenly used 26 instead of 25 as the AT_HWCAP value.
26 is AT_HWCAP2. While experimenting with FreeBSD-11.2-BETA3 (where both values are
being supplied in the auxv), the AT_HWCAP2 value read is 0 which triggers the error again:

  runtime: this CPU has no floating point hardware, so it cannot run this GOARM=7 binary. Recompile using GOARM=5.

Updates #24507.

Change-Id: Ide04b7365d8f10e4650edf4e188dd58bdf42cc26
Reviewed-on: https://go-review.googlesource.com/114822Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This change enables bug248 to be tested with Go code.
For that, it adds a flag -1 to error check and run directory
with one package failing compilation prior the last package
which should be run.

Specifically, the "p" package in bug1.go file was renamed into "q"
to compile them in separate steps,
bug2.go and bug3.go files were reordered,
bug2.go was changed into non-main package.

Updates #25586.

Change-Id: Ie47aacd56ebb2ce4eac66c792d1a53e1e30e637c
Reviewed-on: https://go-review.googlesource.com/114818
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

go build

command is short for

go build .

and it builds . package. When command above is executed from
directory inside of GOPATH, it uses GOPATH to calculate package
source directory. So . package uses GOPATH as part of package
source directory.

On the other hand

go build -ldflags=abc

only passes flag to the linker for packages that are listed
on the command line. The command above assumes . package again,
and that package source path is compared with current directory.

Current code compares result of os.Getwd with what GOPATH
environment variable contains. But these values might differ
in letter case on Windows. For example, one might return
c:\gopath\..., while the other might contain C:\GOPATH.

Fixes #24750
Fixes #24232
Fixes #25046

Change-Id: I03d8c7a9b73e847f88ae61c88cd41efa546c6d0e
Reviewed-on: https://go-review.googlesource.com/109235
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates #6751

Change-Id: Ibb176a17e67c67f855bc4f3e5462dddaedaa8a58
Reviewed-on: https://go-review.googlesource.com/114755
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fix a problem in DWARF inline debug generation relating to handling of
statically unreachable local variables. For a function such as:

    const always = true

    func HasDeadLocal() int {
      if always {
        return 9
      }
      x := new(Something)
      ...
      return x.y
    }

the variable "x" is placed onto the Dcl list for the function during
parsing, but the actual declaration node is deleted later on when
gc.Main invokes "deadcode". Later in the compile the DWARF code emits
an abstract function with "x" (since "x" was on the Dcl list at the
point of the inline), but the export data emitted does not contain
"x". This then creates clashing/inconsistant DWARF abstract function
DIEs later on if HasDeadLocal is inlined in somewhere else.

As a fix, the inliner now pruned away variables such as "x" when
creating a copy of the Dcl list as part of the inlining; this means
that both the export data generator and the DWARF emitter wind up
seeing a consistent picture.

Fixes #25459

Change-Id: I753dc4e9f9ec694340adba5f43c907ba8cc9badc
Reviewed-on: https://go-review.googlesource.com/114090
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>

While fixing some failing tests, CL 114416 also picked up the newly
added TestXattr from golang.org/x/sys/unix which fails on android. Pick
up CL 114535 to fix it as well.

Also pick up CL 114616 to fix TestStatx occasionally failing on linux.

Change-Id: I6ebebd7761fa7a086d96ee0447dbbc5c6b94131d
Reviewed-on: https://go-review.googlesource.com/114575
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This also allows the GODEBUGCPU options to change the
support_* runtime cpu feature variable values.

Change-Id: I884c5f03993afc7e3344ff2fd471a2c6cfde43d4
Reviewed-on: https://go-review.googlesource.com/114615
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

-W and -w turn on printing of Nodes for both order and walk.
I have found their output mildly incomprehensible for years.
Improve it, at long last.

Change-Id: Ia05d77e59aa741c2dfc9fcca07f45019420b655e
Reviewed-on: https://go-review.googlesource.com/114520
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Comment changes only.

Change-Id: I3f9c1c38ae6b4989f02b62fff09265e4bcb934f7
Reviewed-on: https://go-review.googlesource.com/114519
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This file was checked in CL 103535.

Change-Id: I03e36ba36e30444c4f8e394caef9224ecd6dd728
GitHub-Last-Rev: 6b7fb62f824c5c68be800aa98cf10241b48b1cc4
GitHub-Pull-Request: golang/go#25559
Reviewed-on: https://go-review.googlesource.com/114521Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

When using gccgo/GoLLVM, there is no package file for a standard
library package. Since it is impossible for the go tool to rebuild the
package, and since the package file exists only in the form of a .gox
file, this seems like the best choice. Unfortunately it was confusing
vet, which wanted to see a real file. This caused vet to report errors
about missing package files for standard library packages. The
gccgoimporter knows how to correctly handle this case. Fix this by

1) telling vet which packages are standard;
2) letting vet skip those packages;
3) letting the gccgoimporter handle this case.

As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
so don't try to depend on it (as it happens, this fixes #25324).

The result is that the cmd/go vet tests pass when using -compiler=gccgo.

Fixes #25324

Change-Id: Iba8f948fe944da5dc674f580bd3321929ee50fa0
Reviewed-on: https://go-review.googlesource.com/113716
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I6eb182968a8e00fe359d812f1eefc9bda896395b
GitHub-Last-Rev: a354b4d2168ed4f1f1744c99c36ece276a24e046
GitHub-Pull-Request: golang/go#25540
Reviewed-on: https://go-review.googlesource.com/114318Reviewed-by: Rob Pike <r@golang.org>

Pick up the changes from CL 114395, CL 114396 and CL 114415.

By re-running govendor in the latest version, some files from
golang.org/x/sys/unix which are ignored for the build also got removed
from the vendored copy.

Updates #25528
Updates #25535

Change-Id: I5c0002fc3a37d6abaafed2e15cc3e2ade803ad7b
Reviewed-on: https://go-review.googlesource.com/114416
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

TestMutexProfile and TestEmptyCallStack couldn't run multiple times
because they mutate state in runtime (mutex profile counters and
a user-defined profile type) and test whether the state
matches what it is supposed to be after the very first run.

We fix TestMutexProfile by relaxing the expected state condition.
We fix TestEmptyCallStack by creating a new profile with a different
name every time the test runs.

For #25520

Change-Id: I8e50cd9526eb650c8989457495ff90a24ce07863
Reviewed-on: https://go-review.googlesource.com/114495
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #25546

Change-Id: I00457b370ed6dcd7ee9efcae3fd914e4c384b12c
Reviewed-on: https://go-review.googlesource.com/114475
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

This changes the http.Transport to flush the bufio.Writer between
writing the request headers and the body.

That wasn't done in the past to minimize the number of TCP packets on
the wire, but that's just an optimization, and it causes problems when
servers are waiting for the headers and the client is blocked on
something before reading the body.

Instead, only do the don't-flush optimization if we know we're not
going to block, whitelisting a set of common in-memory Request.Body
types. (the same set of types special-cased by http.NewRequest)

Fixes #22088

Change-Id: I7717750aa6df32dd3eb92d181b45bc7af24b1144
Reviewed-on: https://go-review.googlesource.com/114316
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

This reverts commit 1764609b.

Reason for revert: It breaks the dragonfly trybot, in which there are sometimes (non-deterministically) Events with the same timestamp that have to occur in a specific order.

Change-Id: I714e640c6ab5ccb23d5577e8aa98c7716ede7ad2
Reviewed-on: https://go-review.googlesource.com/114356Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This commit fixes a regression with wasm caused by a367f44c.
It adds optimizations to the lowering rules of wasm to ensure
that the lowered version of the code generated for write barriers
is simple enough so it can be processed by Liveness.markUnsafePoints.

Change-Id: Ic98f0dd3791fe1df23dcb34d2457fbde7ffce441
Reviewed-on: https://go-review.googlesource.com/114375
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Embedded interfaces in interfaces must take the form of a (possibly
qualified) type name. Before alias types, a type name always denoted
a defined (formerly "named") type. The introduction of alias types
enabled embedding of non-defined types via alias type names, as in:

type T interface { E }
type E interface { m() }

Both cmd/compile and gccgo accept this kind of code, and the spec does
not prohibit it. There may be code in the wild that makes use of this.

go/types was written under the assumption that embedded interfaces
were always defined types; and that assumption was even reflected in
the go/types API.

This change removes this restriction in the implementation (which
happens to make it simpler), and in the API (by adding additional
functions and deprecating the corresponding older versions).

It also replaces uses of NewInterface and Embedded (old API) by
NewInterface2 and EmbeddedType (new API) in dependent packages
(importers).

The old API remains in place for backward compatibility and is marked
as deprecated.

Fixes #25301.

Change-Id: I272acd498754179efaf0590ca49d3eb4eee4348e
Reviewed-on: https://go-review.googlesource.com/114317Reviewed-by: Alan Donovan <adonovan@google.com>

TestDebugCall* uses atomic spin loops and hence can deadlock if the
garbage collector is enabled (because of #10958; ironically,
implementing debugger call injection is closely related to fixing this
exact issue, but we're not there yet).

Fix this by disabling the garbage collector during these tests.

Updates #25519 (might fix it, though I suspect not)

Change-Id: If1e454b9cdea8e4b1cd82509b762c75b6acd8476
Reviewed-on: https://go-review.googlesource.com/114086
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Apparently a LoadReg can take a Phi as its argument. The Phi has names
in the NamedValue table, so just read the Load's names from the Phi.

The example given, XORKeyStream in chacha20, is pretty complicated so I
didn't try to actually debug it and verify that the results are right.
But the debug logging looks reasonable, with the right names in the right
registers at the right times.

Fixes #25404

Change-Id: I2c3183dcfb033948556d6805bd66c22c0b45625c
Reviewed-on: https://go-review.googlesource.com/114008
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

Remove the unexpected function, which is a lot less relevant now that
the generation basically can't detect invalid states, and make sure no
logging appears without -d locationlists=2.

Updates #25404

Change-Id: If3522df5a7397f2e7b43cb808936e319132132b6
Reviewed-on: https://go-review.googlesource.com/114007
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

For #23221.

Change-Id: If55dcf2e0706d6658f4a0863e3740437e008706c
Reviewed-on: https://go-review.googlesource.com/114335
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

When the internal/cpu package was introduced, the AES package still used
the custom crypto/internal/cipherhw package for amd64 and s390x. This
change removes that package entirely in favor of directly referencing the
cpu feature flags set and exposed by the internal/cpu package. In
addition, 5 new flags have been added to the internal/cpu s390x struct
for detecting various cipher message (KM) features.

Change-Id: I77cdd8bc1b04ab0e483b21bf1879b5801a4ba5f4
GitHub-Last-Rev: a611e3ecb1f480dcbfce3cb0c8c9e4058f56c1a4
GitHub-Pull-Request: golang/go#24766
Reviewed-on: https://go-review.googlesource.com/105695Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Go's SSA instructions only operate on registers. For example, an add
instruction would read two registers, do the addition and then write
to a register. WebAssembly's instructions, on the other hand, operate
on the stack. The add instruction first pops two values from the stack,
does the addition, then pushes the result to the stack. To fulfill
Go's semantics, one needs to map Go's single add instruction to
4 WebAssembly instructions:
- Push the value of local variable A to the stack
- Push the value of local variable B to the stack
- Do addition
- Write value from stack to local variable C

Now consider that B was set to the constant 42 before the addition:
- Push constant 42 to the stack
- Write value from stack to local variable B

This works, but is inefficient. Instead, the stack is used directly
by inlining instructions if possible. With inlining it becomes:
- Push the value of local variable A to the stack (add)
- Push constant 42 to the stack (constant)
- Do addition (add)
- Write value from stack to local variable C (add)

Note that the two SSA instructions can not be generated sequentially
anymore, because their WebAssembly instructions are interleaved.

Design doc: https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4

Updates #18892

Change-Id: Ie35e1c0bebf4985fddda0d6330eb2066f9ad6dec
Reviewed-on: https://go-review.googlesource.com/103535
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Update golang/go#25528
Update golang/go#25529

Change-Id: I47ec282e76eb7740547e220ac00d6a7992e17b9e
Reviewed-on: https://go-review.googlesource.com/114094Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>