Bryan C. Mills [Fri, 30 Nov 2018 19:04:35 +0000 (14:04 -0500)]
[release-branch.go1.11-security] cmd/go: reject 'get' of paths containing leading dots or unsupported characters
On some platforms, directories beginning with dot are treated as
hidden files, and filenames containing unusual characters can be
confusing for users to manipulate (and delete).
Change-Id: Ia1f5a65b9cff4eeb51cc4dba3ff7c7afabc343f2
Reviewed-on: https://team-review.git.corp.google.com/c/368442 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Filippo Valsorda [Wed, 5 Dec 2018 03:23:22 +0000 (22:23 -0500)]
[release-branch.go1.11-security] crypto/x509: limit number of signature checks for each verification
That number grows quadratically with the number of intermediate
certificates in certain pathological cases (for example if they all have
the same Subject) leading to a CPU DoS. Set a fixed budget that should
fit all real world chains, given we only look at intermediates provided
by the peer.
The algorithm can be improved, but that's left for follow-up CLs:
* the cache logic should be reviewed for correctness, as it seems to
override the entire chain with the cached one
* the equality check should compare Subject and public key, not the
whole certificate
* certificates with the right SKID but the wrong Subject should not
be considered, and in particular should not take priority over
certificates with the right Subject
Change-Id: Ib257c12cd5563df7723f9c81231d82b882854213
Reviewed-on: https://team-review.git.corp.google.com/c/370475 Reviewed-by: Andrew Bonventre <andybons@google.com>
(cherry picked from commit 09d57361bc99cbbfb9755ee30ddcb42ff5a9d7d6)
Reviewed-on: https://team-review.git.corp.google.com/c/372858 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Robert Griesemer [Thu, 11 Oct 2018 00:19:29 +0000 (17:19 -0700)]
[release-branch.go1.11] go/types: use correct receiver types for embedded interface methods
Interface methods don't declare a receiver (it's implicit), but after
type-checking the respective *types.Func objects are marked as methods
by having a receiver. For interface methods, the receiver base type used
to be the interface that declared the method in the first place, even if
the method also appeared in other interfaces via embedding. A change in
the computation of method sets for interfaces for Go1.10 changed that
inadvertently, with the consequence that sometimes a method's receiver
type ended up being an interface into which the method was embedded.
The exact behavior also depended on file type-checking order, and because
files are sometimes sorted by name, the behavior depended on file names.
This didn't matter for type-checking (the typechecker doesn't need the
receiver), but it matters for clients, and for printing of methods.
This change fixes interface method receivers at the end of type-checking
when we have all relevant information.
Daniel Theophanes [Sun, 30 Sep 2018 05:10:43 +0000 (22:10 -0700)]
[release-branch.go1.11] database/sql: correctly report MaxIdleClosed stat
Previously the MaxIdleClosed counter was incremented when added
to the free connection list, rather then when it wasn't added
to the free connection list. Flip this logic to correct.
Fixes #28325
Change-Id: I405302c14fb985369dab48fbe845e5651afc4ccf
Reviewed-on: https://go-review.googlesource.com/c/138578
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 7db509e682891f3bc501c7b23e32e02c64893557)
Reviewed-on: https://go-review.googlesource.com/c/146697
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org> Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Hana Kim [Mon, 17 Sep 2018 18:46:50 +0000 (14:46 -0400)]
[release-branch.go1.11] cmd/trace: don't drop sweep slice details
For sweep events, we used to modify the ViewerEvent returned from
ctx.emitSlice later in order to embed more details about the sweep
operation. The trick no longer works after the change
https://golang.org/cl/92375 and caused a regression.
ctx.emit method encodes the ViewerEvent, so any modification to the
ViewerEvent object after ctx.emit returns will not be reflected.
Refactor ctx.emitSlice, so ctx.makeSlice can be used when producing
slices for SWEEP. ctx.emit* methods are meant to truely emit
ViewerEvents.
Alex Brainman [Tue, 30 Oct 2018 08:40:57 +0000 (19:40 +1100)]
[release-branch.go1.11] internal/poll: advance file position in windows sendfile
Some versions of Windows (Windows 10 1803) do not set file
position after TransmitFile completes. So just use Seek
to set file position before returning from sendfile.
Russ Cox [Wed, 24 Oct 2018 16:01:13 +0000 (12:01 -0400)]
[release-branch.go1.11] cmd/go, cmd/link: silence bogus Apple Xcode warning
Certain installations of Xcode are affected by a bug that causes
them to print an inconsequential link-time warning that looks like:
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.
This has nothing to do with Go, and we've sent this repro case
to Apple:
$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
version: 10.0.0.0.1.1535735448
$ clang --version
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
$ cat > issue.c
int main() { return 0; }
^D
$ clang issue.c -framework CoreFoundation
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
$
Even if Apple does release a fixed Xcode, many people are seeing
this useless warning, and we might as well make it go away.
Fixes #26073.
Change-Id: Ifc17ba7da1f6b59e233c11ebdab7241cb6656324
Reviewed-on: https://go-review.googlesource.com/c/144112 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
(cherry picked from commit 66bb8ddb956c5ee55b471a019fac2c6817c08ef5)
Reviewed-on: https://go-review.googlesource.com/c/145458
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Jason Keene [Thu, 13 Sep 2018 02:35:58 +0000 (20:35 -0600)]
[release-branch.go1.11] cmd/go: ensure git attributes are set
This change disables the export-subst and export-ignore attributes when
creating zip files for modules. This is done to prevent the ziphash for
a given repo/revision from differing based on variables such as git
version or size of repo. The full rational for this change is detailed
here:
Cherry Zhang [Wed, 3 Oct 2018 02:04:45 +0000 (22:04 -0400)]
[release-branch.go1.11] cmd/compile: fix type of OffPtr in some optimization rules
In some optimization rules the type of generated OffPtr was
incorrectly set to the type of the pointee, instead of the
pointer. When the OffPtr value is spilled, this may generate
a spill of the wrong type, e.g. a floating point spill of an
integer (pointer) value. On Wasm, this leads to invalid
bytecode.
Richard Musiol [Tue, 2 Oct 2018 17:11:14 +0000 (19:11 +0200)]
[release-branch.go1.11] misc/wasm: add mention of polyfill for Edge support
Edge supports WebAssembly but not TextEncoder or TextDecoder.
This change adds a comment pointing to a polyfill that could
be used. The polyfill is not added by default, because we want to
let the user decide if/how to include the polyfill.
Fixes #27295
Change-Id: I375f58f2168665f549997b368428c398dfbbca1c
Reviewed-on: https://go-review.googlesource.com/139037 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit cfb603b0b5fb9c1e72be665b2d65743ddf18c779)
Reviewed-on: https://go-review.googlesource.com/139057 Reviewed-by: Richard Musiol <neelance@gmail.com>
Matthew Waters [Mon, 24 Sep 2018 10:08:54 +0000 (06:08 -0400)]
[release-branch.go1.11] net: concatenate multiple TXT strings in single TXT record
When go resolver was changed to use dnsmessage.Parser, LookupTXT
returned two strings in one record as two different records. This change
reverts back to concatenating multiple strings in a single
TXT record.
Change-Id: I46a975ed37d5e570afe2e228d3edf74949e08ad7
Reviewed-on: https://go-review.googlesource.com/138580 Reviewed-by: Michael Munday <mike.munday@ibm.com>
Reviewed-on: https://go-review.googlesource.com/138583
Run-TryBot: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith Randall [Tue, 25 Sep 2018 22:54:11 +0000 (15:54 -0700)]
[release-branch.go1.11] reflect: ensure correct scanning of return values
During a call to a reflect-generated function or method (via
makeFuncStub or methodValueCall), when should we scan the return
values?
When we're starting a reflect call, the space on the stack for the
return values is not initialized yet, as it contains whatever junk was
on the stack of the caller at the time. The return space must not be
scanned during a GC.
When we're finishing a reflect call, the return values are
initialized, and must be scanned during a GC to make sure that any
pointers in the return values are found and their referents retained.
When the GC stack walk comes across a reflect call in progress on the
stack, it needs to know whether to scan the results or not. It doesn't
know the progress of the reflect call, so it can't decide by
itself. The reflect package needs to tell it.
This CL adds another slot in the frame of makeFuncStub and
methodValueCall so we can put a boolean in there which tells the
runtime whether to scan the results or not.
This CL also adds the args length to reflectMethodValue so the
runtime can restrict its scanning to only the args section (not the
results) if the reflect package says the results aren't ready yet.
Do a delicate dance in the reflect package to set the "results are
valid" bit. We need to make sure we set the bit only after we've
copied the results back to the stack. But we must set the bit before
we drop reflect's copy of the results. Otherwise, we might have a
state where (temporarily) no one has a live copy of the results.
That's the state we were observing in issue #27695 before this CL.
The bitmap used by the runtime currently contains only the args.
(Actually, it contains all the bits, but the size is set so we use
only the args portion.) This is safe for early in a reflect call, but
unsafe late in a reflect call. The test issue27695.go demonstrates
this unsafety. We change the bitmap to always include both args
and results, and decide at runtime which portion to use.
issue27695.go only has a test for method calls. Function calls were ok
because there wasn't a safepoint between when reflect dropped its copy
of the return values and when the caller is resumed. This may change
when we introduce safepoints everywhere.
This truncate-to-only-the-args was part of CL 9888 (in 2015). That
part of the CL fixed the problem demonstrated in issue27695b.go but
introduced the problem demonstrated in issue27695.go.
TODO, in another CL: simplify FuncLayout and its test. stack return
value is now identical to frametype.ptrdata + frametype.gcdata.
Update #27867
Change-Id: I2d49b34e34a82c6328b34f02610587a291b25c5f
Reviewed-on: https://go-review.googlesource.com/137440
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/138582
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith Randall [Tue, 25 Sep 2018 21:32:44 +0000 (14:32 -0700)]
[release-branch.go1.11] reflect: use correct write barrier operations for method funcs
Fix the code to use write barriers on heap memory, and no
write barriers on stack memory.
These errors were discovered as part of fixing #27695. They may
have something to do with that issue, but hard to be sure.
The core cause is different, so this fix is a separate CL.
Update #27867
Change-Id: Ib005f6b3308de340be83c3d07d049d5e316b1e3c
Reviewed-on: https://go-review.googlesource.com/137438 Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit e35a41261b19589f40d32bd66274c23ab4b9b32e)
Reviewed-on: https://go-review.googlesource.com/138581
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Gudger [Thu, 6 Sep 2018 06:53:36 +0000 (23:53 -0700)]
[release-branch.go1.11] net: fail fast for DNS rcode success with no answers of requested type
DNS responses which do not contain answers of the requested type return
errNoSuchHost, the same error as rcode name error. Prior to
golang.org/cl/37879, both cases resulted in no additional name servers
being consulted for the question. That CL changed the behavior for both
cases. Issue #25336 was filed about the rcode name error case and
golang.org/cl/113815 fixed it. This CL fixes the no answers of requested
type case as well.
Updates #27525
Fixes #27537
Change-Id: I52fadedcd195f16adf62646b76bea2ab3b15d117
Reviewed-on: https://go-review.googlesource.com/133675
Run-TryBot: Ian Gudger <igudger@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 94f48ddb96c4dfc919ae024f64df19d764f5fb5b)
Reviewed-on: https://go-review.googlesource.com/138175
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith Randall [Mon, 17 Sep 2018 19:25:36 +0000 (12:25 -0700)]
[release-branch.go1.11] runtime: ignore races between close and len/cap
They aren't really races, or at least they don't have any
observable effect. The spec is silent on whether these are actually
races or not.
Fix this problem by not using the address of len (or of cap)
as the location where channel operations are recorded to occur.
Use a random other field of hchan for that.
I'm not 100% sure we should in fact fix this. Opinions welcome.
Fixes #27778
Change-Id: Ib4efd4b62e0d1ef32fa51e373035ef207a655084
Reviewed-on: https://go-review.googlesource.com/135698 Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(cherry picked from commit 83dfc3b001245f0b725afdc94c0b540fe1952d21)
Reviewed-on: https://go-review.googlesource.com/138179
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Johan Brandhorst [Fri, 24 Aug 2018 11:10:01 +0000 (12:10 +0100)]
[release-branch.go1.11] net/http: ensure null body in Fetch response is not read
The Fetch API returns a null body if there is no response body,
on browsers that support streaming the response body. This
change ensures we check for both undefined and null bodies
before attempting to read the body.
Fixes #27424
Change-Id: I0da86b61284fe394418b4b431495e715a037f335
Reviewed-on: https://go-review.googlesource.com/131236 Reviewed-by: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit ce536837d8e53f1bf0c7ef450d4580d19f7d6f52)
Reviewed-on: https://go-review.googlesource.com/136915
Dmitri Shuralyov [Wed, 12 Sep 2018 17:58:18 +0000 (13:58 -0400)]
[release-branch.go1.11] doc/go1.11, cmd/go: elaborate on new GOFLAGS environment variable
In Go 1.11, cmd/go gained support for the GOFLAGS environment variable.
It was added and described in detail in CL 126656.
Mention it in the Go 1.11 release notes, link to the cmd/go documentation,
and add more details there.
Fixes #27387.
Change-Id: Ifc35bfe3e0886a145478d36dde8e80aedd8ec68e
Reviewed-on: https://go-review.googlesource.com/135035 Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Rob Pike <r@golang.org>
(cherry picked from commit 58c6afe075d74261dd67750e0aab5a1b8460839f)
Reviewed-on: https://go-review.googlesource.com/135496 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Alberto Donizetti [Wed, 22 Aug 2018 12:01:22 +0000 (14:01 +0200)]
[release-branch.go1.11] cmd/compile: prevent overflow in walkinrange
In the compiler frontend, walkinrange indiscriminately calls Int64()
on const CTINT nodes, even though Int64's return value is undefined
for anything over 2⁶³ (in practise, it'll return a negative number).
This causes the introduction of bad constants during rewrites of
unsigned expressions, which make the compiler reject valid Go
programs.
This change introduces a preliminary check that Int64() is safe to
call on the consts on hand. If it isn't, walkinrange exits without
doing any rewrite.
Rebecca Stambler [Thu, 30 Aug 2018 15:33:19 +0000 (11:33 -0400)]
[release-branch.go1.11] go/types: handle nil pointer when panic is written outside of a function
The current implementation crashes when someone writes a panic outside of
a function, which makes sense since that is broken code. This fix allows
one to type-check broken code.
Fixes #27497
Change-Id: I81b90dbd918162a20c60a821340898eaf02e648d
Reviewed-on: https://go-review.googlesource.com/132235 Reviewed-by: Alan Donovan <adonovan@google.com>
(cherry picked from commit c99687f87aed84342cfe92ae78924f791237c6f6)
Reviewed-on: https://go-review.googlesource.com/133395 Reviewed-by: Robert Griesemer <gri@golang.org>
[release-branch.go1.11] crypto/x509: allow ":" in Common Name hostnames
At least one popular service puts a hostname which contains a ":"
in the Common Name field. On the other hand, I don't know of any name
constrained certificates that only work if we ignore such CNs.
Updates #24151
Change-Id: I2d813e3e522ebd65ab5ea5cd83390467a869eea3
Reviewed-on: https://go-review.googlesource.com/134076
Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 03c703697f321f66d28d6223457622c5879ba37f)
Reviewed-on: https://go-review.googlesource.com/134078 Reviewed-by: Andrew Bonventre <andybons@golang.org>
Keith Randall [Wed, 5 Sep 2018 21:36:20 +0000 (14:36 -0700)]
[release-branch.go1.11] runtime: in semasleep, subtract time spent so far from timeout
When pthread_cond_timedwait_relative_np gets a spurious wakeup
(due to a signal, typically), we used to retry with the same
relative timeout. That's incorrect, we should lower the timeout
by the time we've spent in this function so far.
In the worst case, signals come in and cause spurious wakeups
faster than the timeout, causing semasleep to never time out.
Also fix nacl and netbsd while we're here. They have similar issues.
Fixes #27521
Change-Id: I6601e120e44a4b8ef436eef75a1e7c8cf1d39e39
Reviewed-on: https://go-review.googlesource.com/133655
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 2bf1370f4369d75f4fffffc6fc05722bce13481b)
Reviewed-on: https://go-review.googlesource.com/134096
Giovanni Bajo [Fri, 31 Aug 2018 00:15:26 +0000 (02:15 +0200)]
[release-branch.go1.11] cmd/compile: in prove, fix fence-post implications for unsigned domain
Fence-post implications of the form "x-1 >= w && x > min ⇒ x > w"
were not correctly handling unsigned domain, by always checking signed
limits.
This bug was uncovered once we taught prove that len(x) is always
>= 0 in the signed domain.
In the code being miscompiled (s[len(s)-1]), prove checks
whether len(s)-1 >= len(s) in the unsigned domain; if it proves
that this is always false, it can remove the bound check.
Notice that len(s)-1 >= len(s) can be true for len(s) = 0 because
of the wrap-around, so this is something prove should not be
able to deduce.
But because of the bug, the gate condition for the fence-post
implication was len(s) > MinInt64 instead of len(s) > 0; that
condition would be good in the signed domain but not in the
unsigned domain. And since in CL105635 we taught prove that
len(s) >= 0, the condition incorrectly triggered
(len(s) >= 0 > MinInt64) and things were going downfall.
Andrei Tudor Călin [Thu, 30 Aug 2018 04:55:05 +0000 (06:55 +0200)]
[release-branch.go1.11] net: refactor readerAtEOF splice test
Refactor TestSplice/readerAtEOF to handle cases where we disable
splice on older kernels better.
If splice is disabled, net.splice and poll.Splice do not get to
observe EOF on the reader, because poll.Splice returns immediately
with EINVAL. The test fails unexpectedly, because the splice operation
is reported as not handled.
This change refactors the test to handle the aforementioned case
correctly, by not calling net.splice directly, but using a higher
level check.
Fixes #27355.
Change-Id: I0d5606b4775213f2dbbb84ef82ddfc3bab662a31
Reviewed-on: https://go-review.googlesource.com/132096
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit bd49b3d580731d8f391e40fb9e2f17301651cede)
Reviewed-on: https://go-review.googlesource.com/132281 Reviewed-by: Andrew Bonventre <andybons@golang.org>
Dmitri Shuralyov [Thu, 23 Aug 2018 19:05:19 +0000 (15:05 -0400)]
[release-branch.go1.11] doc/go1.11: add link to new WebAssembly wiki page
The wiki page has recently been created, and at this time it's
just a stub. It's expected that support for WebAssembly will be
evolving over time, and the wiki page can be kept updated with
helpful information, how to get started, tips and tricks, etc.
Use present tense because it's expected that there will be more
general information added by the time Go 1.11 release happens.
Also add link to https://webassembly.org/ in first paragraph.
Change-Id: I139c2dcec8f0d7fd89401df38a3e12960946693f
Reviewed-on: https://go-review.googlesource.com/131078 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 6e76aeba0bda33f6bd45ac9c8e5c026c1688e846)
Reviewed-on: https://go-review.googlesource.com/131096
Filippo Valsorda [Tue, 21 Aug 2018 20:50:04 +0000 (14:50 -0600)]
[release-branch.go1.11] crypto/tls: make ConnectionState.ExportKeyingMaterial a method
The unexported field is hidden from reflect based marshalers, which
would break otherwise. Also, make it return an error, as there are
multiple reasons it might fail.
Russ Cox [Sat, 18 Aug 2018 18:16:26 +0000 (14:16 -0400)]
[release-branch.go1.11] cmd/go: add go.sum entries to go mod download -json output
Clients of 'go mod download', particularly proxies, may need
the hashes of the content they downloaded, for checking against
go.sum entries or recording elsewhere.
Change-Id: Ic36c882cefc540678e1bc5a3dae1e865d181aa69
Reviewed-on: https://go-review.googlesource.com/129802
Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
(cherry picked from commit 46033d7639cb1399029b99bb0cdc53d2b8f4bd08)
Reviewed-on: https://go-review.googlesource.com/130615
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is possible to enter the parent-walking directory loop in a way that
it will loop forever - if mdir is empty, and d reaches ".". To avoid
this, make sure that the 'd = filepath.Dir(d)' step only happens if the
parent directory is actually different than the current directory.
This fixes some of the tests like TestImport/golang.org_x_net_context,
which were never finishing before.
While at it, also fix TestImport/golang.org_x_net, which seems to have
the wrong expected error. The root of the x/net repo doesn't have a
go.mod file, nor is part of a module itself, so it seems like the
expected error should reflect that.
After these two changes, 'go test cmd/go/internal/modload' passes on my
linux/amd64 machine.
It was a bug to find that commit in the Masterminds/semver repo.
It's not part of the main repo but only part of an unmerged pull request.
The code was updated to try not to look at unmerged pull requests,
but the test was not. Worse, whether the code succeeds at not looking
at unmerged pull requests apparently depends on the git version.
Sigh.
Russ Cox [Sat, 18 Aug 2018 02:32:22 +0000 (22:32 -0400)]
cmd/go: allow 'go run x.go' to use nearby internal imports in module mode
In GOPATH mode the rule has always been that 'go run x.go' can
import whatever the package in x.go's directory would be able to
import. Apply the same rule here.
The bad import path was triggering other mysterious errors
during 'go run' in other circumstances. Setting it correctly fixes
those too.
Russ Cox [Sat, 18 Aug 2018 01:25:52 +0000 (21:25 -0400)]
cmd/go: fix and reenable TestAccidentalGitCheckout
This is an important security problem so we shouldn't disable the test.
The second half was failing on case-sensitive file systems but the
first half is still good.
then the go get command has always worked hard to make sure
that it applies the wildcard after downloading rsc/foo.
(If it applied the wildcard only before downloading rsc/foo,
it would match nothing if you had an empty GOPATH before,
and you'd still have an empty afterward, which is clearly useless.)
The goal has always been that if you run the same go get
command twice, the second command doesn't find anything
new to do.
CL 19892 worked around an "internal error" failure but broke
the rule about the first command doing everything the second
command would. Suppose you had github.com/rsc/foo already,
with just github.com/rsc/foo/bar, and you run
go get -u github.com/rsc/...
The wildcard first matches github.com/rsc/foo/bar, but suppose
updating the repo pulls down github.com/rsc/foo/baz, which
in turn depends on the non-existent package github.com/rsc/quux.
We need to reevaluate the wildcard after the download.
The new pattern match refactoring makes this easier and happened
to have corrected the behavior, but we missed a long test that
expected the old behavior.
Russ Cox [Fri, 17 Aug 2018 19:40:55 +0000 (15:40 -0400)]
cmd/go: treat VCS errors as hard errors in module search
If we're looking for a module for a/b/c/d/e,
we check for a module named a/b/c/d/e,
then a/b/c/d, then a/b/c, then a/b, then a.
If we know the source repo for a/b/c and that
fails, we should report that error instead of
continuing the loop: a/b and a are useless,
and the error from a/b/c contains important
information.
The errors are now a bit more verbose than
I'd like but they will suffice for Go 1.11.
$ go get github.com/bradfitz/private/sonos
go get github.com/bradfitz/private/sonos: git ls-remote -q origin in /Users/rsc/pkg/mod/cache/vcs/61e3c76780847e514802ec6af8f940f641c6017f711444f05c59cb17ac46d456: exit status 128:
remote: Repository not found.
fatal: repository 'https://github.com/bradfitz/private/' not found
$ go list launchpad.net/gocheck
can't load package: package launchpad.net/gocheck: unknown import path "launchpad.net/gocheck": bzr branch --use-existing-dir https://launchpad.net/~niemeyer/gocheck/trunk . in /Users/rsc/pkg/mod/cache/vcs/f46ce2ae80d31f9b0a29099baa203e3b6d269dace4e5357a2cf74bd109e13339: exec: "bzr": executable file not found in $PATH
$
Russ Cox [Fri, 17 Aug 2018 18:47:31 +0000 (14:47 -0400)]
cmd/go: remove go mod fix, add go help go.mod
"go mod fix" does work already done by nearly every other go command.
It was also confusing why we had both "go mod fix" and "go mod tidy".
Delete "go mod fix".
The main reason we kept "go mod fix" this long was for the discussion
of automatic go.mod updates in its documentation, which is now moved
into a new "go help go.mod".
The proxy protocol was simplified to only send
(and only receive) the Path and Version fields
in the JSON blob, not Name and Short.
(Those make sense when querying a VCS repo directly,
but not when talking about extracted modules.)
So don't expect them in the test.
Russ Cox [Fri, 10 Aug 2018 20:28:48 +0000 (16:28 -0400)]
cmd/go: do not turn list ./nonexist into a network lookup
If you're in a directory corresponding to x/y
and you run go list ./z, we do at some point
want to turn that into x/y/z. But if ./z does
not exist that will make the go command
check the network to see if it can find x/y/z.
That's clearly wrong: ./z means that directory,
nothing else. And it turns a typo into a long delay,
which is even worse.
Russ Cox [Fri, 17 Aug 2018 16:40:18 +0000 (12:40 -0400)]
cmd/go: report which patterns match each package in list
It's important for some uses of go/packages, as well as for some
of go/packages's internal use, to be able to tell which results from
go list output correspond to which patterns, keeping in mind that
a single package might have been matched by multiple patterns.
Russ Cox [Fri, 10 Aug 2018 04:01:48 +0000 (00:01 -0400)]
cmd/go: fix -gcflags, -ldflags not applying to current directory
A flag setting like -gcflags=-e applies only to the packages
named on the command line, not to their dependencies.
The way we used to implement this was to remember the
command line arguments, reinterpret them as pattern matches
instead of package argument generators (globs), and apply them
during package load. The reason for this complexity was to
address a command-line like:
go build -gcflags=-e fmt runtime
The load of fmt will load dependencies, including runtime,
and the load of runtime will reuse the result of the earlier load.
Because we were computing the effective -gcflags for each
package during the load, we had to have a way to tell, when
encountering runtime during the load of fmt, that runtime had
been named on the command line, even though we hadn't
gotten that far. That would be easy if the only possible
arguments were import paths, but we also need to handle
go build -gcflags=-e fmt runt...
go build -gcflags=-e fmt $GOROOT/src/runtime
go build -gcflags=-e fmt $GOROOT/src/runt...
and so on.
The match predicates usually did their job well, but not
always. In particular, thanks to symlinks and case-insensitive
file systems and unusual ways to spell file paths, it's always
been possible in various corner cases to give an argument
that evalutes to the runtime package during loading but
failed to match it when reused to determine "was this package
named on the command line?"
CL 109235 fixed one instance of this problem by making
a directory pattern match case-insensitive on Windows, but that
is incorrect in some other cases and doesn't address the root problem,
namely that there will probably always be odd corner cases
where pattern matching and pattern globbing are not exactly aligned.
This CL eliminates the assumption that pattern matching
and pattern globbing are always completely in agreement,
by simply marking the packages named on the command line
after the package load returns them. This means delaying
the computation of tool flags until after the load too,
for a few different ways packages are loaded.
The different load entry points add some complexity,
which is why the original approach seemed more attractive,
but the original approach had complexity that we simply
didn't recognize at the time.
This CL then rolls back the CL 109235 pattern-matching change,
but it keeps the test introduced in that CL. That test still passes.
In addition to fixing ambiguity due to case-sensitive file systems,
this new approach also very likely fixes various ambiguities that
might arise from abuse of symbolic links.
Russ Cox [Fri, 10 Aug 2018 17:26:32 +0000 (13:26 -0400)]
cmd/go: distinguish patterns from the results of matching them
To date the go command has always just treated the command line
package patterns as a []string, expanded by pattern matching into
another []string. As a result, the code is not always clear about
whether a particular []string contains patterns or results.
A few different important bugs are caused by not keeping
this distinction clear enough. This CL sets us up well for fixing those,
by introducing an explicit search.Match struct holding the
results of matching a single pattern.
The added clarity here also makes it clear how to avoid duplicate
warnings about unmatched packages.
Daniel Martí [Thu, 16 Aug 2018 13:39:13 +0000 (14:39 +0100)]
cmd/vet: don't suggest ... if it breaks a program
It is possible to write a function that seems to wrap a print/printf
call, but then doesn't. For example, if the string parameter we thought
was the format is used as another argument.
One option would be to make vet's print analysis smarter, to detect when
format strings are indeed used like we initially suspected.
However, I've opted for a simpler solution - check if the print/printf
call is already using more than one variadic argument, in which case
using an ellipsis in the last one would break the program:
// too many arguments in call to fmt.Printf
fmt.Printf(format, arg0, args...)
Dan Johnson [Wed, 15 Aug 2018 23:48:44 +0000 (16:48 -0700)]
cmd/compile: make duplicate anonymous interface output deterministic
Ranging through a map is non-deterministic and there can be duplicate
entries in the set (with the same name) which don't have identical
definitions in some cases.
Russ Cox [Sat, 11 Aug 2018 00:05:44 +0000 (20:05 -0400)]
cmd/go: ignore import "C" files in module loader in non-cgo mode
Obviously, including files that import "C" when cgo is disabled is wrong.
The package load step correctly excludes them and finds no files at all,
which then causes a failure.
Fixes #26927.
Change-Id: I00e6d6450e783d467d20bde99e91240ecb0db837
Reviewed-on: https://go-review.googlesource.com/129062
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: David du Colombier <0intro@gmail.com>
Russ Cox [Sat, 11 Aug 2018 00:22:21 +0000 (20:22 -0400)]
cmd/go: ignore /tmp/go.mod
Two different people have created /tmp/go.mod for experimentation
and then had other tests that create fresh work directories
below /tmp fail unexpectedly because the go command finds
/tmp/go.mod. Refuse to use /tmp/go.mod. /tmp/anything/go.mod is fine.
The change, while addressing issue #26352, introduced another
regression (#26930), which is worse. Reverting this change in
favor of a better fix for the original issue.
Updates #26352.
Fixes #26930.
Change-Id: I71ad12a8212992cce5c1e73907d1f7460f98d9e8
Reviewed-on: https://go-review.googlesource.com/129255
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Richard Musiol [Sun, 5 Aug 2018 16:52:15 +0000 (18:52 +0200)]
cmd/compile/internal/gc: add nil check for closure call on wasm
This commit adds an explicit nil check for closure calls on wasm,
so calling a nil func causes a proper panic instead of crashing on the
WebAssembly level.
Johan Brandhorst [Fri, 3 Aug 2018 14:48:16 +0000 (14:48 +0000)]
net/http: support configuring fetch options
The default WASM RoundTripper is implemented using
the browser Fetch API. Some options don't readily map to
existing http.Request options, so we use the precedent
set by the TrailerPrefix constant to allow a user to configure
the "mode" and "credentials" options by supplying them
as headers in the http.Request.
Russ Cox [Fri, 10 Aug 2018 03:44:43 +0000 (23:44 -0400)]
cmd/go: report implicit cgo inputs in go list -compiled
Tools using go list -compiled expect to see an Imports list
that includes all the imports in CompiledGoFiles.
Make sure the list includes the cgo-generated imports.