If a single module is imported via two different paths (e.g., as itself and as a
replacement for something else), some users may be surprised if the two paths
do not share the same package-level state. Others may be surprised if the two
paths do share state.
Punt on the question for now by rejecting that condition explicitly.
Fixes#26607.
Change-Id: I15c3889f61f8dd4ba5e5c48ca33ad63aeecac04e
Reviewed-on: https://go-review.googlesource.com/126156
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
doImport is itself a thin wrapper around Import, and doPkg is its only call
site. I'm having trouble following what doPkg is doing due to the indirection,
so I'm removing it.
Change-Id: I6167be68e869a36010a56a5869df50b1145ac813
Reviewed-on: https://go-review.googlesource.com/125837
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
We can add unversioned paths via -replace;
-dropreplace must be able to drop them.
Fixes#26417.
Change-Id: Ic05e9ae2ad80c008e11b195695cbb9d0fc8dbc0a
Reviewed-on: https://go-review.googlesource.com/126155
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Previously go list -test <pkg> would return pkg and, if it exists,
pkg.test, the test main package. This change will also list the
two test code packages (if they exist) that contain testing functions,
<pkg> [<pkg>.test] and <pkg>_test [<pkg>.test].
These packages which contain testing code are usually the packages
go list users desire to know about, so they should be surfaced
in go list -test.
See the discussion at
golang.org/cl/123635#message-5befbc66663063fb7247645a02ab1327a681e362
for more context.
Change-Id: I7170b539d02b548c050ac54048735ed785f47389
Reviewed-on: https://go-review.googlesource.com/126475
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
"LDP (R0), (F0, F1)" and "STP (F1, F2), (R0)" are
silently accepted by the arm64 assembler without
any error message. And this CL fixes that bug.
fixes#26556.
Change-Id: Ib6fae81956deb39a4ffd95e9409acc8dad3ab2d2
Reviewed-on: https://go-review.googlesource.com/125637
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 125296 added TestScript/mod_gobuild_import. This
test is failing on Plan 9, because go/build invokes
the go tool which cannot be found in the path.
The "PATH" environment variable has been updated to
contain the path to the go tool on Unix and Windows,
but on Plan 9, the analogous environment variable is
called "path".
This change fixes the script engine by setting
the "path" environment variable on Plan 9.
Fixes#26669.
Change-Id: If1be50e14baceccee591f4f76b7e698f5e12a2d4
Reviewed-on: https://go-review.googlesource.com/126608
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The test TestACL failed when ran on a Windows set
up in another language as the "Guest" account
name is translated. The SID of the group of Guests
always exist and is used instead.
Fixes#26658
Change-Id: Ia885d08a9e50563787e389c2d2dc2547881a2943
Reviewed-on: https://go-review.googlesource.com/126598
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This will help with forward compatibility when we add additional
directives that only matter for the main module (or that can be
safely ignored otherwise).
Change-Id: Ida1e186fb2669b128aeb5a9a1187e2535b72b763
Reviewed-on: https://go-review.googlesource.com/125936
Reviewed-by: Bryan C. Mills <bcmills@google.com>
We're starting to see tutorials that assume
'go mod' is the only module-related command.
Fixes#26597.
Change-Id: I44701f29f89fc67086f96307afbdb4659bb63873
Reviewed-on: https://go-review.googlesource.com/125935
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The mod -graph output was showing every dependency
as an edge from the main module, instead of showing only
the things that are listed in go.mod.
Fixes#26489.
Change-Id: I248fedb1fc9225e2a7a9ddc2f4a84520b3a96138
Reviewed-on: https://go-review.googlesource.com/125657
Reviewed-by: Bryan C. Mills <bcmills@google.com>
"go env GOMOD" gives this for the main module already
but it's useful to be able to query other modules.
Using {{.Dir}} does not work if the go.mod was auto-synthesized.
Change-Id: If4844571e9e429b541de0d40c36ff4c5743b2031
Reviewed-on: https://go-review.googlesource.com/125656
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Suggested in discussion on #26366.
Change-Id: Id9ad2e429a915f88b4c4b30fc415c722eebe0ea4
Reviewed-on: https://go-review.googlesource.com/125297
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The introduction of modules has broken (intentionally) the rule
that the source code for a package x/y/z is in GOPATH/src/x/y/z
(or GOROOT/src/x/y/z). This breaks the code in go/build.Import,
which uses that rule to find the directory for a package.
In the long term, the fix is to move programs that load packages
off of go/build and onto golang.org/x/tools/go/packages, which
we hope will eventually become go/packages. That code invokes
the go command to learn what it needs to know about where
packages are.
In the short term, though, there are lots of programs that use go/build
and will not be able to find code in module dependencies.
To help those programs, go/build now runs the go command to
ask where a package's source code can be found, if it sees that
modules are in use. (If modules are not in use, it falls back to the
usual lookup code and does not invoke the go command, so that
existing uses are unaffected and not slowed down.)
Helps #24661.
Fixes#26504.
Change-Id: I0dac68854cf5011005c3b2272810245d81b7cc5a
Reviewed-on: https://go-review.googlesource.com/125296
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The test RuntimeTypeAttr always failed when gcc
was unavailable. The test is duplicated for internal
and external linking. The usual verification
of host linker is added at the beginning of the
external link test.
Fixes#26621
Change-Id: I076d661f854c8a6de8fa5e7b069942a471445047
Reviewed-on: https://go-review.googlesource.com/126075
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
In -godefs mode any typedefs that appear in struct fields and the like
will presumably be defined in the input file. If we resolve to the
base type, those cross-references will not work. So for -godefs mode,
keep the Go 1.10 behavior and don't resolve the typedefs in a loop.
Fixes#26644
Change-Id: I48cf72d9eb5016353c43074e6aff6495af326f35
Reviewed-on: https://go-review.googlesource.com/125995
Reviewed-by: Keith Randall <khr@golang.org>
When the test retried multiple times, it reused the same Work variable,
causing in the builders being flaky due to panics. I was able to
immediately reproduce the failure with stress and -race:
$ go test -race -c && stress -p 32 ./par.test -test.run=TestWorkParallel$
/tmp/go-stress909062277
--- FAIL: TestWorkParallel (0.07s)
panic: par.Work.Do: already called Do [recovered]
panic: par.Work.Do: already called Do
Instead, use a new Work variable at each retry. Now, the line above
seems to never fail. Of course, much higher 'stress -p' values will
still result in "does not seem to be parallel" test failures since the
machine lacks resources. But those are test failures, not panics.
Fixes#26642.
Change-Id: I5e962eca7602cf413d911ff5669f56d4f52da5a7
Reviewed-on: https://go-review.googlesource.com/126355
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This variable is not used anymore. It was used in the
TestPackageNotStaleWithTrailingSlash test.
Change-Id: I5e52d4d1d91592dd21e2d9cff96974a49d07f5f8
Reviewed-on: https://go-review.googlesource.com/126376
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Before this CL the user effectively has to guess at the expected
location of a binary-only package. While the location is normally
obvious ($GOPATH/pkg/GOOS_GOARCH/PATH/PKG.a) it is much less so when
building with options that implicitly add an -installsufix option.
Fixes#26590
Change-Id: I753ef54d6dcf733bb456dba65a4a92e4db57a1b0
Reviewed-on: https://go-review.googlesource.com/125818
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If we're compiling a large function, be more picky about how big
the function we're inlining is. If the function is >5000 nodes,
we lower the inlining threshold from a cost of 80 to 20.
Turns out reflect.Value's cost is exactly 80. That's the function
at issue in #26546.
20 was chosen as a proxy for "inlined body is smaller than the call would be".
Simple functions still get inlined, like this one at cost 7:
func ifaceIndir(t *rtype) bool {
return t.kind&kindDirectIface == 0
}
5000 nodes was chosen as the big function size. Here are all the
5000+ node (~~1000+ lines) functions in the stdlib:
5187 cmd/internal/obj/arm (*ctxt5).asmout
6879 cmd/internal/obj/s390x (*ctxtz).asmout
6567 cmd/internal/obj/ppc64 (*ctxt9).asmout
9643 cmd/internal/obj/arm64 (*ctxt7).asmout
5042 cmd/internal/obj/x86 (*AsmBuf).doasm
8768 cmd/compile/internal/ssa rewriteBlockAMD64
8878 cmd/compile/internal/ssa rewriteBlockARM
8344 cmd/compile/internal/ssa rewriteValueARM64_OpARM64OR_20
7916 cmd/compile/internal/ssa rewriteValueARM64_OpARM64OR_30
5427 cmd/compile/internal/ssa rewriteBlockARM64
5126 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_50
6152 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_60
6412 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_70
6486 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_80
6534 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_90
6534 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_100
6534 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_110
6675 cmd/compile/internal/gc typecheck1
5433 cmd/compile/internal/gc walkexpr
14070 cmd/vendor/golang.org/x/arch/arm64/arm64asm decodeArg
There are a lot more smaller (~1000 node) functions in the stdlib.
The function in #26546 has 12477 nodes.
At some point it might be nice to have a better heuristic for "inlined
body is smaller than the call", a non-cliff way to scale down the cost
as the function gets bigger, doing cheaper inlined calls first, etc.
All that can wait for another release. I'd like to do this CL for
1.11.
Fixes#26546
Update #17566
Change-Id: Idda13020e46ec2b28d79a17217f44b189f8139ac
Reviewed-on: https://go-review.googlesource.com/125516
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
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>
