(See https://go-review.googlesource.com/#/c/18450)
Details:
- delete buildutil.AllowVendor flag.
Instead use unexported 'go16' var in each package that needs it.
- delete buildutil.StripVendor; was never needed.
- remove inapplicable vendoring comments from loader14.go
- importgraph: go1.5: don't bother checking for 1.6 before calling
absolutize (minor simplifiication and deoptimization).
Tested on 1.4.1, 1.5, and ~1.6 (tip).
Change-Id: If692b0df2eb6c120a9c09d7b1ed99f1b4c6b0826
Reviewed-on: https://go-review.googlesource.com/18452
Reviewed-by: Russ Cox <rsc@golang.org>
Each string in build.Package.{,Test,XTest}Imports must now be
interpreted relative to the Package.Dir. This adds a ton of
redundant I/O.
Also:
- use a counting semaphore to limit concurrent I/O calls
(Fixesgolang/go#10306)
- remove obsolete call to runtime.GOMAXPROCS from the test.
Change-Id: Ic556c4cf41cce7a88c0158800c992e66f354c484
Reviewed-on: https://go-review.googlesource.com/18050
Reviewed-by: Russ Cox <rsc@golang.org>
Rewrite performed with this command:
sed -i '' 's_code.google.com/p/go\._golang.org/x/_g' \
$(grep -lr 'code.google.com/p/go.' *)
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/170920043
Nodes in a strongly connected component (which includes most
stdlib packages) appear in results of both "forward" and
"reverse" searches from any other node in the same SCC.
LGTM=sameer
R=sameer
CC=golang-codereviews, gri
https://golang.org/cl/136470044
Refactoring tools can use this to determine an upper bound on
the set of packages potentially affected by a refactoring.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/141310043
