According to RFC-3986, the sub-delims chars should not be escaped in
fragment.
So this change fixes current behavior a bit.
Fixes#19917
Change-Id: I1a8deb93255d979532f75bae183c3fb53a05d395
Reviewed-on: https://go-review.googlesource.com/61650
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The test uses functions from C that were introduced in OSX 1.12.
Include stubs for those functions when compiling for 1.11 and earlier.
This test really a compile-time test, it doesn't matter much what the
executed code actually does.
Use a nasty #define hack to work around the fact that cgo doesn't
support static global variables.
Update #24161Fixes#26355
Change-Id: Icf6f7bc9b6b36cacc81d5d0e033a2ebaff7e0298
Reviewed-on: https://go-review.googlesource.com/123715
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Many parts of the FAQ are dusty and need cleaning up.
This is the first of a series of changes to bring it up to date.
Since it was first written at the time of release, some of the
ideas and background have changed, and some historical
remarks are largely irrelevant now.
Update #26107.
Change-Id: I1f36df7d8ecc8a1a033d5ac4fa1edeece25ed6b4
Reviewed-on: https://go-review.googlesource.com/123496
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing implementation stops recording type information once it
encounters an error. This results in missing type information that is
needed by various tools. This change handles a few commonly encountered
cases by continuing to check subtrees after errors. Also, add tests for
cases where the package fails to type-check.
Updates #22467
Change-Id: I1bb48d4cb8ae5548dca63bdd785ea2f69329e92b
Reviewed-on: https://go-review.googlesource.com/123578
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Updates bundled x/net/http2 to git rev d0887baf81f4 for:
http2: ignore unknown 1xx responses like HTTP/1
https://golang.org/cl/123615
http2: fix bug in earlier CL 123615
https://golang.org/cl/123675
Also along for the ride, but without any effect:
http2: export a field of an internal type for use by net/http
https://golang.org/cl/123656Fixes#26189
Updates #17739
Change-Id: I1955d844d74113efbcbbdaa7d7a7faebb2225b45
Reviewed-on: https://go-review.googlesource.com/123676
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL fixes up tests from the x/vgo repo that are failing
on some of the builders.
It will be submitted together with CL 123576.
Change-Id: I6bec81a93ad4f7116e8edc8c15beafa25747530c
Reviewed-on: https://go-review.googlesource.com/123580
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL corresponds to CL 123361, the final manual CL in that repo,
making this the final manual sync.
All future commits will happen in this repo (the main Go repo),
and we'll update x/vgo automatically with a fixed patch+script.
Change-Id: I572243309c1809727604fd704705a23c30e85d1a
Reviewed-on: https://go-review.googlesource.com/123576
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Previously Transport.CloseIdleConnections only closed the HTTP/2
Transport's idle connections if the HTTP/2 transport was configured
automatically via the bundled copy (in h2_bundle.go).
This makes it also work if the user called http2.ConfigureTransport
themselves using golang.org/x/net/http2 instead of the bundled copy.
No tests because we have no current way to run such cross-repo tests,
at least in any efficient or non-flaky way.
Tested by hand that:
package main
import (
"net/http"
"golang.org/x/net/http2"
)
func main() {
tr := &http.Transport{}
http2.ConfigureTransport(tr)
tr.CloseIdleConnections()
}
... now works and calls the x/net/http2.Transport.CloseIdleConnections
code. (I threw in a print statement locally)
Fixes#22891 once CL 123656 is also in.
Change-Id: Id697fd3e7877c3a988bc3c3368b88940ba56cfd0
Reviewed-on: https://go-review.googlesource.com/123657
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Two fixes:
1) Typedefs of the bad typedefs should also not be rewritten to the
underlying type. They shouldn't just be uintptr, though, they should
retain the C naming structure. For example, in C:
typedef const __CFString * CFStringRef;
typedef CFStringRef SecKeyAlgorithm;
we want the Go:
type _Ctype_CFStringRef uintptr
type _Ctype_SecKeyAlgorithm = _Ctype_CFStringRef
2) We need more types than just function arguments/return values.
At least we need types of global variables, so when we see a reference to:
extern const SecKeyAlgorithm kSecKeyAlgorithmECDSASignatureDigestX962SHA1;
we know that we need to investigate the type SecKeyAlgorithm.
Might as well just find every typedef and check the badness of all of them.
This requires looping until a fixed point of known types is reached.
Usually it takes just 2 iterations, sometimes 3.
Fixes#24161
Change-Id: I32ca7e48eb4d4133c6242e91d1879636f5224ea9
Reviewed-on: https://go-review.googlesource.com/123177
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If both branches of a write barrier test go to the same block,
then there's no unsafe points.
This can only happen if the resulting memory state is somehow dead,
which can only occur in degenerate cases, like infinite loops. No
point in cleaning up the useless branch in these situations.
Fixes#26024.
Change-Id: I93a7df9fdf2fc94c6c4b1fe61180dc4fd4a0871f
Reviewed-on: https://go-review.googlesource.com/123655
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Lack of a well-defined order between VarDef and related
address operations sometimes causes problems with store order
and write barrier transformations; glitches in the order are
made irreparable (by later optimizations) if the two parts of
the glitch straddle a split in the original block caused by
insertion of a write barrier diamond.
Fix this by creating a LocalAddr for addresses of locals
(what VarDef matters for) that takes a memory input to
help make the order explicit. Addr is modified to only
be legal for SB operand, so there is no overlap between
Addr and LocalAddr uses (there may be some downstream
cleanup from this).
Changes to generic.rules and rewrite.go ensure that codegen
tests continue to pass; CSE of LocalAddr is impaired, not
quite sure of the cost.
Fixes#26105.
Change-Id: Id4192b4440aa4e9d7ba54a465c456df9b530b515
Reviewed-on: https://go-review.googlesource.com/122483
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The behavior of -a no longer changes depending on which kind
of branch of Go you are using (the new build cache fixed all that).
These tests are not doing anything useful (and failing).
Change-Id: I1c65120a3e05286e888951d61bca4a903e2c1158
Reviewed-on: https://go-review.googlesource.com/123575
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
API compatibility violation, but it wasn't safe before and people
should be using golang.org/x/sys/windows instead.
Fixes#24820
Change-Id: I3b43493f56b3116924b9d848a294899279f314fd
Reviewed-on: https://go-review.googlesource.com/123455
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing example code uses variable name d, but
prints t in its output. It's needlessly confusing.
Change-Id: I67bef3c732e84d2d89819f96b4b62663630fd69e
Reviewed-on: https://go-review.googlesource.com/123516
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Updates bundled x/net/http2 to git rev cffdcf67 for:
http2: use GetBody unconditionally on Transport retry, when available
https://golang.org/cl/123476
http2: a closed stream cannot receive data
https://golang.org/cl/111676
Updates #25009
Updates #25023
Change-Id: I84f50cc50c0fa5a3c34f0037a9cb1ef468e5f0d9
Reviewed-on: https://go-review.googlesource.com/123515
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change "have to" to "need to" for clarity and to avoid a
peculiar English idiom.
Change-Id: Iec2b1f841d0353dd7925f8f934fe82d4ed059d7d
Reviewed-on: https://go-review.googlesource.com/123495
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For golang.org/cl/74110, I forgot that you can use range-based for
loops to extract key values from a map value.
This wasn't a problem for the binary format importer, because it was
more tolerant about missing inline function bodies. However, the
indexed importer is more particular about this.
We could potentially just make it more lenient like the binary
importer, but tweaking the logic here is easy enough and seems like
the preferable solution.
Fixes#26341.
Change-Id: I54564dcd0be60ea393f8a0f6954b7d3d61e96ee5
Reviewed-on: https://go-review.googlesource.com/123475
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
GOCACHE=off is not a reliable signal of user intent.
At startup the go command fills in an empty GOCACHE with the effective setting.
If $HOME is set, then GOCACHE ends up somewhere in $HOME/.cache.
But if $HOME is unset, then the go command sets GOCACHE=off explicitly.
That environment is used for invoking "go tool dist".
So if the machine has no $HOME, then go tool dist ends up with the cache
disabled even though the user was not trying to disable the cache.
This affects the linux-ppc64le builder, which appears to be unique
among builders in not having $HOME set. So that builder is running
with no build cache.
Now that there is a cmd/go test that needs the cache to be on,
the linux-ppc64le builder is failing.
In the next release we intend to force the use of the build cache
always. This CL is not doing that: it's only forcing the use of the
build cache during all.bash, which won't affect the majority of
our users (they run pre-build binary releases).
If this is a problem we can roll it back and fix the linux-ppc64le
builders some other way.
While we're here, print a few more useful variables in 'go tool dist env'
and sort the output.
Change-Id: I66548aa8990d0794cbc0f2069b739ab1834898dd
Reviewed-on: https://go-review.googlesource.com/123297
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also, remove some test code that was trying to work on XP and fix up
some comments referencing XP.
Fixes#26191
Updates #23380
Change-Id: I0b7319fe1954afddb22d396e5ec91d8c960268d8
Reviewed-on: https://go-review.googlesource.com/123415
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix the panic message produced for an interface conversion error to
only say "types from different packages" if they are definitely from
different packges. If they may be from the same package, say "types
from different scopes."
Updates #18911Fixes#26094
Change-Id: I0cea50ba31007d88e70c067b4680009ede69bab9
Reviewed-on: https://go-review.googlesource.com/123395
Reviewed-by: Austin Clements <austin@google.com>
DWARF compression accounts for roughly 30% of the linker's time. This
CL switches from DefaultCompression to BestSpeed, which virtually
eliminates this time. This roughly halves the overhead of handling
DWARF in the linker:
name \ time/op nodwarf dwarf dwarf-speed
BuildCmdGoAll 10.0s ±11% 10.6s ± 5% 10.8s ± 5%
nodwarf +6.41% +8.03%
dwarf ~
LinkCmdGo 626ms ± 5% 1096ms ± 2% 860ms ± 2%
nodwarf +75.17% +37.36%
dwarf -21.59%
Previously, enabling DWARF had a 75% overhead in link time for cmd/go.
This change reduces this overhead to 37% (a 22% reduction).
The effect on binary size is minimal compared to DefaultCompression,
and still substantially better than no compression:
cmd/go bytes
nodwarf 10106953
dwarf 12159049 nodwarf+20%
dwarf-speed 12408905 nodwarf+23%
dwarf-nozlib 17766473 nodwarf+76%
Updates #26318.
Change-Id: I33bb7caa038a2753c29104501663daf4839e7054
Reviewed-on: https://go-review.googlesource.com/123356
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Based on Dmitry Vyukov's comments in CL 65210.
Change-Id: I5dce7286b0d180cd43cad3aaf70f537fafcda588
Reviewed-on: https://go-review.googlesource.com/123275
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Remove some incorrect code that was present after since I added
support for idle timeouts in CL 22670.
This code actually caused a bug (a rare goroutine leak) rather than
prevent a bogus connection reuse.
The t.idleMu mutex already protects most the invariants, including an
explicit Stop call. There's only one Stop call on that timer, and it's
guarded by t.idleMu. What idleMu doesn't protect against is the timer
firing on its own. But we don't need code to protect against that case
because the goroutine that is created via AfterFunc when the timer
fires already checks the invariants:
// closeConnIfStillIdle closes the connection if it's still sitting idle.
// This is what's called by the persistConn's idleTimer, and is run in its
// own goroutine.
func (pc *persistConn) closeConnIfStillIdle() {
t := pc.t
t.idleMu.Lock()
defer t.idleMu.Unlock()
if _, ok := t.idleLRU.m[pc]; !ok {
// Not idle.
return
}
(note the "Not idle." part).
Tested by hand with the repro code from #25621. No more leaks.
Fixes#25621
Change-Id: Idf011a4cb1fcd01f55a5a6269e4c0ee5f4446786
Reviewed-on: https://go-review.googlesource.com/123315
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
OpenBSD 6.4 will require the stack pointer to be pointing at an area that is
marked as MAP_STACK when entering and exiting syscalls. Adjust the stack pointer
used for a new thread such that it points within the stack, not at the top of
it (i.e. outside).
Fixes#26142
Change-Id: I905bd8e5be3dfc325392e7ac490fb56a7c71b3aa
Reviewed-on: https://go-review.googlesource.com/122735
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Private fields of the Go class are not used any more after the program
has exited. Delete them to allow JavaScript's garbage collection to
clean up the WebAssembly instance.
Updates #26193.
Change-Id: I349784a49eaad0c22ceedd4f859df97132775537
Reviewed-on: https://go-review.googlesource.com/122296
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In general, dumb terminal indicates terminal with limited capability.
It may provide no support for special character sequences, e.g., no
handling of ANSI escape sequences. Its input/output handling behavior
may deviate from what's described in termios or terminfo. E.g., in
the shell in emacs, even after successfully setting the terminal to
raw mode, the terminal behaves as if it's still operating in canonical
mode since emacs is doing input processing first.
Readline support can be broken in various ways in dumb terminal mode,
so we want to disable readline or advanced UI features. The easiest
way to detect dumb terminal is to check the environment variable "TERM".
Fixes#26254
Change-Id: I6b652eb555bc03b84405aae08b0b25d111fbb8b0
Reviewed-on: https://go-review.googlesource.com/122879
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Taking a read lock in SetBlocking could cause SetBlocking to block
waiting for a Read in another goroutine to complete. Since SetBlocking
is called by os.(*File).Fd, that could lead to deadlock if the
goroutine calling Fd is going to use it to unblock the Read.
Use an atomic store instead.
Updates #24481
Change-Id: I79413328e06ddf28b6d5b8af7a0e29d5b4e1e6ff
Reviewed-on: https://go-review.googlesource.com/123176
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Recognize NetBSD in:
- go/internal/work/init.go
- race.bash
- runtime/race/race.go
Add __ps_strings symbol in runtime/cgo/netbsd.go as this is
used internally in the TSan library for NetBSD and used for
ReExec().
Tested on NetBSD/amd64 v. 8.99.12.
Around 98% tests are passing for the ./race.bash target.
Updates #19273
Change-Id: Ic0e48d2fb159a7868aab5e17156eeaca1225e513
GitHub-Last-Rev: d6e082707b
GitHub-Pull-Request: golang/go#24322
Reviewed-on: https://go-review.googlesource.com/99835
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When generating an abstract function DIE, call objabi.PathToPrefix on
the import path so as to be consistent with how the linker handles
import paths. This is intended to resolve another problem with DWARF
inline info generation in which there are multiple inconsistent
versions of an abstract function DIE for a function whose package path
is rewritten/canonicalized by objabi.PathToPrefix.
Fixes#26237
Change-Id: I4b64c090ae43a1ad87f47587a1a71f19bc5fc8e8
Reviewed-on: https://go-review.googlesource.com/123036
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Functions exported on behalf of other packages need to have their
argument stack maps specified explicitly. They don't get an implicit
map because they are not in the local package, and if they get defer'd
they need argument maps.
Fixes#24419
Change-Id: I35b7d8b4a03d4770ba88699e1007cb3fcb5397a9
Reviewed-on: https://go-review.googlesource.com/122676
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
At the moment, method declarations are type-checked together with
they receiver base types. This is a known problem (to be fixed early
for Go 1.12) but with the new cycle detection algorithm now also
introduced artifical type cycles.
This change pushes a special marker on the cycle path in those cases
so that these cycles can be ignored.
Fixes#26124.
Change-Id: I64da4ccc32d4ae293da48880c892154a1c6ac3fe
Reviewed-on: https://go-review.googlesource.com/121757
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
The clang compiler on some terminals will issue colored error
messages, which can confuse tools like cgo. To avoid this we used to
set TERM=dumb for all programs started by the go tool. However, that
confuses the pprof tool, which doesn't know whether to support fancy
editing and colors itself.
Instead, change the go tool and the cgo tool to set TERM=dumb where it
matters--when invoking the C compiler--rather than in all cases.
Updates #26254
Change-Id: I95174f961ac269a50a83f5f9d268219043cba968
Reviewed-on: https://go-review.googlesource.com/122975
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
More test cases of combined load for arm64.
Change-Id: I7a9f4dcec6930f161cbded1f47dbf7fcef1db4f1
Reviewed-on: https://go-review.googlesource.com/122582
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Also populate Imports for test main with go list -test.
Update comment in internal/load/test.go about
p.Imports, p.Internal.RawImports, and p.Imports
being perfectly aligned. The first two are,
but the third is not, as evidenced by CL 111175.
Since p.Imports is not aligned, don't assume that anymore.
Fixes#25949.
Change-Id: Icbfbc881bc01d1e195a759648fbd1c978ddbc161
Reviewed-on: https://go-review.googlesource.com/122878
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
The existing algorithm assumed that the length of a cycle was simply
the number of elements in the cycle slice starting at the start object.
However, we use a special "indir" indirection object to indicate
pointer and other indirections that break the inline placement of
types in composite types. These indirection objects don't exist as
true named type objects, so don't count them anymore.
This removes an unnecessary cycle error in one of the existing tests
(testdata/issues.src:100).
Also:
- added more tracing support (only active if tracing is enabled)
- better documentation in parts
- r/check.typ/check.typExpr/ in a few of places where we don't
need to record a type indirection
Found while investigating #26124.
Change-Id: I45341743225d979a72af3fbecfa05012b32fab67
Reviewed-on: https://go-review.googlesource.com/121755
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
cmd/cover has always assumed that package x/y/z can be
found in $GOPATH/src/x/y/z (roughly; by using go/build).
That won't be true for too much longer. Instead, run the
go command to find out where packages are.
This will make 'go tool cover' safe for use with Go modules
when they are in use in Go 1.11, and it continues to work
with the existing Go toolchains too.
An alternative would be to modify the cover profile format
to record file names directly, but that would require also
updating golang.org/x/tools/cover/profile and any tools
that use it, which seems not worth the trouble.
(That fork of the code does not contain any code to resolve
package names to directory locations, so it's unaffected.)
No new test here: cmd/go's TestCoverageFunc tests this code.
Fixes#25318 (when people use Go 1.11 instead of vgo).
Change-Id: I8769b15107aecf25f7aaf8692b724cf7d0f073d0
Reviewed-on: https://go-review.googlesource.com/122478
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>