Saves ~105KB of heap for callers who don't use html.UnescapeString.
(EscapeString is much more common).
Also saves 70KB of binary size, because now the linker can do dead
code elimination. (because #2559 is still open and global maps always
generate init code)
Fixes#26727
Updates #6853
Change-Id: I18fe9a273097e2c7e0cb7f88205cae1bb60fa89b
Reviewed-on: https://go-review.googlesource.com/127075
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Due to a new specification of //line: directives, missing
column info is now treated as column 0, aka "unknown column"
(see https://github.com/golang/go/issues/24183 for details).
As cgo does not add column number to generated //line: directive,
resulting files parsed do not have column info.
Fix by adding column of 1 to generated line directives.
Fixes#26692
Change-Id: Ie9263c0cf666b92d19c34240e745e8f32ffe7174
Reviewed-on: https://go-review.googlesource.com/126675
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ensure that we call FinishType on all the types added to the ptrs map.
We only add a key to ptrKeys once. Once we FinishType for that key,
we'll never look at that key again. But we can add a new type under that
key later, and we'll never finish it.
Make sure we add the key to the ptrKeys list every time we make the list
of types for that key non-empty.
This makes sure we FinishType each pointer type exactly once.
Fixes#26517
Change-Id: Iad86150d516fcfac167591daf5a26c38bec7d143
Reviewed-on: https://go-review.googlesource.com/126275
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some of the arguments — particularly format strings passed to git commands — may
contain spaces, and it's useful to be able to paste commands from 'go get -x
foo' directly into a shell to reproduce their output.
Change-Id: I4f0c0b4e05db8b5232458e9a271f2ccbb665e85a
Reviewed-on: https://go-review.googlesource.com/126955
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also updates the bundled http2 to x/net/http2 git rev 49c15d80 for:
http2: revert CL 107295 (don't sniff Content-type in Server when nosniff)
https://golang.org/cl/126895Fixes#24795
Change-Id: I6ae1a21c919947089274e816eb628d20490f83ce
Reviewed-on: https://go-review.googlesource.com/126896
Reviewed-by: Damien Neil <dneil@google.com>
This commit removes O_NONBLOCK on js/wasm. O_SYNC can't be
removed, because it is referenced by the os package, so instead
its use returns an error.
On Windows, the options O_NONBLOCK and O_SYNC are not available
when opening a file with Node.js. This caused the initialization
of the syscall package to panic.
The simplest solution is to not support these two options on js/wasm
at all. Code written for js/wasm is supposed to be portable,
so platform-specific options should not be used.
Fixes#26524.
Change-Id: I366aa3cdcfa59dfa9dc513368259f363ca090f00
Reviewed-on: https://go-review.googlesource.com/126600
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This commit moves the documentation about how Go values are mapped to
JavaScript values to the functions that apply the mapping, instead of
mentioning them in the documentation of the types being mapped. This
should be easier to read.
Change-Id: I2465eb4a45f71b3b61624349e908a195010a09f1
Reviewed-on: https://go-review.googlesource.com/126856
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The example code was treating a method starting with Test
as a test function when considering whether to produce
a whole-file example or not. As a method can never be
a test function, this isn't correct.
Change-Id: Idd8ec9eaf0904af076e941d7fe7d967f6b7eef78
Reviewed-on: https://go-review.googlesource.com/125257
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This struct, global var and method are not used anywhere.
Change-Id: I83d9e93041a46904064d0fa88ab655a50149c747
Reviewed-on: https://go-review.googlesource.com/126397
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The FAQ already has a link to the release notes and the go command docs.
Add a link from the release notes to the go command docs, to ensure that
people ultimately end up there (the docs that then signpost
people to the relevant other help docs).
Updates #25517.
Change-Id: I284c84af712d4519c59f7ca6c396b05a4c967cee
Reviewed-on: https://go-review.googlesource.com/126777
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Expand mod_internal tests to cover vendoring, replacements, and failure
messages.
Packages beginning with "golang_org/" resolve to $GOROOT/src/vendor, and should
therefore not be visible within module code.
Fixes#23970.
Change-Id: I706e9c4a1d1e025883e84b897972678d0fa3f2bd
Reviewed-on: https://go-review.googlesource.com/125836
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
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>
The message was hardcoded to indicate that the test wanted a nil error, even
though in some cases a specific error was wanted. This patch fixes the
message to print the wanted error.
Change-Id: Id86ea89d6f41f25bfa164acc50142ae8ff0ec410
GitHub-Last-Rev: c220374845
GitHub-Pull-Request: golang/go#26674
Reviewed-on: https://go-review.googlesource.com/126619
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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 net/http module added support for HTTPS proxies in CL 68550, but the
Transport.Proxy docstring was never updated to reflect this. This (doc-only)
update adds "https" to the list of supported schemes.
Change-Id: I0570fcdae8232bb42d52c4dd739dd09ee8dfd612
Reviewed-on: https://go-review.googlesource.com/126495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The Linux kernel faccessat system call does not take a flags parameter.
The flag parameter to the C library faccessat function is implemented in C.
The syscall.Faccessat function takes a flags parameter. In older releases
we have passed the flags parameter to the kernel, which ignored it.
In CL 120015 we started returning an error if any flags were set.
That seems clearly better than ignoring them, but it turns out that some
code was using the flags. The code was previously subtly broken.
Now it is obviously broken. That is better, but we can do better still:
we can implement the flags as the C library does. That is what this CL does.
Change-Id: I259bd6f240c3951e939b81c3032dead3d9c567b4
Reviewed-on: https://go-review.googlesource.com/126415
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We've expanded this several times. Try more.
Fixes#18837
Change-Id: I03b699391351a30ee60a15d7aa712c6c66444cf9
Reviewed-on: https://go-review.googlesource.com/125875
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
Change the Pipe() function to use the pipe() syscall (which has a unique
calling convention on linux/mips) instead of using pipe2(). This allows
it work on kernels <2.6.27 when pipe2() was introduced.
Change-Id: I65dfbd2a02b64e777a8eb13013d718e356521be6
GitHub-Last-Rev: c483a06168
GitHub-Pull-Request: golang/go#26608
Reviewed-on: https://go-review.googlesource.com/125915
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Vladimir Stefanovic <vladimir.stefanovic@mips.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing implementation of TLS connection has a deadlock. It occurs
when client connects to TLS server and doesn't send data for
handshake, so server calls Close on this connection. This is because
server reads data under locked mutex, while Close method tries to
lock the same mutex.
Fixes#23518
Change-Id: I4fb0a2a770f3d911036bfd9a7da7cc41c1b27e19
Reviewed-on: https://go-review.googlesource.com/90155
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@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>
This avoids problems when running under QEMU. It seems that at least
some QEMU versions turn the sigaction implementation into a call to
the C library sigaction function. The C library function will reject
attempts to set the signal handler for signals 32 and 33. Ignore
errors in that case.
Change-Id: Id443a9a32f6fb0ceef5c59a398e7ede30bf71646
Reviewed-on: https://go-review.googlesource.com/125955
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The DNS client in net is documented to treat Conns returned by
Resolver.Dial which implement PacketConn as UDP and those which don't as
TCP regardless of what was requested. golang.org/cl/37879 changed the
DNS client to assume that the Conn returned by Resolver.Dial was the
requested type which broke compatibility.
Fixes#26573
Updates #16218
Change-Id: Idf4f073a4cc3b1db36a3804898df206907f9c43c
Reviewed-on: https://go-review.googlesource.com/125735
Run-TryBot: Ian Gudger <igudger@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
