Fix duplicated index in LHS and RHS of the < operator.
Found using https://go-critic.github.io/overview#dupSubExpr-ref
Change-Id: I9a5a40bbd436b32e8117579a01bc50afe3608c97
Reviewed-on: https://go-review.googlesource.com/122776
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We need to determine whether arguments to and return values from C
functions are "bad" typedef'd pointer types which need to be uintptr
on the Go side.
The type of those arguments are not specified explicitly. As a result,
we never look through the C declarations for the GetTypeID functions
associated with that type, and never realize that they are bad.
However, in another function in the same package there might be an
explicit reference. Then we end up with the declaration being uintptr
in one file and *struct{...} in another file. Badness ensues.
Fix this by doing a 2-pass algorithm. In the first pass, we run as
normal, but record all the argument and result types we see. In the
second pass, we include those argument types also when reading the C
types.
Fixes#24161
Change-Id: I8d727e73a2fbc88cb9d9899f8719ae405f59f753
Reviewed-on: https://go-review.googlesource.com/122575
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Added since last update.
Change-Id: Ic5be0e2e379d422ef72b956a794d65613a0dd7be
Reviewed-on: https://go-review.googlesource.com/122815
Reviewed-by: Andrew Bonventre <andybons@golang.org>
CL 95215 changed text/template so that untyped nil arguments were no
longer ignored, but were instead passed to functions as expected.
This had an unexpected effect on html/template, where all data is
implicitly passed to functions: originally untyped nil arguments were
not passed and were thus effectively ignored, but after CL 95215 they
were passed and were printed, typically as an escaped version of "<nil>".
This CL restores some of the behavior of html/template by ignoring
untyped nil arguments passed implicitly to escaper functions.
While eliminating one change to html/template relative to earlier
releases, this unfortunately introduces a different one: originally
values of interface type with the value nil were printed as an escaped
version of "<nil>". With this CL they are ignored as though they were
untyped nil values. My judgement is that this is a less common case.
We'll see.
This CL adds some tests of typed and untyped nil values to
html/template and text/template to capture the current behavior.
Updates #18716Fixes#25875
Change-Id: I5912983ca32b31ece29e929e72d503b54d7b0cac
Reviewed-on: https://go-review.googlesource.com/121815
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The same-site cookie attribute prevents a cookie from being sent along with
cross-site requests. The main goal is mitigate the risk of cross-origin
information leakage and provides some protection against cross-site request
forgery attacks.
This change adds the option to http.Cookie so it can be stored and
passed to HTTP clients.
Spec: https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00Fixes#15867
Based on
eb31a0f063
by Reed Loden <reed@hackerone.com>
Change-Id: I98c8a9a92358b2f632990576879759e3aff38cff
Reviewed-on: https://go-review.googlesource.com/79919
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add field to http.Transport which limits connections per host,
including dial-in-progress, in-use and idle (keep-alive) connections.
For HTTP/2, this field only controls the number of dials in progress.
Fixes#13957
Change-Id: I7a5e045b4d4793c6b5b1a7191e1342cd7df78e6c
Reviewed-on: https://go-review.googlesource.com/71272
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We need to make sure that the terminating comparison has the right
sense given the increment direction. If the increment is positive,
the terminating comparsion must be < or <=. If the increment is
negative, the terminating comparison must be > or >=.
Do a few cleanups, like constant-folding entry==0, adding comments,
removing unused "exported" fields.
Fixes#26116
Change-Id: I14230ee8126054b750e2a1f2b18eb8f09873dbd5
Reviewed-on: https://go-review.googlesource.com/121940
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Revert CL 101715.
The size of a sync.Pool scales linearly with GOMAXPROCS,
making it inappropriate to put a sync.Pool in any individually
allocated object, as the sync.Pool documentation explains.
The change also broke DeepEqual on regexps.
I have a cleaner way to do this with global sync.Pools but it's
too late in the cycle. Will revisit in Go 1.12. For now, revert.
Fixes#26219.
Change-Id: Ie632e709eb3caf489d85efceac0e4b130ec2019f
Reviewed-on: https://go-review.googlesource.com/122596
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Original CL description:
When using test -cover or -coverprofile the output for "no test files"
is the same format as for "no tests to run".
Reverting because this CL changed cmd/go to build test binaries for
packages that have no tests, leading to extra work and confusion.
Updates #24570Fixes#25789Fixes#26157Fixes#26242
Change-Id: Ibab1307d39dfaec0de9359d6d96706e3910c8efd
Reviewed-on: https://go-review.googlesource.com/122518
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This test is skipped on Linux and should be skipped on Android for the
same reason.
Change-Id: I753c4788d935bd58874554b455c0d5be2315b794
Reviewed-on: https://go-review.googlesource.com/122585
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 122515 tightened TestAbort to look for breakpoint exceptions and
not just general signal crashes, but this only applies on x86 arches.
On non-x86 arches we use a nil pointer dereference to abort, so the
test is now failing.
This CL re-loosens TestAbort on non-x86 arches to only expect a signal
traceback.
Should fix the build on linux/arm, linux/arm64, linux/ppc64, and
linux/s390x.
Change-Id: I1065341180ab5ab4da63b406c641dcde93c9490b
Reviewed-on: https://go-review.googlesource.com/122580
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Since CL 122515, TestAbort is failing on Plan 9
because there is no SIGTRAP signal on Plan 9,
but a note containing the "sys: breakpoint" string.
This change fixes the TestAbort test by handling
the Plan 9 case.
Fixes#26265.
Change-Id: I2fae00130bcee1cf946d8cc9d147a77f951be390
Reviewed-on: https://go-review.googlesource.com/122464
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Currently, if the runtime overflows the g0 stack on Windows, it leads
to an infinite recursion:
1. Something overflows the g0 stack bounds and calls morestack.
2. morestack determines it's on the g0 stack and hence cannot grow the
stack, so it calls badmorestackg0 (which prints "fatal: morestack on
g0") followed by abort.
3. abort performs an INT $3, which turns into a Windows
_EXCEPTION_BREAKPOINT exception.
4. This enters the Windows sigtramp, which ensures we're on the g0
stack and calls exceptionhandler.
5. exceptionhandler has a stack check prologue, so it determines that
it's out of stack and calls morestack.
6. goto 2
Fix this by making the exception handler avoid stack checks until it
has ruled out an abort and by blowing away the stack bounds in
lastcontinuehandler before we print the final fatal traceback (which
itself involves a lot of stack bounds checks).
Fixes#21382.
Change-Id: Ie66e91f708e18d131d97f22b43f9ac26f3aece5a
Reviewed-on: https://go-review.googlesource.com/120857
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Windows includes an 8K guard in system-allocated thread stacks, which
we currently don't account for when setting the g0 stack bounds. As a
result, if we do overflow the g0 stack bounds, we'll get a
STATUS_GUARD_PAGE_VIOLATION exception, which we're not expecting.
Fix the g0 stack bounds to include a total of 16K of slop to account
for this 8K guard.
Updates #21382.
Change-Id: Ia89b741b1413328e4681a237f5a7ee645531fe16
Reviewed-on: https://go-review.googlesource.com/122516
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
On Windows, the IP recorded in the breakpoint exception caused by
runtime.abort is actually one byte after the INT3, unlike on UNIX
OSes. Account for this in isgoexception.
It turns out TestAbort was "passing" on Windows anyway because abort
still caused a fatal panic, just not the one we were expecting. This
CL tightens this test to check that the runtime specifically reports a
breakpoint exception.
Fixing this is related to #21382, since we use runtime.abort in
reporting g0 stack overflows, and it's important that we detect this
and not try to handle it.
Change-Id: I66120944d138eb80f839346b157a3759c1019e34
Reviewed-on: https://go-review.googlesource.com/122515
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
The ADDLmodify/SUBLmodify/ANDLmodify/ORLmodify/XORLmodify should
have clobberFlags set to true.
Change-Id: Ie447d536db51334eddc70c00a722647282186a69
Reviewed-on: https://go-review.googlesource.com/122556
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reportedly CIFS on RHEL 7 can fail to report files if directories are
read in 4K increments. While this seems to be a CIFS or RHEL bug,
reportedly CIFS does not return more than 5760 bytes in a block, so
reading in 8K increments should hide the problem from users with
minimal cost.
Fixes#24015
Change-Id: Iaf9f00ffe338d379c819ed9edcd4cc9834e3b0f7
Reviewed-on: https://go-review.googlesource.com/121756
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Expanding interface method sets is handled during width calculation,
which can't be performed concurrently. Make sure that we eagerly
expand interfaces in the frontend when importing them, even if they're
not actually used by code, because we might need to generate a type
description of them.
Fixes#25055.
Change-Id: I6fd2756de2c7d5dbc33056f70b3028ca3aebab41
Reviewed-on: https://go-review.googlesource.com/122517
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Go documentation can have header lines, which are single-line paragraphs
with leading and trailing letters and almost no punctuation.
Before this CL, the only allowed punctuation was ' followed by s.
After this CL, parentheses and commas are also allowed,
to pick up a pair of previously unrecognized headings in the
go command documentation:
Gofmt (reformat) package sources
Modules, module versions, and more
Change-Id: I6d59c40a1269f01cef62a3fb17b909571c2f2adb
Reviewed-on: https://go-review.googlesource.com/122407
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
CL 118095 added gitrepo tests. These tests are failing on Plan 9
since they expect a full-featured git command, while the git tool
has been emulated as a simple rc script on Plan 9.
Fixes#25938.
Change-Id: I262a89d0ce83168c550d9af3e832ed3a1e3c43f6
Reviewed-on: https://go-review.googlesource.com/122455
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test is slightly flaky on the s390x builder and I suspect that
the 100ms timeout is a little too optimistic when the VM is starved.
Increase the timeout to 5s to match the other part of the test.
Fixes#26231.
Change-Id: Ia6572035fb3efb98749f2c37527d250a4c779477
Reviewed-on: https://go-review.googlesource.com/122315
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I don't have access to this e-mail inbox anymore.
Change-Id: Ia3dff6a56c7f6c782be74a998a622ef0611eca7e
Reviewed-on: https://go-review.googlesource.com/122456
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
This function tests that calling Shutdown on a Server that has a "new"
connection yet to write any bytes, in which case it should wait for five
seconds until considering the connection as "idle".
However, the test was flaky. If Shutdown happened to run before the
server accepted the connection, the connection would immediately be
rejected as the server is already closed, as opposed to being accepted
in the "new" state. Then, Shutdown would return almost immediately, as
it had no connections to wait for:
--- FAIL: TestServerShutdownStateNew (2.00s)
serve_test.go:5603: shutdown too soon after 49.41µs
serve_test.go:5617: timeout waiting for Read to unblock
Fix this by making sure that the connection has been accepted before
calling Shutdown. Verified that the flake is gone after 50k concurrent
runs of the test with no failures, whereas the test used to fail around
10% of the time on my laptop:
go test -c && stress -p 256 ./http.test -test.run TestServerShutdownStateNew
Fixes#26233.
Change-Id: I819d7eedb67c48839313427675facb39d9c17257
Reviewed-on: https://go-review.googlesource.com/122355
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The maximum number of 'spanz' iterations that the s390x assembler
performs to reach a fixed point for relative offsets was 10. This
turned out to be too aggressive for one example of auto-generated
fuzzing code. Increase the number of iterations by 10x to reduce
the likelihood that the limit will be hit again. This limit only
exists to help find bugs in the assembler.
master at tip does not fail with the example code in the issue, I
have therefore not submitted it as a test (it is also quite large).
I tested this change with the example code at the commit given and
it fixes the issue.
Fixes#25269.
Change-Id: I0e44948957a7faff51c7d27c0b7746ed6e2d47bb
Reviewed-on: https://go-review.googlesource.com/122235
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Otherwise it is possible that msan will consider the C result to be
partially initialized, which may cause msan to think that the Go stack
is partially uninitialized. The compiler will never mark the stack as
initialized, so without this CL it is possible for stack addresses to
be passed to msanread, which will cause a false positive error from msan.
Fixes#26209
Change-Id: I43a502beefd626eb810ffd8753e269a55dff8248
Reviewed-on: https://go-review.googlesource.com/122196
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There is no "window" global in a web worker context. Use "self" instead.
Fixes#26192
Change-Id: I6c6f3db6c3d3d9ca00a473f8c18b849bc07a0017
Reviewed-on: https://go-review.googlesource.com/122055
Run-TryBot: Richard Musiol <neelance@gmail.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
Use an HTML comment with triple dashes for the copypright header, which
means that the paragraph will be ignored when rendering both HTML and
TeX.
While at it, quote "GC", and properly link to internal/ssa/README.md.
Change-Id: Ib18529d2fc777d836e74726ff1cfe685e08b063c
Reviewed-on: https://go-review.googlesource.com/109875
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The implementation is mostly copied from the commit that added
linux/amd64 support for this feature (https://golang.org/cl/17761).
Change-Id: I3f482167620a7a3daf50a48087f8849a30d713bd
Reviewed-on: https://go-review.googlesource.com/102438
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We already remove -rdynamic if -static appears in -extldflags.
Extend that to apply to CGO_LDFLAGS and #cgo LDFLAGS as well.
Updates #26197
Change-Id: Ibb62d1b20726916a12fd889acb05c1c559a5ace2
Reviewed-on: https://go-review.googlesource.com/122135
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently we use a globally unique symbol property on objects that get
passed from JavaScript to Go to store a unique ID that Go then uses when
referring back to the JavaScript object (via js.Value.ref). This
approach fails however when a JavaScript object cannot be modified, i.e.
cannot have new properties added or is frozen. The test that is added as
part of this commit currently fails with:
Cannot add property Symbol(), object is not extensible
Instead we consolidate the string, symbol and object unique ID mapping
into a single map. Map key equality is determined via strict equality,
which is the semantic we want in this situation.
Change-Id: Ieb2b50fc36d3c30e148aa7a41557f3c59cd33766
Reviewed-on: https://go-review.googlesource.com/121799
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
Since the initial version was written, I've gotten help writing
cmd/compile/README.md and I've also learned some more on my own, so it's
time to organise this document better and expand it.
First, split up the document in sections, starting from the simplest
ideas that can be explained on their own. From there, build all the way
up into SSA functions and how they are compiled.
Each of the sections also gets more detail now; most ideas that were a
paragraph are now a section with several paragraphs. No new major
sections have been added in this CL.
While at it, add a copyright notice and make better use of markdown,
just like in the other README.md.
Also fix a file path in value.go, which I noticed to be stale while
reading godocs to write the document.
Finally, leave a few TODO comments for areas that would benefit from
extra input from people familiar with the SSA package. They will be
taken care of in future CLs.
Change-Id: I85e7a69a0b3260e72139991a625d926099624f71
Reviewed-on: https://go-review.googlesource.com/110067
Reviewed-by: Keith Randall <khr@golang.org>
When a command has a test that is not in package main, the main
package is built as a library, with ForceLibrary set. It can of course
also be built as an ordinary main package. If we don't record that fact
in the hash, then both variants of the command will use the same hash,
which causes a GODEBUG=gocacheverify=1 failure. It also seems unsafe
although it's not clear to me whether it can cause an actual failure.
Along with CL 121941,
Fixes#25666
Change-Id: I115ad249012f30fbe45cd0c41da86adc295fe4b2
Reviewed-on: https://go-review.googlesource.com/121942
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The linker's sym.Symbol struct contains two string fields, "Dynimplib"
and "Dynimpvers" that are used only in very specific circumstances
(for many symbols, such as DWARF syms, they are wasted space). Split
these two off into a separate struct, then point to an instance of
that struct when needed. This reduces the size of sym.Symbol so as to
save space in the common case.
Updates #26186
Change-Id: Id9c74824e78423a215c8cbc105b72665525a1eff
Reviewed-on: https://go-review.googlesource.com/121916
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The sym.Symbol 'Reachparent' field is used only when field tracking
is enabled. So as to use less memory for the common case where
field tracking is not enabled, remove this field and use a side
table stored in the context to achieve the same functionality.
Updates #26186
Change-Id: Idc5f8b0aa323689d4d51dddb5d1b0341a37bb7d2
Reviewed-on: https://go-review.googlesource.com/121915
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before CL 116855, Transport would only skip over 100 (expect-continue)
responses automatically and treat all other 1xx responses as if they
were the final status. CL 116855 made the Transport more spec
compliant (ignoring unknown 1xx responses), but broke "101 Switching
Protocols" in the process. Since 101 is already in use and defined to
not have a following message, treat it as terminal.
Note that because the Client/Transport don't support hijacking the
underlying Conn, most clients doing a WebSocket or other protocol
upgrade are probably using net.Dial + http.ReadResponse instead, which
remained unaffected (before & after this CL).
The main affect of this CL is to fix tests that were using the
Client/Transport to test that a server returns 101, presumably without
actually switching to another protocol.
Fixes#26161
Change-Id: Ie3cd3a465f948c4d6f7ddf2a6a78a7fb935d0672
Reviewed-on: https://go-review.googlesource.com/121860
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The vetx output file is a build output, and as such should be
deterministic. This CL changes it to not depend on map iteration order.
This avoids a pointless GODEBUG=gocacheverify=1 failure.
Updates #25666
Change-Id: Ic132bad134cb10938275f883c2c68432cb7c4409
Reviewed-on: https://go-review.googlesource.com/121941
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
