cp -r x/tools/cmd/vet cmd/vet without any changes.
The next change will adjust the source to use std
repo go/types and friends.
This may (temporarily) break the build; the next
commit (immediately following) will fix it. We do
it in two commits so that we can see the manual
changes.
Change-Id: Ic45dab7066f13923e21f8c61200c8c3fd447b171
Reviewed-on: https://go-review.googlesource.com/10694
Reviewed-by: Rob Pike <r@golang.org>
As of golang.org/cl/9154, running go test will override a previous
go install -a -tags=lldb std with the tag-less version of stdlib. So
we pass -tags=lldb into the relevant go test commands.
Change-Id: I1c718289d7212373a9383eff53a643f06598f5ed
Reviewed-on: https://go-review.googlesource.com/10701
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Also modifies 'dist test' to use that sharding, and removes some old
temporary stuff from dist test which are no longer required.
'dist test' now also supports running a list of tests given in
arguments, mutually exclusive with the existing -run=REGEXP flag. The
hacky fast paths for avoiding the 1 second "go list" latency are now
removed and only apply to the case where partial tests are run via
args, instead of regex. The build coordinator will use both styles
for awhile. (the statically-sharded ARM builders on scaleway will
continue to use regexps, but the dynamically-shared builders on GCE
will use the list of tests)
Updates #10029
Change-Id: I557800a54dfa6f3b5100ef4c26fe397ba5189813
Reviewed-on: https://go-review.googlesource.com/10688
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If 'go install' (with no arguments, meaning the current directory)
succeeds, remove the executable written by 'go build', if present.
This avoids leaving a stale binary behind during a sequence like:
go build
<test, mostly works, make small change>
go install
Before this CL, the current directory still has the stale binary
from 'go build'. If $PATH contains dot, running the name of
the program will find this stale binary instead of the new,
installed one.
Remove the 'go build' target during 'go install', both to clean
up the directory and to avoid accidentally running the stale binary.
Another way to view this CL is that it makes the go command
behave as if 'go install' is implemented by 'go build' followed by
moving the resulting binary to the install location.
See #9645 for discussion and objections.
Fixes#9645.
Change-Id: Ide109572f96bbb5a35be45dda17738317462a7d4
Reviewed-on: https://go-review.googlesource.com/10682
Reviewed-by: Rob Pike <r@golang.org>
We used to put a rebuilding barrier between GOPATHs, so that if
you had GOPATH=dir1:dir2 and you had "p" in dir1/src/p
and "q" in dir2/src/q, with "p" importing "q", then when you
ran 'go install p', it would see that it was working in dir1
and (since nothing from dir2 was explicitly mentioned)
would assume that everything in dir2 is up-to-date, provided
it is built at all.
This has the confusing behavior that if "q" hasn't been built ever,
then if you update sources in q and run 'go install p', the right
thing happens (q is rebuilt and then p), but after that, if you update
sources in q and run 'go install p', nothing happens: the installed
q is assumed up-to-date.
People using code conventions with multiple GOPATH entries
(for example, with commands in one place and libraries in another,
or vendoring conventions that try to avoid rewriting import paths)
run into this without realizing it and end up with incorrect build
results.
The original motivation here was to avoid rebuild standard packages
since a system-installed GOROOT might be unwritable.
The change introduced to separate GOROOT also separated
individual GOPATH entries. Later changes added a different, more
aggressive earlier shortcut for GOROOT in release settings,
so the code here is now only applying to (and confusing)
multiple GOPATH entries. Remove it.
Fixes#10509.
Change-Id: I687a3baa81eff4073b0d67f9acbc5a3ab192eda5
Reviewed-on: https://go-review.googlesource.com/9155
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The go command uses file modification times to decide when a
package is out of date: if the .a file is older than a source file,
the .a file needs to be rebuilt. This scheme breaks down when
multiple source files compile into a single .a file: if one source file
is removed but no other changes are made, there is no indication
that the .a file is out of date.
The fix is to store a value called a build ID in the package archive itself.
The build ID is a hash of the names of all source files compiled into the package.
A later go command can read the build ID out of the package archive
and compare to the build ID derived from the list of source files it now
sees in the directory. If the build IDs differ, the file list has changed,
and the package must be rebuilt.
There is a cost here: when scanning a package directory, in addition
to reading the beginning of every source file for build tags and imports,
the go command now also reads the beginning of the associated
package archive, for the build ID. This is at most a doubling in the
number of files read. On my 2012 MacBook Pro, the time for
'go list std' increases from about 0.215 seconds to about 0.23 seconds.
For executable binaries, the approach is the same except that the
build ID information is stored in a trailer at the end of the executable file.
It remains to be seen if anything objects to the trailer.
I don't expect problems except maybe on Plan 9.
Fixes#3895.
Change-Id: I21b4ebf5890c1a39e4a013eabe1ddbb5f3510c04
Reviewed-on: https://go-review.googlesource.com/9154
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Suggested during code reviews of last 15 CLs (or so).
Change-Id: If780f6eb47a7a31df133c64d5dcf0eaf04d8447b
Reviewed-on: https://go-review.googlesource.com/10675
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
stkcheck is flow-insensitive: It processes calls in PC order.
Since morestack was always the first call in a function,
it was a safe, conservative approximation to simply adjust stack
space as we went, recognizing morestack when it showed up.
Subsequent CLS will rearrange the function prologue;
morestack may no longer be the first call in a function.
Introducing flow-sensitivity to stkcheck would allow this,
and possibly allow a smaller stackguard.
It is also a high risk change and possibly expensive.
Instead, assume that all calls to morestack occur as
part of the function prologue, no matter where they
are located in the program text.
Updates #10587.
Change-Id: I4dcdd4256a980fc4bc433a68a10989ff57f7034f
Reviewed-on: https://go-review.googlesource.com/10496
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The only unreviewed change is in mparith3.go.
Change-Id: Iec0885e7688981cbaed04c152dc9b1c7032677e6
Reviewed-on: https://go-review.googlesource.com/10665
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
The build ID is an opaque token supplied by the build system.
The compiler writes it out early in the Go export metadata
(the second line), in a way that does not bother existing readers.
The intent is that the go command can use this to store information
about the sources for the generated code, so that it can detect
stale packages even in cases (like removed files) where mtimes fail.
Change-Id: Ib5082515d6cde8a07a8d4b5c69d1e8e4190cb5e1
Reviewed-on: https://go-review.googlesource.com/9153
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This one didn't get written out.
Change-Id: Iee173861fb4dc7cafa64ba5f601f4664b6e8da4e
Reviewed-on: https://go-review.googlesource.com/10681
Reviewed-by: Russ Cox <rsc@golang.org>
In particular, this avoids moving the mtime on runtime/zversion.go
forward unless the file is out of date. In turn, this makes cross compiles
that run dist multiple times coexist nicely.
(It's no longer necessary to run dist multiple times to set up cross compiles,
but people still might, and it's easy to fix regardless.)
Fixes#4749.
Change-Id: Id430525f168f106bc4b821ca74b2ca498a748f14
Reviewed-on: https://go-review.googlesource.com/9152
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was mishandling conjunctions containing negations.
Change-Id: Ife571b28416870ba2ceadbdac5ecb4670432bba1
Reviewed-on: https://go-review.googlesource.com/9151
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sending out the conversion of a single test to get comments on the
overall approach. Converting more tests will follow.
Change-Id: I4755442d08aeb6f74c46856ae406fec41cf8d5dc
Reviewed-on: https://go-review.googlesource.com/10464
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
It was an oversight (but as linux/arm64 doesn't support internal
linking and always use external linking with cgo, no harm is done.)
Change-Id: Ie5f2b445cb67a8e63d6b868e63379c68847554f9
Reviewed-on: https://go-review.googlesource.com/10636
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When go doc is invoked with a single package name argument (e.g. go doc pkgname)
it needs to find the directory of the requested package sources in GOPATH.
GOPATH might contain directories with the same name as the requested package
that do no contain any *.go files. This change makes "go doc" ignore such
directories when looking for possible package directories.
This fixes#10882
Change-Id: Ib3d4ea69a25801c34cbe7b044de9870ba12f9aa8
Reviewed-on: https://go-review.googlesource.com/10190
Reviewed-by: Rob Pike <r@golang.org>
They're each architecture-specific.
Let them share.
Reduces Prog size to 288, which is the
next smaller malloc class.
Reduces inuse_space while compiling the
rotate tests by ~3.2%.
Change-Id: Ica8ec90e466c97b569745fffff0e5acd364e55fa
Reviewed-on: https://go-review.googlesource.com/10514
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
That which cannot happen has not happened.
No immediate changes to Addr or Prog size.
Change-Id: I4cb9315f2c9f5f92eda340bfc4abb46395fa467f
Reviewed-on: https://go-review.googlesource.com/10513
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Printed and Width were unused.
Despite only removing two bytes, due to alignment, 8 bytes are saved
on 64-bit:
Before: unsafe.Sizeof(obj.Prog{}) == 304
After: unsafe.Sizeof(obj.Prog{}) == 296
The next size class below 320 (304=>19(320)) is 288. Still 8 bytes
away from that.
Change-Id: I8d1632dd40d387f7036c03c65ea4d64e9b6218c3
Reviewed-on: https://go-review.googlesource.com/10511
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
It is almost never set and Addr is large, so having the full struct
in the Prog wastes memory most of the time.
Before (on a 64-bit system):
$ sizeof -p cmd/internal/obj Addr Prog
Addr 80
Prog 376
$
After:
$ sizeof -p cmd/internal/obj Addr Prog
Addr 80
Prog 304
$
Change-Id: I491f201241f87543964a7d0f48b85830759be9d0
Reviewed-on: https://go-review.googlesource.com/10457
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Use pkgimport == nil (or not) to distinguish between
parsing .go source files where "p" exponent specifier
is not allowed and parsing .a or .o export data where
it is. Use that to control error when p-exponent is
seen.
Fixes#9036
Change-Id: I8924f09c91d4945ef3f20e80a6e544008a94a7e4
Reviewed-on: https://go-review.googlesource.com/10450
Reviewed-by: Russ Cox <rsc@golang.org>