The old version git not support "--no-show-signature", git add this from
v2.10.0.
Fixesgolang/go#26501.
Change-Id: Ia6b54488651e8687b08a4d40e092822bf960c4fe
Reviewed-on: https://go-review.googlesource.com/125315
Run-TryBot: Baokun Lee <nototon@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
"string" should really be "struct" in the structures describing the module.
Change-Id: I4e9cb12434bd33aa243622380c78e5e297d01d0b
Reviewed-on: https://go-review.googlesource.com/125638
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Rejigger the DWARF tests to ensure that they run in a reasonable
amount of time in short mode, particularly the "abstract origin
sanity" testpoints.
Updates #26470
Change-Id: Idae9763ac20ea999fa394595aacfcd1e271293ae
Reviewed-on: https://go-review.googlesource.com/125295
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
If we have go get -u x1@v1 x2@v2 and x1 depends on x2,
use v2 as the "upgraded" x2 chosen by -u instead of
letting -u pick something (say, v2.1) and then immediately
overriding it. This avoids chasing down the deps from v2.1
and also avoids them polluting the overall module graph.
This fix also lets us delete some code in the preparation step,
reducing the overall latency of get -u.
Suggested by Bryan Mills in
https://go-review.googlesource.com/c/vgo/+/122396/6#371.
Fixes#26342.
Change-Id: I50fa842304820d3f16f66a8e65dea695e2b0f88b
Reviewed-on: https://go-review.googlesource.com/124856
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If x v1.0.0 requires y v1.2.0, then
go get x@v1.0.0 y@v1.0.0 needs to fail gracefully.
Fixes#25917.
Change-Id: I9b426af23a30310fcb0c3545a8d97feb58b8ddbe
Reviewed-on: https://go-review.googlesource.com/124800
Reviewed-by: Bryan C. Mills <bcmills@google.com>
While writing the GOPROXY docs it occurred to me that versions
can contain upper-case letters as well. The docs therefore say
that versions are case-encoded the same as paths in the proxy
protocol (and therefore in the cache as well). Make it so.
Change-Id: Ibc0c4af0192a4af251e5dd6f2d36cda7e529099a
Reviewed-on: https://go-review.googlesource.com/124795
Reviewed-by: Bryan C. Mills <bcmills@google.com>
I forgot to run trybots on CL 123758, and the test failed on Windows because I
hard-coded a slash-delimited path.
Use the tent-in-a-box operator ([/\\]) to make the path platform-agnostic.
Change-Id: I9113ab60d21152c11e2ebdf822b58a44b1b38574
Reviewed-on: https://go-review.googlesource.com/125115
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The test runs far too long for -short mode (4 seconds).
Also removed useless test of now-disconnected knob
(GO_SSA_PHI_LOC_CUTOFF), which cuts 4 seconds to 2 seconds (which
is still too long), and finished removing the disconnected knob.
Updates #26469.
Change-Id: I6c594227c4a5aaffee46832049bdbbf570d86e60
Reviewed-on: https://go-review.googlesource.com/125075
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
If the the package cannot be built,
"go test" and "go vet" should not run the "vet" tool.
In that case only errors from the compilers will be displayed.
Fixes#26125
Change-Id: I5da6ba64bae5f44feaf5bd4e765eea85533cddd4
Reviewed-on: https://go-review.googlesource.com/123938
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 123577 added TestScript. The install_rebuild_gopath
test was failing on Plan 9 because it defines a GOPATH
using the ':' separator, while Plan 9 expects the '\000'
separator in environment variables.
This change fixes the script engine by defining a new
":" environment variable set to OS-specific path list
separator.
The install_rebuild_gopath test has been updated to use
"${:}" instead of ":".
Fixes#26421.
Change-Id: I58a97f882cdb48cc0836398b0d98a80ea58041ba
Reviewed-on: https://go-review.googlesource.com/124435
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It's important for a smooth transition for non-module users
not to change operation in GOPATH/src by default in Go 1.11,
even if go.mod exists in a downloaded dependency.
Even so, users create go.mod and then are confused about
why 'go get' commands seem to behave oddly, when in fact
they are getting the old 'go get'.
Try to split the difference by printing a warning in 'go get'
when run in a tree that would normally be considered a
module if only it were outside GOPATH/src.
Change-Id: I55a1cbef127f3f36de54a8d7b93e1fc64bf0a708
Reviewed-on: https://go-review.googlesource.com/124859
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If there was a mod and non-mod meta tag for a given prefix,
the meta tag extractor was already dropping the non-mod meta tag.
But we might have mod and non-mod meta tags with different
prefixes, in which case the mod tag should prevail when both match.
Fixes#26200.
Change-Id: I17ab361338e270b9fa03999ad1954f2bbe0f5017
Reviewed-on: https://go-review.googlesource.com/124714
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This was an unfortunate debugging print introduced
while working on the unfortunately large CL 123576.
At least now we're done with that awfulness.
Change-Id: Ib83db59382a799f649832d22d3c6f039d2ef9d2c
Reviewed-on: https://go-review.googlesource.com/125015
Reviewed-by: Bryan C. Mills <bcmills@google.com>
go.sum accumulates cruft as modules are added and removed as
direct and indirect dependencies. Instead of exposing all that cruft,
let "go mod -sync" clean it out.
Fixes#26381.
Change-Id: I7c9534cf7cc4579f7f82646d00ff691c87a13c4a
Reviewed-on: https://go-review.googlesource.com/124713
Reviewed-by: Bryan C. Mills <bcmills@google.com>
People are (understandably) confused by creating go.mod files in GOPATH/src
and then having the go command not use modules in those directories.
We can't change that behavior (or we'll break non-module users of GOPATH)
but we can force 'go mod' (including 'go mod -init') to fail loudly in that case.
If this is not enough, the next step would be to print a warning every time
the go command is run in a GOPATH/src directory with a go.mod but
module mode hasn't triggered. But that will annoy all the non-module users.
Hopefully anyone confused will eventually run a 'go mod' command of
some kind, which will fail loudly.
Fixes#26365.
Change-Id: I8c5fe987fbc3f8d2eceb1138e6862a391ade150c
Reviewed-on: https://go-review.googlesource.com/124708
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Also document module use of GOPATH including GOPATH/src/mod
and GOPATH/bin (unless GOBIN is set).
Fixes#26399.
Fixes#26406.
Change-Id: I7be8eaf110f4fa6fc76ea4cd39aea3dd8addf0b0
Reviewed-on: https://go-review.googlesource.com/124707
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Now pkg@none actually removes the pkg instead of dying.
For #26342.
Change-Id: I9df7281ed8fd24480109b36f33a563f92e279244
Reviewed-on: https://go-review.googlesource.com/124796
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The original pseudo-version design used versions of the form
v0.0.0-yyyymmddhhmmss-abcdef123456
These were intentionally chosen to be valid semantic versions
that sort below any explicitly-chosen semantic version (even v0.0.0),
so that they could be used before anything was tagged but after
that would essentially only be useful in replace statements
(because the max operation during MVS would always prefer
a tagged version).
Then we changed the go command to accept hashes on the
command line, so that you can say
go get github.com/my/proj@abcdef
and it will download and use v0.0.0-yyyymmddhhmmss-abcdef123456.
If you were using v1.10.1 before and this commit is just little bit
newer than that commit, calling it v0.0.0-xxx is confusing but
also harmful: the go command sees the change from v1.10.1 to
the v0.0.0 pseudoversion as a downgrade, and it downgrades other
modules in the build. In particular if some other module has
a requirement of github.com/my/proj v1.9.0 (or later), the
pseudo-version appears to be before that, so go get would
downgrade that module too. It might even remove it entirely,
if every available version needs a post-v0.0.0 version of my/proj.
This CL introduces new pseudo-version forms that can be used
to slot in after the most recent explicit tag before the commit.
If the most recent tagged commit before abcdef is v1.10.1,
then now we will use
v1.10.2-0.yyyymmddhhmmss-abcdef123456
This has the right properties for downgrades and the like,
since it is after v1.10.1 but before almost any possible
successor, such as v1.10.2, v1.10.2-1, or v1.10.2-pre.
This CL also uses those pseudo-version forms as appropriate
when mapping a hash to a pseudo-version. This fixes the
downgrade problem.
Overall, this CL reflects our growing recognition of pseudo-versions
as being like "untagged prereleases".
Issue #26150 was about documenting best practices for how
to work around this kind of accidental downgrade problem
with additional steps. Now there are no additional steps:
the problem is avoided by default.
Fixes#26150.
Change-Id: I402feeccb93e8e937bafcaa26402d88572e9b14c
Reviewed-on: https://go-review.googlesource.com/124515
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Repos written before the introduction of semantic import versioning
introduced tags like v2.0.0, v3.0.0, and so on, expecting that
(1) the import path would remain unchanged, and perhaps also
(2) there would be at most one copy of the package in a build.
We've always accommodated these by mapping them into the
v0/v1 version range, so that if you ran
go get k8s.io/client-go@v8.0.0
it would not complain about v8.x.x being a non-v1 version and
instead would map that version to a pseudo-version in go.mod:
require k8s.io/client-go v0.0.0-20180628043050-7d04d0e2a0a1
The pseudo-version fails to capture two important facts: first,
that this really is the v8.0.0 tag, and second, that it should be
preferred over any earlier v1 tags.
A related problem is that running "go get k8s.io/client-go"
with no version will choose the latest v1 tag (v1.5.1), which
is obsolete.
This CL introduces a new version suffix +incompatible that
indicates that the tag should be considered an (incompatible)
extension of the v1 version sequence instead of part of its
own major version with its own versioned module path.
The requirement above can now be written:
require k8s.io/client-go v8.0.0+incompatible
(The +metadata suffix is a standard part of semantic versioning,
and that suffix is ignored when comparing two versions for
precedence or equality. As part of canonicalizing versions
recorded in go.mod, the go command has always stripped all
such suffixes. It still strips nearly all: only +incompatible is
preserved now.)
In addition to recognizing the +incompatible, the code that
maps a commit hash to a version will use that form when
appropriate, so that
go get k8s.io/client-go@7d04d0
will choose k8s.io/client-go@v8.0.0+incompatible.
Also, the code that computes the list of available versions from
a given source code repository also maps old tags to +incompatible
versions, for any tagged commit in which a go.mod file does not exist.
Therefore
go list -m -versions k8s.io/client-go@latest
will show
k8s.io/client-go v1.4.0 v1.5.0 v1.5.1 v2.0.0-alpha.0+incompatible ... v8.0.0+incompatible
and similarly
go get k8s.io/client-go
will now choose v8.0.0+incompatible as the meaning of "latest tagged version".
The extraction of +incompatible versions from source code repos
depends on a codehost.Repo method ReadFileRevs, to do a bulk read
of multiple revisions of a file. That method is only implemented for git in this CL.
Future CLs will need to add support for that method to the other repository
implementations.
Documentation for this change is in CL 124515.
Fixes#26238.
Change-Id: I5bb1d7a46b5fffde34a3c0e6f8d19d9608188cea
Reviewed-on: https://go-review.googlesource.com/124384
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Windows networking doesn't work without this environment variable (#25210).
Re-enable TestScript on Windows, and fix two minor failures.
Fixes#26457.
Change-Id: Id9bea49dfb58403195c29c3d831a532ef0f9a233
Reviewed-on: https://go-review.googlesource.com/124858
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Until we figure out how to deal with gdb on Darwin (doesn't
read compressed DWARF from binaries), avoid compressing
DWARF in that case so that the test will still yield meaningful
results.
This is also reported to be a problem for Windows.
Problem also exists for lldb, but this test doesn't check
lldb.
Updates #25925
Change-Id: I85c0e5db75f3329957290500626a3ac7f078f608
Reviewed-on: https://go-review.googlesource.com/124712
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Pointed out in CL 122396.
An empty prefix has already been handled above.
Change-Id: Ib94df0a9c8c0517f932b90126232111caa9ad289
Reviewed-on: https://go-review.googlesource.com/124797
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If one tries to use promoted fields in a struct literal, the compiler
errors correctly. However, if the embedded fields are of struct pointer
type, the field.Type.Sym.Name expression below panics.
This is because field.Type.Sym is nil in that case. We can simply use
field.Sym.Name in this piece of code though, as it only concerns
embedded fields, in which case what we are after is the field name.
Added a test mirroring fixedbugs/issue23609.go, but with pointer types.
Fixes#26416.
Change-Id: Ia46ce62995c9e1653f315accb99d592aff2f285e
Reviewed-on: https://go-review.googlesource.com/124395
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The arm64 backend generates "TST" for "if uint32(a)&uint32(b) == 0",
which should be "TSTW".
fixes#26438
Change-Id: I7d64c30e3a840b43486bcd10eea2e3e75aaa4857
Reviewed-on: https://go-review.googlesource.com/124637
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In CLs 122575 and 123177 the cgo tool started explicitly looking up
typedefs. When there are two Go files using import "C", and the first
one has an incomplete typedef and the second one has a complete
version of the same typedef, then we will now record a version of the
first typedef which will not match the recorded version of the second
typedef, producing an "inconsistent definitions" error. Fix this by
silently merging incomplete typedefs with complete ones.
Fixes#26430
Change-Id: I9e629228783b866dd29b5c3a31acd48f6e410a2d
Reviewed-on: https://go-review.googlesource.com/124575
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
It worked once. It needs to keep working.
Change-Id: Iaa43726e1c78f0c4a20b5805c7c2bfa76fab2489
Reviewed-on: https://go-review.googlesource.com/124383
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
We need an easy way to remove $GOPATH/src/mod,
especially since all the directories are marked read-only.
Change-Id: Ib9e8e47e50048f55ecc4de0229b06c4a416ac114
Reviewed-on: https://go-review.googlesource.com/124382
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The top-level directory in a module was marked unwritable
but not the subdirectories. Fix that.
Change-Id: Ia57e5343624753851d9fe1ddfe496b870b67f924
Reviewed-on: https://go-review.googlesource.com/124381
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Within the zip file for a given module, disallow names that are invalid
on various operating systems (mostly Windows), and disallow
having two different paths that are case-fold-equivalent.
Disallowing different case-fold-equivalent paths means the
zip file content is safe for case-insensitive file systems.
There is more we could do to relax the rules later, but I think
this should be enough to avoid digging a hole in the early days
of modules that's hard to climb out of later.
In tests on my repo test corpus, the repos now rejected are:
github.com/vjeantet/goldap v0.0.0-20160521203625-ea702ca12a40
"doc/RFC 4511 - LDAP: The Protocol.txt": invalid char ':'
github.com/ChimeraCoder/anaconda v0.0.0-20160509014622-91bfbf5de08d
"json/statuses/show.json?id=404409873170841600": invalid char '?'
github.com/bmatcuk/doublestar
"test/a☺b": invalid char '☺'
github.com/kubernetes-incubator/service-catalog v0.1.10
"cmd/svcat/testdata/responses/clusterserviceclasses?fieldSelector=spec.externalName=user-provided-service.json": invalid char '?'
The : and ? are reserved on Windows,
and the : is half-reserved (and quite confusing) on macOS.
The ☺ is perhaps an overreach, but I am not convinced
that allowing all of category So is safe; certainly Sk is not.
Change-Id: I83b6ac47ce6c442f726f1036bccccdb15553c0af
Reviewed-on: https://go-review.googlesource.com/124380
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Over time there may exist two modules with names that differ only in case.
On systems with case-insensitive file systems, we need to make sure those
modules do not collide in the download cache.
Do this by using the new "safe encoding" for file system paths as well as
proxy paths.
Fixes#25992.
Change-Id: I717a9987a87ad5c6927d063bf30d10d9229498c9
Reviewed-on: https://go-review.googlesource.com/124379
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Module paths, like import paths, are case-sensitive, for better or worse.
But not all file systems distinguish file paths with different cases.
If we are going to use module paths to construct file system paths,
we must apply an encoding that distinguishes case without relying
upon the file system to do it.
This CL defines that encoding, the "safe module path encoding".
Module paths today are ASCII-only with limited punctuation,
so the safe module path encoding is to convert the whole path
to lower case and insert an ! before every formerly upper-case letter:
github.com/Sirupsen/logrus is stored as github.com/!sirupsen/logrus.
Although this CL defines the encoding, it does not change the rest
of the go command to use the encoding. That will be done in
follow-up CLs.
Change-Id: I06e6188dcfcbbc1d88674f7c95e1cb45cb476238
Reviewed-on: https://go-review.googlesource.com/124378
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Git timestamp parsing is broken when fetching modules if the
local git configuration has 'log.showsignature=true'.
Fixes#26388
Change-Id: I47f92381784072335a2a465de56092106c616108
GitHub-Last-Rev: 96f988c0a2
GitHub-Pull-Request: golang/go#26389
Reviewed-on: https://go-review.googlesource.com/123958
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In Android's NDK16, jobject is now declared as:
#ifdef __cplusplus
class _jobject {};
typedef _jobject* jobject;
#else /* not __cplusplus */
typedef void* jobject;
#endif
This makes the jobject to uintptr check fail because it expects the
following definition:
struct _jobject;
typedef struct _jobject *jobject;
Update the type check to handle that new type definition in both C and
C++ modes.
Fixes#26213
Change-Id: Ic36d4a5176526998d2d5e4e404f8943961141f7a
GitHub-Last-Rev: 42037c3c58
GitHub-Pull-Request: golang/go#26221
Reviewed-on: https://go-review.googlesource.com/122217
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Autos must be kept if their address reaches the control value of a
block. We didn't see this before because it is rare for an auto's
address to reach a control value without also reaching a phi or
being written to memory. We can probably optimize away the
comparisons that lead to this scenario since autos cannot alias
with pointers from elsewhere, however for now we take the
conservative approach and just ensure the auto is properly
initialised if its address reaches a control value.
Fixes#26407.
Change-Id: I02265793f010a9e001c3e1a5397c290c6769d4de
Reviewed-on: https://go-review.googlesource.com/124335
Reviewed-by: David Chase <drchase@google.com>
The original cmd/go tests were tiny shell scripts
written against a library of shell functions.
They were okay to write but difficult to run:
you couldn't select individual tests (with -run)
they didn't run on Windows, they were slow, and so on.
CL 10464 introduced go_test.go's testgo framework
and later CLs translated the test shell script over to
individual go tests. This let us run tests selectively,
run tests on Windows, run tests in parallel, isolate
different tests, and so on. It was a big advance.
The tests had always been awkward to write.
Here was the first test in test.bash:
TEST 'file:line in error messages'
# Test that error messages have file:line information at beginning of
# the line. Also test issue 4917: that the error is on stderr.
d=$(TMPDIR=/var/tmp mktemp -d -t testgoXXX)
fn=$d/err.go
echo "package main" > $fn
echo 'import "bar"' >> $fn
./testgo run $fn 2>$d/err.out || true
if ! grep -q "^$fn:" $d/err.out; then
echo "missing file:line in error message"
cat $d/err.out
ok=false
fi
rm -r $d
The final Go version of this test was:
func TestFileLineInErrorMessages(t *testing.T) {
tg := testgo(t)
defer tg.cleanup()
tg.parallel()
tg.tempFile("err.go", `package main; import "bar"`)
path := tg.path("err.go")
tg.runFail("run", path)
shortPath := path
if rel, err := filepath.Rel(tg.pwd(), path); err == nil && len(rel) < len(path) {
shortPath = rel
}
tg.grepStderr("^"+regexp.QuoteMeta(shortPath)+":", "missing file:line in error message")
}
It's better but still quite difficult to skim.
This CL introduces a new facility meant as a successor to the testgo
approach that brings back the style of writing tests as little scripts,
but they are now scripts in a built-for-purpose shell-like language,
not bash itself. In this new form, the test above is a single file,
testdata/script/fileline.txt:
# look for short, relative file:line in error message
! go run ../../gopath/x/y/z/err.go
stderr ^..[\\/]x[\\/]y[\\/]z[\\/]err.go:
-- ../x/y/z/err.go --
package main; import "bar"
The file is a txtar text archive (see CL 123359) in which the leading comment
is the test script and the files are the initial state of the temporary file
system where the script runs.
Each script runs as a subtest, so that they can still be selected individually.
The scripts are kept isolated from each other by default,
so all script subtests are treated as parallel tests, for the
testing package to run in parallel. Even for the 15 tests in
this CL, that cuts the time for TestScript from 5.5s to 2.5s.
The scripts do not have access to the cmd/go source directory,
nor to cmd/go/testdata, so they are prevented from creating temporary
files in those places or modifying existing ones. (Many existing tests
scribble in testdata, unfortunately, especially testdata/pkg when
they run builds with GOPATH=testdata.)
This CL introduces the script facility and converts 15 tests.
The txtar archive form will allow us to delete the large trees of trivial
files in testdata; a few are deleted in this CL.
See testdata/script/README for details and a larger conversion example.
As part of converting testdata/script/test_badtest.txt,
I discovered that 'go test' was incorrectly printing a FAIL line
to stderr (not stdout) in one corner case. This CL fixes that
to keep the test passing.
Future CLs will convert more tests.
Change-Id: I11aa9e18dd2d4c7dcd8e310dbdc6a1ea5f7e54c1
Reviewed-on: https://go-review.googlesource.com/123577
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The vet action assumes that a.Deps[0] is the compilation action for
which vet information should be generated. However, when using
-linkshared, the action graph is built with a ModeBuggyInstall action
to install the shared library built from the compilation action.
Adjust the set up of the vet action accordingly. Also don't clean up
the working directory after completing the buggy install.
Updates #26400
Change-Id: Ia51f9f6b8cde5614a6f2e41b6207478951547770
Reviewed-on: https://go-review.googlesource.com/124275
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Docker sets $HOME to / when running with a UID that doesn't exist within
the container. This not uncommon on CI servers.
Fixes#26280
Change-Id: Ic7ff62b41403fe6e7c0cef12814667ef73f6c954
Reviewed-on: https://go-review.googlesource.com/122487
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
