[git-generate]
cd src/runtime
mv export_test.go export.go
GOROOT=$(dirname $(dirname $PWD)) rf '
add mheap.pagesInUse \
// Proportional sweep \
// \
// These parameters represent a linear function from gcController.heapLive \
// to page sweep count. The proportional sweep system works to \
// stay in the black by keeping the current page sweep count \
// above this line at the current gcController.heapLive. \
// \
// The line has slope sweepPagesPerByte and passes through a \
// basis point at (sweepHeapLiveBasis, pagesSweptBasis). At \
// any given time, the system is at (gcController.heapLive, \
// pagesSwept) in this space. \
// \
// It is important that the line pass through a point we \
// control rather than simply starting at a 0,0 origin \
// because that lets us adjust sweep pacing at any time while \
// accounting for current progress. If we could only adjust \
// the slope, it would create a discontinuity in debt if any \
// progress has already been made. \
pagesInUse_ atomic.Uint64 // pages of spans in stats mSpanInUse
ex {
import "runtime/internal/atomic"
var t mheap
var v, w uint64
var d int64
t.pagesInUse -> t.pagesInUse_.Load()
t.pagesInUse = v -> t.pagesInUse_.Store(v)
atomic.Load64(&t.pagesInUse) -> t.pagesInUse_.Load()
atomic.LoadAcq64(&t.pagesInUse) -> t.pagesInUse_.LoadAcquire()
atomic.Store64(&t.pagesInUse, v) -> t.pagesInUse_.Store(v)
atomic.StoreRel64(&t.pagesInUse, v) -> t.pagesInUse_.StoreRelease(v)
atomic.Cas64(&t.pagesInUse, v, w) -> t.pagesInUse_.CompareAndSwap(v, w)
atomic.Xchg64(&t.pagesInUse, v) -> t.pagesInUse_.Swap(v)
atomic.Xadd64(&t.pagesInUse, d) -> t.pagesInUse_.Add(d)
}
rm mheap.pagesInUse
mv mheap.pagesInUse_ mheap.pagesInUse
'
mv export.go export_test.go
Change-Id: I495d188683dba0778518563c46755b5ad43be298
Reviewed-on: https://go-review.googlesource.com/c/go/+/356549
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Iterate through the actual, possibly defined types of constraints
when type-checking generic conversions, not the underlying types.
For #47150.
Change-Id: Ia7af313bf46d6f6b0ad5292ff793b030b8e2d3d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/357333
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a clean port of CL 357291 from x/tools.
For #46586
Change-Id: Ib22087ae7fe8477d368acd230b263b83cdad4d36
Reviewed-on: https://go-review.googlesource.com/c/go/+/357429
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 327872, there's a fix for crawling of embeddable types directly
reached by the user, so all of its methods need to be re-exported. But
we missed the cased when an un-exported type may be reachable by
embedding in exported type. Example:
type t struct {}
func (t) M() {}
func F() interface{} { return struct{ t }{} }
We generate the wrapper for "struct{ t }".M, and when inlining call to
"struct{ t }".M makes "t.M" reachable.
It works well, and only be revealed in CL 327871, when we changed
methodWrapper to always call inline.InlineCalls, thus causes the crash
in #49016, which involve dot type in inlined function.
Fixes#49016
Change-Id: If174fa5575132da5cf60e4bd052f7011c4e76c5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/356254
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Remove a bit of dead code from the Go object file reader (io.ReaderAt
no longer needed in goobj.Reader).
Change-Id: I04150d37fb90b59c9dbe930878d4dd21cdcd7ca7
Reviewed-on: https://go-review.googlesource.com/c/go/+/357309
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Minor leftover from CL 74851.
Change-Id: I1b56afcde3c505ba77a0f79e8ae9b01000362298
GitHub-Last-Rev: 87e97571a5
GitHub-Pull-Request: golang/go#48942
Reviewed-on: https://go-review.googlesource.com/c/go/+/355629
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Alexander Rakoczy <alex@golang.org>
When invoking check.binary for assignment operation, the expression will
be nil, thus for printing the assignment operation error message, we
need to reconstruct the statement from lhs, op, rhs.
Fixes#48472
Change-Id: Ie38c3dd8069b47e508968d6e43cedcf7536559ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/357229
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: I2fca7a801c85ed93c002c23bfcb0cf9593f1bdf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/356571
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The "" stand-in for the current package needs to be substituted
in more places when importing, because of generics.
""..dict.conv4["".MyString]
when imported in main and then exported, this becomes
a..dict.conv4["".MyString]
and then the linker makes that into
a..dict.conv4[main.MyString]
Which isn't correct. We need to replace on import not just
function names, but also globals, which this CL does.
Change-Id: Ia04a23b5ffd60aeeaba72c807f69261105670f8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/356570
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This makes it easier to run tests on existing generic code that is
not using the `.go2` ending currently used by type checker tests.
For #49074.
Change-Id: I1501463c55dbe1d709918786e1a43b6d1bf1629a
Reviewed-on: https://go-review.googlesource.com/c/go/+/357050
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is the port of CL 356809 for Value.Pointer to fix the mismatch of
methodValueCall code pointer.
Change-Id: I080ac41b94b44d878cd5896207a76a28c57fd48b
Reviewed-on: https://go-review.googlesource.com/c/go/+/356950
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 350691 added Value.UnsafePointer and make Value.Pointer call it
internally. It has a downside that Value.Pointer can now eligible to be
inlined, thus making un-intentional side effect, like the test in
fixedbugs/issue15329.go becomes flaky.
This CL restore Value.Pointer original implementation, pre CL 350691,
with the deprecation TODO removed.
Fixes#49067
Change-Id: I735af182f8e729294333ca906ffc062f477cfc99
Reviewed-on: https://go-review.googlesource.com/c/go/+/356949
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
GOWORK will be set to the go.work file's path, if in workspace mode
or will be empty otherwise.
For #45713Fixes#48589
Change-Id: I163ffaf274e0a41469c1f3b8514d6f90e20423b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/355689
Trust: Michael Matloob <matloob@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Add support for replace directives in the go.work file. If there are
conflicting replaces in go.mod files, suggest that users add an
overriding replace in the go.work file.
Add HighestReplaced to MainModules so that it accounts for the
replacements in the go.work file.
(Reviewers: I'm not totally sure that HighestReplace is computed
correctly. Could you take a closer look at that?)
For #45713
Change-Id: I1d789219ca1dd065ba009ce5d38db9a1fc38ba83
Reviewed-on: https://go-review.googlesource.com/c/go/+/352812
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
errors.Is internally unwraps the error until the error matches the
target. Because of this, a user-authored Is method on an error type
need not call errors.Unwrap on itself or the target, because that would
make the unwrapping operation O(N^2). It is a subtle detail to remind
authors for resource efficiency reasons.
Change-Id: Ic1ba59a5bdbfe2c7cb51a2cba2537ab6de4a13ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/356789
Reviewed-by: Jean de Klerk <deklerk@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Jean de Klerk <deklerk@google.com>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Jean de Klerk <deklerk@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change adds support for the reg ABI to the Index and Count
functions for ppc64/ppc64le.
Most Index and Count benchmarks show improvement in performance on
POWER9 with this change. Similar numbers observed on POWER8 and POWER10.
name old time/op new time/op delta
Index/32 71.0ns ± 0% 67.9ns ± 0% -4.42% (p=0.001 n=7+6)
IndexEasy/10 17.5ns ± 0% 17.2ns ± 0% -1.30% (p=0.001 n=7+7)
name old time/op new time/op delta
Count/10 26.6ns ± 0% 25.0ns ± 1% -6.02% (p=0.001 n=7+7)
Count/32 78.6ns ± 0% 74.7ns ± 0% -4.97% (p=0.001 n=7+7)
Count/4K 5.03µs ± 0% 5.03µs ± 0% -0.07% (p=0.000 n=6+7)
CountEasy/10 26.9ns ± 0% 25.2ns ± 1% -6.31% (p=0.001 n=7+7)
CountSingle/32 11.8ns ± 0% 9.9ns ± 0% -15.70% (p=0.002 n=6+6)
Change-Id: Ibd146c04f8107291c55f9e6100b8264dfccc41ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/355509
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
uint64 is guaranteed by the compiler to be aligned on 64-bit archs.
By using uint64+uint32 instead of [3]uint32 we can make use of the
guaranteed alignment to avoid the run-time alignment check.
On linux/amd64:
name old time/op new time/op delta
WaitGroupUncontended-4 8.84ns ± 3% 7.62ns ± 4% -13.72% (p=0.000 n=17+18)
WaitGroupAddDone-4 66.8ns ± 3% 45.9ns ± 2% -31.31% (p=0.000 n=20+18)
WaitGroupAddDoneWork-4 79.2ns ± 1% 56.6ns ± 1% -28.54% (p=0.000 n=17+20)
WaitGroupWait-4 2.83ns ± 2% 2.58ns ± 2% -9.05% (p=0.000 n=18+20)
WaitGroupWaitWork-4 16.8ns ± 6% 16.5ns ± 6% ~ (p=0.072 n=20+18)
WaitGroupActuallyWait-4 263ns ± 2% 261ns ± 5% ~ (p=0.063 n=18+20)
Change-Id: I314340f2ed8a47d8b9c15f8a3b07e41f252f4831
Reviewed-on: https://go-review.googlesource.com/c/go/+/189837
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change also does some refactors around how
we prevent many (*F) methods from being called
inside (*F).Fuzz. Previously, there was a lot of
comment/code duplication, which was going to be
difficult to maintain and brittle. The refactor
lessens this duplication.
Previously, the methods Log, Logf, Failed, Name and
Skipped were the only (*common) methods that were
allowed to be called inside (*F).Fuzz. After this
change, Failed and Name are still allowed, but
Log, Logf, and Skipped are not (t.Log, t.Logf, or
t.Skipped should be used instead).
Fixes#48988
Change-Id: I4066247d551ea1908e8a2ca2889509fc68e3bb44
Reviewed-on: https://go-review.googlesource.com/c/go/+/356151
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This is a clean port of CL 356533 from go/types to types2.
Fixes#49043.
Change-Id: If389b94ece28042b0c8b436959dd21f26147a144
Reviewed-on: https://go-review.googlesource.com/c/go/+/356517
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a clean port of CL 356490 from go/types to types2.
Fixes#48703.
Fixes#48974.
Change-Id: I08c0db0b92250cbb043325541b21a577726b40ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/356515
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is an essentially clean port of CL 356489 from go/types to types2,
with minor adjustments due to the different AST packages and error
reporting.
Fixes#47990.
Change-Id: I52187872474bfc1fb49eb77905f22fc820b7295b
Reviewed-on: https://go-review.googlesource.com/c/go/+/356514
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL addresses the 2nd part of the issue below.
- For types2, now use the same error messages as the compiler in this case.
- Make the mechanism for reporting clarifying error messages handle the case
where we don't have additional position information.
- Provide context information (type assertion vs type switch).
Fixes#49005.
Change-Id: I4eeaf4f0c3f2f8735b63993778f58d713fef21ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/356512
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Findley <rfindley@google.com>
CL 322350 changed how to take address of assembly functions, using
abi.FuncPCABI0 intrinsic. But we forgot to update the code in
Value.UnsafePointer (was Value.Pointer) to reflect that change.
This CL fixes that bug, and also add a test to make sure the code
pointer is in sync.
Change-Id: I05ae7df31c706583a0f374d8af027066528f5ceb
Reviewed-on: https://go-review.googlesource.com/c/go/+/356809
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
In CL 354670, I copied some existing rules for convenience but forgot
to update the last rule which broke `GOAMD64=v3 ./make.bat`
Revive CL 354670
Change-Id: Ic1e2047c603f0122482a4b293ce1ef74d806c019
Reviewed-on: https://go-review.googlesource.com/c/go/+/356810
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
(Temporarily, until they can be fixed.)
For #49046
For #49047
Change-Id: Ib580a5e45a0955aabdfc1899ed38a262a37f66ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/356649
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
On riscv64, the JAL instruction is only capable of reaching +/-1MB. In the case where
a single function and its trampolines exceeds this size, it is possible that the JAL
is unable to reach the trampoline, which is laid down after the function text. In the
case of large functions, switch back to using a AUIPC+JALR pairs rather than using
trampolines.
Fixes#48791
Change-Id: I119cf3bc20ce4933a9b7ab41a8e514437c6addb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/356250
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Fixes#37595
Change-Id: I83e5f6105748a0a9238322a4f7ec4b0bbf61a263
Reviewed-on: https://go-review.googlesource.com/c/go/+/348394
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Cherry Mui <cherryyz@google.com>
ticks might be same after tick division, although the real cputicks
is linear growth
Fixes#46737
Change-Id: I1d98866fbf21b426c6c1c96cc9cf802d7f440f18
Reviewed-on: https://go-review.googlesource.com/c/go/+/330849
Trust: Meng Zhuo <mzh@golangcn.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The branch test only takes a few seconds so enable it in short mode. Also fix a
typo that currently prevents the code from compiling.
Change-Id: I25fc646b002a66c042c61fb1f56d5efa8e47903c
Reviewed-on: https://go-review.googlesource.com/c/go/+/356249
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Even after type-checking the RHS of a type declaration, we may not yet
be able to expand, if the RHS is itself an instance (see #49043).
We can instead rely on the mechanisms we have in place for delayed
expansion.
Fixes#49043
Change-Id: Ibffa4c1b1163c824b5c7e151aaac35f3e8c84ec7
Reviewed-on: https://go-review.googlesource.com/c/go/+/356533
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Rather than using Checker.later in newNamed, add a Checker.defTypes
field to track named types that have been created during type-checking,
and use this to expand named types as a final phase in type checking.
We have encountered several bugs related to infinite recursion while
expanding named types, because (I would argue) we have two conflicting
requirements in the type checker: ensuring that we eventually collapse
underlying chains, and yet allowing lazy substitution of the underlying
type in instances. The former is necessary for correctness, and to
ensure that we detect cycles during the type-checking pass. The latter
is necessary to allow infinitely expanding patterns of instances through
underlying or method definitions.
I believe this CL reconciles these conflicting requirements, by creating
a boundary between types that are encountered in the source during
type checking, and instances that are created by recursive evaluation.
At the end of the type checking pass, Checker.defTypes should contain
all possible origin types for instantiation. Once we compute the true
underlying for these origin types, any remaining instances that are
unresolved are guaranteed to have an origin with a valid underlying.
Therefore, we can return from the type-checking pass without calling
under() for these remaining instances.
Fixes#48703Fixes#48974
Change-Id: I1474f514e2ab71c1ad4c3704fe32bfba11d59394
Reviewed-on: https://go-review.googlesource.com/c/go/+/356490
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add constraint type inference for type instances, to be consistent with
inference of function values.
Fixes#47990
Change-Id: Ib99b5215cb2da5c10badc4de7e9e60ca0e48489f
Reviewed-on: https://go-review.googlesource.com/c/go/+/356489
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When (*bufio.Writer).ReadFrom is called with a partially filled buffer,
fill out and flush the buffer and then call the underlying writer's
ReadFrom method if present.
Fixes#44815.
Change-Id: I15b3ef0746d0d60fd62041189a9b9df11254dd29
Reviewed-on: https://go-review.googlesource.com/c/go/+/340530
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It was noticed through some other investigation that BitLen32
was not generating the best code and found that it wasn't recognized
as an intrinsic. This corrects that and enables the test for PPC64.
Change-Id: Iab496a8830c8552f507b7292649b1b660f3848b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/355872
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This change removes the js.Wrapper interface for performance reasons.
See proposal #44006 for details.
This is a breaking change, but syscall/js is exempt from Go's
compatibility promise.
Fixes#44006
Change-Id: I968cd14b1e61cc72ea9f84240b6bd29e8b8ae673
Reviewed-on: https://go-review.googlesource.com/c/go/+/356430
Trust: Richard Musiol <neelance@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
This changes Go, to remove this unused field on the `Tree` struct. Which seems to replaced by the non-private field `Mode`.
Change-Id: I5b384424cf60aa0af36eb8aad1d8db3f99b9838e
GitHub-Last-Rev: 4b033f967b
GitHub-Pull-Request: golang/go#48028
Reviewed-on: https://go-review.googlesource.com/c/go/+/345789
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Allowing eliminates a class of possible misuse of unsafe.Pointer, and
allow callers to migrate from Value.Addr and Value.Pointer, thus they
can be now deprecated.
Fixes#40592
Change-Id: I798e507c748922cac5cc1c1971c1b2cc7095a068
Reviewed-on: https://go-review.googlesource.com/c/go/+/350691
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The doc mentions that "UnsafeAddr returns a _pointer_ to v's data", but
it returns a uintptr instead, which don't have pointer semantic.
Change-Id: I557d5597cbc485356ca803eb496a99d6db8c63ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/350690
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The compiler refuses to do spectre mitigation on 386, but the
assembler doesn't. Fix that.
Fixes#49006
Change-Id: I887b6f7ed7523a47f463706f06ca4c2c6e828b6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/356190
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
After CL 349012 and CL 350911, we can fully handle these
labeled statements, so we can allow them when inlining.
Updates #14768
Change-Id: I0ab3fd3f8d7436b49b1aedd946516b33c63f5747
Reviewed-on: https://go-review.googlesource.com/c/go/+/355497
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Dan Scales <danscales@google.com>
This CL avoids a useless follow-on error (that gets reported before the
actual error due to source position). This addresses the first part of
the issue below.
Thanks to @cuonglm for the suggestion for the fix.
For #49005.
Change-Id: Ifdd83072a05c32e115dc58a0233868a64f336f3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/356449
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The respective issue was fixed in types2 with CL 356189;
and the problem didn't exist in go/types. This CL simply
adds the test case to the type checkers as well.
For #49003.
Change-Id: Ib50ee8bb0ad21f2916f2b79d4f77593302899a3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/356411
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Make sure that an embedded field like "MyStruct[T]" works and can be
referenced via the name MyStruct.
Change-Id: I8be1f1184dd42c4e54e4144aff2fd85e30af722f
Reviewed-on: https://go-review.googlesource.com/c/go/+/356312
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Simple cleanup: convert a bunch of if's to a switch statement in
getInstInfo. Also, use a few extra variables to avoid repeated node
conversions (such as n.(*ir.CallExpr))
Change-Id: I7a2a4efb569415256a8bc9350fb100bd2d8cfb39
Reviewed-on: https://go-review.googlesource.com/c/go/+/356311
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
SetImplicit() has an explicit meaning and really shouldn't be used in
this way - its use is left over from early prototype of the dictionary
code. Convert from using SetImplicit to just using a map during
traversal.
Change-Id: I3d257c101a859f000e159d7ced307d1b7cf990d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/356310
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Both netpollblock and netpollunblock read gpp using a non-atomic load.
When consuming a ready event, netpollblock clears gpp using a non-atomic
store, thus skipping a barrier.
Thus on systems with weak memory ordering, a sequence like so this is
possible:
T1 T2
1. netpollblock: read gpp -> pdReady
2. netpollblock: store gpp -> 0
3. netpollunblock: read gpp -> pdReady
4. netpollunblock: return
i.e., without a happens-before edge between (2) and (3), netpollunblock
may read the stale value of gpp.
Switch these access to use atomic loads and stores in order to create
these edges.
For ease of future maintainance, I've simply changed rg and wg to always
be accessed atomically, though I don't believe pollOpen or pollClose
require atomics today.
Fixes#48925
Change-Id: I903ea667eea320277610b4f969129935731520c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/355952
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
The go command no longer reports an error when invoked in a repository
nested inside another. This check is still used by 'go get' in GOPATH
mode when locating a repository, but it's not needed when preparing
the build stamp.
Fixes#49004
Change-Id: I4ed4dcc04174d2d42da8651d47e52ab1d7d66e35
Reviewed-on: https://go-review.googlesource.com/c/go/+/356309
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This pulls in some code and tests from CL 353355.
This change makes some refactors for when we read
to and write from memory during minimization.
That fixes a bug when minimizing interesting inputs.
Now, if an error occurs while minimizing an interesting
input, that value will continue to be minimized as a
crash, and returned to the user.
This change also allows minimization of a crash that
occurred during the warmup phase. We don't want to
minimize failures in the seed corpus, but if an entry
in the cache causes a new failure, then there's no
compelling reason why we shouldn't try to minimize it.
Fixes#48731
Change-Id: I7262cecd8ea7ae6fdf932f3a36db55fb062a1f2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/355691
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This CL fixes the subtle issue that Elem can promote a
not-in-heap pointer, which could be any bit pattern, into an
unsafe.Pointer, which the garbage collector can see. If that
resulting value is bad, it can crash the GC.
Make sure that we don't introduce bad pointers that way. We can
make Elem() panic, because any such bad pointers are in the Go heap,
and not-in-heap pointers are not allowed to point into the Go heap.
Update #48399
Change-Id: Ieaf35a611b16b4dfb5e907e229ed4a2aed30e18c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350153
Trust: Keith Randall <khr@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add a simple mechanism to provide formatted descriptions for
delayed actions. The comment strings are printed when tracing
is enabled and the delayed action is executed. This results
in more easily decipherable tracing output.
Requires debug mode in order to minimize the overhead during normal
execution. Use the mechanism in a few places to show typical use.
Also cleaned up a few unrelated comments.
Change-Id: Ic273c380c3963341500396ec62b694d143c25de2
Reviewed-on: https://go-review.googlesource.com/c/go/+/355871
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Modify the phase for creating needed function/method instantiations and
modifying functions to use those instantiations, so that the phase is
self-contained and can be called again after inlining. This is to deal
with the issue that inlining may reveal new fully-instantiated types
whose methods must be instantiated.
With this change, we have an extra phase for instantiation after
inlining, to take care of the new fully-instantiated types that have
shown up during inlining. We call inline.InlineCalls() for any new
instantiated functions that are created.
Change-Id: I4ddf0b1907e5f1f7d45891db7876455a99381133
Reviewed-on: https://go-review.googlesource.com/c/go/+/352870
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
This fixes a test failure on the 386-longtest builder.
For #37475
Change-Id: Icd1d3474968fcf85ef893190760fb488302abc3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/356209
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Same for Value.
Add a bigger test. Include some shouldPanic checks.
Fix a bug in assignment conversion.
Fixes#48294
Change-Id: Id863ee5122a5787a7b35574b18586fd24d118788
Reviewed-on: https://go-review.googlesource.com/c/go/+/356049
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Fixes a test failure in cmd/go TestScript/mod_outside.
make.bash (cmd/dist) builds everything with -gcflags=all= -ldflags=all=
by default. If those no-op flags aren't used, all GOROOT binaries
appear stale.
It's likely safe to omit those flags in cmd/dist if they're
empty. Checking out a new commit in GOROOT would always cause
staleness since the VCS info would change.
For #37475
Change-Id: Ic9aa0f3b7318e05fbb2f7d2c008ad07a4c61952f
Reviewed-on: https://go-review.googlesource.com/c/go/+/356014
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This CL fixes the debug/buildinfo test, which did not expect build settings.
For #37475
Change-Id: Ie8c15ec633b4eec6a976120c8db64f116589d98e
Reviewed-on: https://go-review.googlesource.com/c/go/+/356012
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
string(int) conversions are somewhat special and deserve an entry.
Change-Id: Ia68d047cfdb2f98e837bf663659f7f46404b16ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/355989
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This flag is not used anymore.
Change-Id: Id083ffa4f0a3051d3f1905a211db8acaaf525cf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/355931
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Test functions with type parameters cannot be invoked without type
arguments, so cmd/go would previously fail with a type-checking error in
the test harness.
Avoid this by producing an error explaining that test functions cannot
have type parameters.
Fixes#48953
Change-Id: I4e39c9b7a06c964fad5f12d74d262aa090c25d79
Reviewed-on: https://go-review.googlesource.com/c/go/+/355889
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Toolchain flags (like -gcflags), build tags (including race and msan),
and cgo variables (including CGO_ENABLED, CGO_CPPFLAGS and others) are
now stamped into binaries.
For #37475
Change-Id: I9023e682c0618f91805434946c6bc937536b69bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/355493
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When the go command builds a binary, it will now stamp the current
revision from the local Git or Mercurial repository, and it will also
stamp whether there are uncommitted edited or untracked files. Only
Git and Mercurial are supported for now.
If no repository is found containing the current working directory
(where the go command was started), or if either the main package
directory or the containing module's root directory is outside the
repository, no VCS information will be stamped. If the VCS tool is
missing or returns an error, that error is reported on the main
package (hinting that -buildvcs may be disabled).
This change introduces the -buildvcs flag, which is enabled by
default. When disabled, VCS information won't be stamped when it would
be otherwise.
Stamped information may be read using 'go version -m file' or
debug.ReadBuildInfo.
For #37475
Change-Id: I4e7d3159e1c270d85869ad99f10502e546e7582d
Reviewed-on: https://go-review.googlesource.com/c/go/+/353930
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The same code was copied into debug/buildinfo. 'go version' doesn't
need its own copy.
For #37475
Change-Id: I9e473ce574139a87a5f9c63229f0fc7ffac447a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/353929
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
BuildInfo now includes the version of Go used to build a binary, as
reported by runtime.Version() or 'go version'.
For #37475
Change-Id: Id07dda357dc70599d64a9202dab894c7288de1de
Reviewed-on: https://go-review.googlesource.com/c/go/+/353888
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
These functions provide access to module information stamped into Go
binaries. In the future, they'll provide access to other information
(like VCS info).
These functions are added in a new package instead of runtime/debug
since they use binary parsing packages like debug/elf, which would
make runtime/debug an unacceptably heavy dependency. The types in
runtime/debug are still used; debug/buildinfo uses them via type
aliases.
This information is already available for the running binary through
debug.ReadBuildInfo and for other binaries with 'go version -m', but
until now, there hasn't been a way to get it for other binaries
without installing cmd/go.
This change copies most of the code in cmd/go/internal/version. A
later CL will migrate 'go version -m' to use this package.
For #37475Fixes#39301
Change-Id: I0fbe0896e04f12ef81c6d79fb61b20daede86159
Reviewed-on: https://go-review.googlesource.com/c/go/+/353887
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Previously, modload.PackageBuildInfo returned a string containing
information about modules used to build an executable. This string is
embedded in the binary and can be read with debug.ReadBuildInfo or
'go version -m'.
With this change, debug.BuildInfo now has a MarshalText method that
returns a string in the same format as modload.PackageBuildInfo.
Package.load now calls Package.setBuildInfo, which constructs a
debug.BuildInfo, formats it with MarshalText, then sets
Package.Internal.BuildInfo. This is equivalent to what
modload.PackageBuildInfo did.
modload.PackageBuildInfo is deleted, since it's no longer used.
For #37475
Change-Id: I5875a98cb64737637fec2a450ab2ffa7f1805707
Reviewed-on: https://go-review.googlesource.com/c/go/+/353886
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
These tests are inherently nondeterministic: They exercise a racy
code path for up to one million iterations, and require that an
error occur at least once.
TestWaitGroupMisuse2 in particular is an ongoing source of trybot
flakiness.
Fixes#38163.
Change-Id: Ibbbda2c998c915333487ad262d3df6829de01c2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/340249
Trust: Damien Neil <dneil@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
This is a clean port of CL 355732 from types2 to go/types.
Fixes#48951.
Change-Id: I9f8cc0655166835d9450608f6e50b726659a73f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/355733
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The algorithm for detecting invalid recursive types that
expand indefinitely suffered from the exact problem is was
intended to detect: if the indefinite expansion is happening
through type parameters, the algorithm ended up in an infinite
sequence of instantiations. (This is only a problem for generic
types).
Changed the algorithm to always only consider the "original"
uninstantiated types. This avoids the problem but it will also
not detect some invalid recursive generic types anymore. That
requires a more sophisticated type flow analysis.
Opened #48962 to track.
Addressed with help from @findleyr.
For #48951.
Change-Id: Ie29cea8f810dae55153dbb1b17c9390cd823c2d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/355732
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Use fcntl(oldfd, F_DUP2FD_CLOEXEC, newfd) to duplicate the file
descriptor and mark is as close-on-exec instead of dup2 & fcntl.
FreeBSD implements dup3 like this in libc.
Change-Id: I36e37bc61c2e31561adb49001f287764125a74de
Reviewed-on: https://go-review.googlesource.com/c/go/+/355571
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
To allow adding fields to ProcSysAttr which are supported on FreeBSD but
not on other BSDs.
For now exec_freebsd.go is an exact copy of exec_bsd.go with adjusted
build tags and copyright year.
For #46258
For #46259
Change-Id: I7667a0cdf1ca86ef64a147b77c06db70c5f8eb90
Reviewed-on: https://go-review.googlesource.com/c/go/+/355569
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before the 1.12 release the use of linkname did not prevent a compiler
error for an empty function body (see #23311). Add some build tags so
that cmd/link will build with earlier releases.
It's true that we currently require Go 1.16 as the bootstrap compiler (#44505).
But for this simple case keep things working with older compilers for now.
Change-Id: I67fe021406096c64c01d6e2c9adbcc4388988a6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/355690
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The respective issue has been accepted, so we can always
accept constraint literals with omitted interfaces.
For #48424.
Change-Id: Ia3d325401252a5a22d5ffa98d2ae6af73178dec0
Reviewed-on: https://go-review.googlesource.com/c/go/+/355709
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
On riscv5, apparently extra wrappers (trampolines) are created for some
functions with the suffix "-tramp". Modify inst_test.go to not match
these "-tramp" wrappers.
Change-Id: I754c724f03555c30f8e1b5cfc08152555bbbcf17
Reviewed-on: https://go-review.googlesource.com/c/go/+/355650
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
This reduces the number of branches to bounds check non-empty slices
from 5 to 3. It does also increase the number of branches to handle
empty slices from 1 to 3; but for non-panicking calls, they should all
be predictable.
Updates #48798.
Change-Id: I3ffa66857096486f4dee417e1a66eb8fdf7a3777
Reviewed-on: https://go-review.googlesource.com/c/go/+/355490
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Allow the user to construct slices that are larger than the Go heap as
long as they don't overflow the address space.
Updates #48798.
Change-Id: I659c8334d04676e1f253b9c3cd499eab9b9f989a
Reviewed-on: https://go-review.googlesource.com/c/go/+/355489
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change allows httputil.ReverseProxy to detect SSE (server-sent events)
content when the response's Content-Type header includes MIME parameters,
such as "text/event-stream;charset=utf-8".
Prior to this change the value of the Content-Type header was compared
directly to the literal "text/event-stream". This caused a false-negative
which failed to set the FlushInterval correctly when MIME parameters were
present.
Change-Id: If8bb43efb78787b6519d7fe7599ca018a0da0023
GitHub-Last-Rev: 224518c5eb
GitHub-Pull-Request: golang/go#48427
Reviewed-on: https://go-review.googlesource.com/c/go/+/350509
Trust: Alexander Rakoczy <alex@golang.org>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
This test seems only to be testing that Dial does not time out
immediately as a result of integer overflow; the precise time taken to
connect is immaterial. Replace naked loop with sub-tests.
Fixes#43069.
Change-Id: Ib5e38a1d8cd191b74c2bc7c26bef57b180e16f68
Reviewed-on: https://go-review.googlesource.com/c/go/+/355390
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
darwin already supports syscall.Sendfile.
Change-Id: Id3db06591ffad0550b4173bacddeb0acfe355f9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/355109
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
If sep does not appear in s, we return nil here
rather than the empty string. Presumably the docs
were copied from the strings package implementation
and brought that along.
Change-Id: I3706c94fe04abd9e2a2c8840f7cc6116386965c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/354969
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Fixes#48848
Change-Id: If85fc16ed10a26eca840ed128ab47c5f00776ddd
Reviewed-on: https://go-review.googlesource.com/c/go/+/346289
Reviewed-by: Amelia Downs <adowns@vmware.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
When a process is forcefully killed (for example, with SIGKILL on unix), its ProccessState.Exited() will return false.
Change-Id: I8cebc8d28f2ba1b687c145f6d941647fc3a10665
GitHub-Last-Rev: 414ae1980f
GitHub-Pull-Request: golang/go#48871
Reviewed-on: https://go-review.googlesource.com/c/go/+/354698
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Pull in the latest published version of github.com/google/pprof
This adds the tagroot and tagleaf options from
7fe48b4c82
Done with:
go get -d github.com/google/pprof@latest
go mod tidy
go mod vendor
Fixes#48839
Change-Id: I85bf0e0689310014eb198c8d5e0bb3a86b0aef1c
GitHub-Last-Rev: b26260f305
GitHub-Pull-Request: golang/go#48856
Reviewed-on: https://go-review.googlesource.com/c/go/+/354692
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
When build with "-linkshared", we can't tell if the interface method will be used or not. It can be used in shared library.
Fixes#47873
Change-Id: Iba12812f199b7679cf2fd41a304268d6d6dd03c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/350189
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Change-Id: I4e50e469047ac7efbf4ed464e238000dbdf53d6b
GitHub-Last-Rev: 8d29b73d11
GitHub-Pull-Request: golang/go#48785
Reviewed-on: https://go-review.googlesource.com/c/go/+/353936
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Corrections were only made to comments and can be reproduced with the
following sed.
sed -i 's/communciation/communication/g' src/internal/fuzz/sys_windows.go
sed -i 's/communciation/communication/g' src/internal/fuzz/sys_posix.go
sed -i 's/substitued/substituted/g' src/cmd/compile/internal/noder/irgen.go
Change-Id: I435aee2fdb41e73b694e6233d52742559d32cf7e
GitHub-Last-Rev: a471e3d123
GitHub-Pull-Request: golang/go#48932
Reviewed-on: https://go-review.googlesource.com/c/go/+/355494
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Go back to allowing spaces in types.(*Type).LinkSring().
Delve folks prefer that there are spaces in type names, if needed, since
DWARF expects type names to be "a string representing the name as it
appears in the source program". At this point, it doesn't necessarily
seem worth having a separate function that removes spaces, only for use
when printing the type names in a function/method instantiation.
Most names of function/method instantiations will still not have spaces,
since they most type args are named or builtin types. I confirmed that
we are back to the original definition of LinkString(), except for some
comment changes.
Change-Id: Iab7143f659ddea4f099c6230cb134edf8aaef868
Reviewed-on: https://go-review.googlesource.com/c/go/+/355354
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Changing type parameter names is not a breaking API change, so we should
not include these names in the output of cmd/api. Instead print a
placeholder '$<index>' wherever type parameters are referenced.
This is valid for cmd/api as there is at most one type parameter list in
scope for any exported declaration. If we ever support method type
parameters, we'll need to revisit this syntax.
Change-Id: I7e677b1dab6ffeb0b79afefdb8d2580bef93891c
Reviewed-on: https://go-review.googlesource.com/c/go/+/355389
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: Ib7cc86643a3dcae788a94472e54de171e0d655fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/355449
Trust: Michael Pratt <mpratt@google.com>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This should be a no-op, but if the sharded builders are for some
reason distributing stale snapshots — or testing them with mismatched
environments — this should catch them out at a relatively low cost
(#24300 notwithstanding).
Given the frequently at which (*tester).runPending already checks for
staleness, we do not expect the impact of this extra check to be
significant for most builders.
For #33598
Updates #24300
Change-Id: I197d6a69c72e2eec9e4563b459206de76c89e8a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/223755
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Add a test for a generic sort function, operating on several different
pointer types (across two packages), so they should all share the same
shape-based instantiation. Actually check that only one instantiation of
Sort is created using 'go tool nm', and also check that the output is
correct.
In order to do the test on the executable using 'go nm', added this as a
'go test' in cmd/compile/internal/test.
Added the genembed.go test that I meant to include with a previous CL.
Change-Id: I9962913c2f1809484c2b1dfef3b07e4c8770731c
Reviewed-on: https://go-review.googlesource.com/c/go/+/354696
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
T.Run uses a map[string]int64 to keep track of subtest names that may
be returned through T.Name. T.Name can't return duplicate names for
subtests started with T.Run.
If a fuzz target calls T.Run, this map takes a large amount of memory,
since there are a very large number of subtests that would
otherwise have duplicate names, and the map stores one entry per subtest.
The unique suffixes are not useful (and may be confusing) since the
full sequence of tests cannot be re-run deterministically.
This change deletes all entries in the map before each call to the
function being fuzzed. There is a slight change in the contract of
T.Name while fuzzing.
This change was discussed in CL 351452.
Fixes#44517
Change-Id: I3093a2e5568099ce54aca1006fac84a6fd2c3ddf
Reviewed-on: https://go-review.googlesource.com/c/go/+/354430
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
In the case in (*TSubster).Type() that we were running into an
incomplete underlying type (TFORW), we should just be immediately
returning the type returned by ts.SubstForwFunc(forw), since that call
returns a proper type node, and has set up any remaining work that has
to be done when we get done with the current top-level type definition.
(For import, that function is doInst, which does an Instantiate of the
new substituted type, with the delayed part via deferredInstStack.) We
should not continue doing the later parts of (*TSubster).Type(), since
the underlying type may not yet have its methods filled in, etc.
Also, in Instantiate(), we need to put the desired new type on
deferredInstStack, even if the base type node already exists, if the
type node is in TFORW state. This is now exactly the case when
Instantiate is called from (*TSubster).Type via doInst, since
(*TSubster).Type has already called NewIncompleteNamedType().
Fixes#48716Fixes#48889
Change-Id: Icd6be5721c4ac75bf8869b8bbdeca50069d632ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/355250
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This change resolves a TODO regarding a couple uncertain APIs for
types.TypeParam. In the case of TypeParam._Index, we've decided it is
worth exporting. In the case of TypeParam._SetId, we've decided it is
unnecessary.
This aligns go/types with types2 (a doc comment in types2 is also
updated).
Updates #47916
Change-Id: I705e8b3437d014775c473e2f8be6f32b1540bb0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354370
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In module-aware mode, 'go get' no longer builds or installs packages.
- 'go generate' explains build commands do not run generate
commands. 'go get' is no longer a build command, so this CL removes
mention of it.
- 'go get' will continue to accept build flags, but they're
ignored. The documentation no longer mentions them, though it does
mention -x for printing VCS commands.
For #43684
Change-Id: I1eea7241eecf72ba9f98238b729d91cc77ec7665
Reviewed-on: https://go-review.googlesource.com/c/go/+/355209
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
We reuse a value for the same selector on the same arg. But if the
value is already marked dead, don't reuse it. A use of an
OpInvalid will confuse the compiler.
Fixes#48916.
Change-Id: I15b9e15b49f6e1991fe91df246cd12a193385e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/355409
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change fixes some issues with -run, and
the subsequent command line output when running
in verbose mode. It replaces CorpusEntry.Name
with CorpusEntry.Path, and refactors the code
accordingly.
This change also adds a lot of additional tests
which check explicit command line output when
fuzz targets are run without fuzzing. This will
be important to avoid regressions.
Updates #48149
Change-Id: If34b1f51db646317b7b51c3c38ae53231d01f568
Reviewed-on: https://go-review.googlesource.com/c/go/+/354632
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Insert machine NOPs when a prefixed instruction crosses a 64B boundary.
ISA 3.1 prohibits prefixed instructions being placed across them. Such
instructions generate SIGILL if executed.
Likewise, adjust the function alignment to guarantee such instructions
can never cross one. And, don't pad the PC based on alignment. The
linker can fit these more optimally.
Likewise, include the function alignment when printing function debug
information. This is needed to verify function alignment happens.
Updates #44549
Change-Id: I434fb0ee4e984ca00dc4566f7569c3bcdf93f910
Reviewed-on: https://go-review.googlesource.com/c/go/+/347050
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
The TestStartsWithClearCode test is new, but if it existed beforehand,
the want strings would be "\x81" and "Hi\x81" without a starting "\x80".
Fixes#26108Fixes#33748
Updates makeworld-the-better-one/didder#7
Updates nothings/stb#1222
Change-Id: I35ac0ed862ba6ee921ba9aee257bc19828abaa82
Reviewed-on: https://go-review.googlesource.com/c/go/+/354710
Trust: Nigel Tao <nigeltao@golang.org>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Direct syscalls are no longer supported on darwin. Instead, use libc
fcntl go:linkname'd from the syscall package.
Change-Id: Ieeec64810452455faedd200f661a8b5839ca1fa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/255260
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Fixes#48706
Change-Id: If0f8d0b49300027e3b2b46f6870302acf2e00f4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354612
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Resolve a TODO from an earlier CL: we should only check type parameter
bounds once in collectTypeParams.
Change-Id: Icf6053ec359f8ac8143cf68ee2defd504f8f86e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/355069
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a straightforward port of CL 353396 to go/types.
For #48424
Change-Id: I3040c2ad3a8c9573026277de01deb9c47953cec8
Reviewed-on: https://go-review.googlesource.com/c/go/+/354991
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a partial revert of CL 353389, now that go/types supports
eliding interface in constraints.
For #48424
Change-Id: Ibde26fb66bf6bd5a4c919acffd045a57783d1b47
Reviewed-on: https://go-review.googlesource.com/c/go/+/354990
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 353139 to go/types, adjusted for error reporting
and for the different representation of field lists in go/ast. A TODO is
added to verify if types2 produces redundant error messages for type
parameters sharing a bound.
For #48424
Change-Id: I3549942be0328de616d1d87d0ba621311fc53576
Reviewed-on: https://go-review.googlesource.com/c/go/+/354989
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 353133 from cmd/compile/internal/syntax, with
significant adjustments for the mechanics of go/parser.
Some additional cleanup is made along the way: parseParameterList can
call parseParamDecl without indirection, and the tparams argument is
redundant with the closing token. Also, the error that "all type
parameters must be named" is positioned on the first unnamed type
parameter.
Error recovery in go/parser is notably worse here than the compiler
parser, so the test data had to be adjusted to synchronize positions.
Fixing this error recovery will have to wait for a later CL.
As with the compiler changes, these changes are guarded behind a flag so
that they may be easily removed if #48424 is not accepted.
For #48424
Change-Id: If87925d246f36aaab11a95442f75f659462d4286
Reviewed-on: https://go-review.googlesource.com/c/go/+/354870
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The docs say:
If the input is at EOF, Decode returns io.EOF and does not modify e.
However, the added test fails:
--- FAIL: TestDecodePartial (0.00s)
encoder_test.go:1263: 31/81: expected io.ErrUnexpectedEOF: EOF
encoder_test.go:1263: 51/81: expected io.ErrUnexpectedEOF: EOF
In particular, the decoder would return io.EOF after reading a valid
message for a type specification, and then hit EOF before reading a data
item message.
Fix that by only allowing a Decode call to return io.EOF if the reader
hits EOF immediately, without successfully reading any message.
Otherwise, hitting EOF is an ErrUnexpectedEOF, like in other cases.
Also fix a net/rpc test that, coincidentally, expected an io.EOF
as an error when feeding bad non-zero data to a gob decoder.
An io.ErrUnexpectedEOF is clearly better in that scenario.
Fixes#48905.
Change-Id: Ied6a0d8ac8377f89646319a18c0380c4f2b09b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/354972
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This changes debug/gosym so it can deal with instantiated
types/funcs/methods. I also added tests for instantiated names. My
assumption is that the concatenation of PackageName, ReceiverName, and
BaseName in order should cover the entire symbol name, so either the
ReceiverName or the BaseName should include any bracketed information
(either the instantiation of the receiver of a method or the
instantiation of function).
This can provide a model for how to parse instantiated functions and
method names.
Fixes#48032
Change-Id: I476781de2d6fc096efbb4be85c197d6f1cafac21
Reviewed-on: https://go-review.googlesource.com/c/go/+/354689
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This reverts CL 351851, which itself reverted CL 348991.
The problem with the original CL, as far as I can tell, was due to a
bug in the Go project's builder infrastructure (#33598) and not the
change itself. Once the build infrastructure is fixed, this change
can be resubmitted.
Fixes#48319
Updates #33598
Change-Id: I0fdbcc241eb2bdeb350944aad58bf58774fb591e
Reviewed-on: https://go-review.googlesource.com/c/go/+/353352
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
It turns out there is no real TODO here - things are working fine. If we
are generating a wrapper for a method on a generic type that is actually
the method on embedded type, then we should just just generate the
normal embedded wrapper, which calls the wrapper for the real receiver
type on that method. There is no need to do the generic path where we
add in the dictionary argument. So, just updated that TODO comment with
this explanation.
Added a new test case embedded.go, which specifically tests various
situations involving converting to empty and non-empty interfaces.
issue44688.go already tests a bunch of these situations as well.
Also made some other cleanups in reflect.go:
- The shape test (that I had added) at the top of imethods is useless
(never true), since it is always an interface type, so removed it.
- Added usual helper function deref() to make code clearer in several
places.
- The shape test in methodWrapper() doesn't have to check HasShape() on
each targ - it can just check HasShape() on the whole receiver.
- The comment about disabling the tail call optimization for RegABI is
no longer true.
- Simplified code in several places by using the value of existing
variable 'methodrcvr'.
Change-Id: I8b1a5dc518dad37585824a1f73ceebb7627a9f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/355129
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Now that x/tools/go/types/objectpath has been updates to support type
parameters, I ran the following commands to update x/tools inside the
cmd module:
go get -d golang.org/x/tools@18fa840216958359dc43466f3e70d96add38edbb # main branch
go mod tidy
go mod vendor
Updates #48588
Change-Id: Ibebc1ac2f721d6e2eb1a4f6c610918770d4879ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/355012
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Fix "MOVW CRx, Rx" and "MOVFL Rx, constant", The FXM field was not
encoded correctly.
Generate mtocrf instead of mtcrf when a CRx argument is used. This
form is much faster.
Simplify several conditional statements which test if the register
argument is REG_CR or one of REG_CRx if the tested argument is known
to be matched as C_CREG. Likewise, a4 is (the From3 arg) is always
TYPE_NONE in the existing optab entries for type_ 69.
Change-Id: I3a4749b1cbfdfab6a2616586ae59e932e01dae50
Reviewed-on: https://go-review.googlesource.com/c/go/+/352789
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
With multiple text sections, there may be holes (non-Go code) in
the PC range of Go code and covered by the functab. Previously, we
use a linear search with actual PCs to find the functab entry. We
need to use special entries to mark holes, so a PC in the hole can
be distinguished from the previous function.
Now, with the previous CL we find if the PC is in between of the
sections upfront in textOff. There is no need to mark holes in the
functab.
Change-Id: I22ff27279422bfc855c2ca35ba0fdfb63234c113
Reviewed-on: https://go-review.googlesource.com/c/go/+/354874
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
In findfunc, we first us the relative PC to find the function's
index in functab. When we split text sections, as the external
linker may shift the sections, and the PC may not match the
(virtual) PC we used to build the functab. So the index may be
inaccurate, and we need to do a (forward or backward) linear
search to find the actual entry.
Instead of using the PC directly, we can first compute the
(pre-external-link virtual) relative PC and use that to find the
index in functab. This way, the index will be accurate and we will
not need to do the special backward linear search.
Change-Id: I8ab11c66b7a5a3d79aae00198b98780e10db27b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/354873
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
What should it mean to run a regexp match on invalid UTF-8 bytes?
The coherent behavior options are:
1. Invalid UTF-8 does not match any character classes,
nor a U+FFFD literal (nor \x{fffd}).
2. Each byte of invalid UTF-8 is treated identically to a U+FFFD in the input,
as a utf8.DecodeRune loop might.
RE2 uses Rule 1.
Because it works byte at a time, it can also provide \C to match any
single byte of input, which matches invalid UTF-8 as well.
This provides the nice property that a match for a regexp without \C
is guaranteed to be valid UTF-8.
Unfortunately, today Go has an incoherent mix of these two, although
mostly Rule 2. This is a deviation from RE2, and it gives up the nice
property, but we probably can't correct that at this point.
In particular .* already matches entire inputs today, valid UTF-8 or
not, and I doubt we can break that.
This CL adopts Rule 2 officially, fixing the few places that deviate from it.
Fixes#48749.
Change-Id: I96402527c5dfb1146212f568ffa09dde91d71244
Reviewed-on: https://go-review.googlesource.com/c/go/+/354569
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Eliminate an unnecessary argument from parseGenericType, and replace an
if statement with a switch.
Change-Id: Iaa8afeface929332579f183c8e523961cca9aca4
Reviewed-on: https://go-review.googlesource.com/c/go/+/354869
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The assembler does not support parsing DCRx registers,
nor does the compiler generate opcodes with these.
Likewise, these registers are only available on ISA
2.07 embedded processors which are not supported in
golang.
Change-Id: Iea258e5958a2022bda0eee8348de1b06437148df
Reviewed-on: https://go-review.googlesource.com/c/go/+/352790
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Uses one less byte when encoded. Performance is unchanged.
Change-Id: If400c9c9fc07a033e5ae9bf975ec512e432f7825
Reviewed-on: https://go-review.googlesource.com/c/go/+/354949
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
dependency
XORL accomplishes the same thing while being shorter to encode.
Change-Id: I4397999ff617edb61a7fb7d1eca757a202ab8134
Reviewed-on: https://go-review.googlesource.com/c/go/+/354832
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
NOT does not affect any FLAGS register values on i386/AMD64 so we do not
need to mark it as an Op that clobbers them.
Change-Id: I6d99cad49cfa2568b01e58190256582b18fb3b7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/354831
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
The code generated when storing eight bytes loaded from memory in big
endian introduced two successive byte swaps that did not actually
modified the data.
The new rules match this specific pattern both for amd64 and for arm64,
eliminating the double swap.
Fixes#41684
Change-Id: Icb6dc20b68e4393cef4fe6a07b33aba0d18c3ff3
Reviewed-on: https://go-review.googlesource.com/c/go/+/320073
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
The double suffix doesn't seem to serve any purpose, and we can keep
the old spelling as a backwards compatible alias in cmd/asm.
Change-Id: I3f01fc7249fb093ac1b25bd75c1cb9f39b8f62a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/354700
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Empirically, it may take more than 3 seconds for minimization to begin.
If that is the case, the "elapsed:" message may start at 4s or higher.
Fixes#48870
Change-Id: I6bb4367b61377454b0af664d80232fdb46e7c245
Reviewed-on: https://go-review.googlesource.com/c/go/+/354794
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The illumos builder is using a Go 1.18 prerelease toolchain for
bootstrapping, which doesn't have ast.IndexListExpr. But we can
instead check for the "compiler_bootstrap" build tag that's already
used for distinguishing binaries built for toolchain1.
Fixes#48863.
Change-Id: I87b672322eee22a60ab8d0bb3be5f76cffc97545
Reviewed-on: https://go-review.googlesource.com/c/go/+/354695
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A stack object record may refer to the object's type's GC mask or
GC program (for very large types). For the latter, currently the GC
program symbol is named "type..gcprog.XXX" which is then laid out
along with type symbols at link time. When relro is used, the type
symbols end up in a different section.
As we now use relative addressing for stack object records to refer
to GC masks or GC programs, it is important that it is laid out in
the rodata section (not rodata.rel.ro). Move GC program symbols to
be along with GC masks, as they are similar and accessed the same
way. They don't have relocations so they don't need to be laid to a
relro section.
This fixes flaky failures like
https://build.golang.org/log/3bdbaaf786ec831b4393a64a959d2130edb5e050
Change-Id: I97aeac1234869da5b0f3a73a3010513d6a3156c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/354793
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The fix for #48807 in CL 354429 forgot that we also need to fix
the softfloat implementation.
Update #48807
Change-Id: I596fb4e14e78145d1ad43c130b2cc5122b73655c
Reviewed-on: https://go-review.googlesource.com/c/go/+/354613
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
See also CL 354693.
Change-Id: Id7579c5f7d486652a5b53b29663a6573a493121f
Reviewed-on: https://go-review.googlesource.com/c/go/+/354694
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a port of CL 354643 from go/types to types2 with adjustments:
- use of syntax rather than go/ast package as needed
- adjustments due to the different code for type parameter declarations
- rename of Checker.rparamMap to Checker.recvTParamMap, which seems clearer
Change-Id: I5311a0c05a13c6b87ea1422b250b90c3d05c5dce
Reviewed-on: https://go-review.googlesource.com/c/go/+/354693
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For this unusual case, where a constraint specifies exactly one type, we
can have a COMPLIT expression with a type that is/has typeparams.
Therefore, we add code to delay transformCompLit for generic functions.
We also need to break out transformAddr (which corresponds to tcAddr),
and added code for delaying it as well. Also, we now need to export
generic functions containing untransformed OCOMPLIT and OKEY nodes, so
added support for that in iexport.go/iimport.go. Untransformed OKEY
nodes include an ir.Ident/ONONAME which we can now export.
Had to adjust some code/asserts in transformCompLit(), since we may now
be transforming an OCOMPLIT from an imported generic function (i.e. from
a non-local package).
Fixes#48537
Change-Id: I09e1b3bd08b4e013c0b098b8a25d082efa1fef51
Reviewed-on: https://go-review.googlesource.com/c/go/+/354354
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
We've decided to leave TParams on FuncType, and type list syntax is
no longer part of the proposal.
Change-Id: Id34f6495a358d76994df331384a4b93487275c4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/354751
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
ParseDuration should handle minimum int64 (-1<<63) nanosecond
since type Duration is alias of int64
name old time/op new time/op delta
ParseDuration 91.4ns ± 0% 86.4ns ± 1% -5.49% (p=0.000 n=9+8)
Fixes: #48629
Change-Id: I81b7035b25cefb4c1e5b7801c20f2d335e29358a
Reviewed-on: https://go-review.googlesource.com/c/go/+/352269
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Receiver type parameters are the only type expressions allowed to be
blank. Previously this was handled by substitution of synthetic
non-blank names in the receiver type expression, but that introduced
problems related to AST mangling: the scope had extra elements,
Object.Name() was inaccurate, and synthetic nodes were recorded in
types.Info.
Fix this instead by recording a map of *ast.Ident->*TypeParam on the
Checker, which is read in Checker.ident to resolve blank identifiers
denoting receiver type parameters.
Change-Id: I6a7a86b823409f54778c0f141e8bd269a2cc85d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/354643
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
PNG images can be paletted, where each pixel value (a uint8) indexes a
slice of colors. In terms of wire format, the PLTE chunk explicitly
contains the palette length. However, in practice, some arguably
malformed images contain pixel values greater than or equal to the
explicit PLTE length.
Go's image/png decoder accomodates such images by lengthening the
decoded image's palette if the implicit maximum is larger than the
explicit maximum. This was already done, prior to this commit, by the
"if len(paletted.Palette) <= int(idx)" lines in decoder.readImagePass.
Separately, PNG images can also be interlaced, where the final image is
the result of merging multiple partial images, also called passes. Prior
to this commit, we applied the palette lengthening to the pass images
but not the final image. This commit fixes that.
Fixes#48612
Change-Id: I77606538cc9a504fbd726071756ebcd10c9da73f
Reviewed-on: https://go-review.googlesource.com/c/go/+/354709
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This is a port of CL 354690 from types2 to go/types.
Change-Id: I50e7297a67e37d261335260e285b9cb1c0d2a62d
Reviewed-on: https://go-review.googlesource.com/c/go/+/354691
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The "fix" (CL 352832) for #48619 was incorrect and broke
the unification algorithm in some cases (e.g., #48695).
This CL reverts the changes made by CL 352832 to unify.go,
and comments out code in corresponding tests.
As a result, #48695 will be fixed, and we will re-open #48619.
Fixes#48695.
For #48619.
For #48656.
Change-Id: I91bc492062dbcc8dae7626f6b33f6dfabf48bcb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/354690
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When we have multiple text sections, we need to mark holes between
the sections in the functab. A hole is marked with an entry with
the end PC of the previous section. As we now use offsets instead
of (relocated) PCs, the end offset of a section may be the same of
the start of the next one. Distinguish it by using the end address
-1.
For #48837.
Change-Id: I121aac53b32a869378632cf151cb1b6f98ad3089
Reviewed-on: https://go-review.googlesource.com/c/go/+/354636
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
As the func table contains the end marker of the text section, we
sometimes need to get that address from an offset. Currently
textAddr doesn't handle that address, as it is not within any
text section. Instead of letting the callers not call textAddr
with the end offset, just handle it more elegantly in textAddr.
For #48837.
Change-Id: I6e97e455f6cb66e9680a7aac6152ba6f4cda2e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/354635
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Like with -benchtime=1ns, if we find that the "discovery" round (run1)
has already crossed the -benchtime threshold, we skip running more
iterations.
Fixes#32051
Change-Id: I76aaef2ba521ba8ad6bbde2b14977e191aada5e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/331089
Trust: Caleb Spare <cespare@gmail.com>
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Change to using types.(*Type).LinkString() for printing names of types
in function/method instantiations. (e.g. f[int] or Value[p.Myint].Set())
LinkString already generates a unique string description for t, using
package paths, except that it uses "" for the local package path. The ""
will be expanded in the linker, so the names in the executable will have
full package paths everywhere and de-duplication of function/method
instantiations will work properly. We do need to add an explicit
substitution of "" in ReadImports() for function/method names. We
previously were using NameString(), which doesn't use full package
paths, so is not fully unique.
We had also discussed that we would prefer to minimize spaces in
function/method instantiation names. So, I changed LinkString() to
eliminate all unneeded spaces. In the one case where we need a
separator, which is between field names and types, we use a "#" instead
of a space.
This change has the advantage of eliminating spaces in some existing
non-generic function name - mainly .type.eq functions for anonymous
types (e.g. "type..eq.struct { runtime.gList; runtime.n int32 }") shows
up in a hello-world executable (as Cherry pointed out).
We do not need an analogous function for types2 right now, since we
create all instantiations using types1 types. In the one case where we
need to create an instantiation during types2-to-types1 translation, we
convert the types to types1 first (see (*irgen).instTypeName2).
Change-Id: Iac4748fa0d0d6f89af59bd51076266986daee945
Reviewed-on: https://go-review.googlesource.com/c/go/+/353609
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previously, when fuzzing for a period of time, the
command line output would look something like this:
fuzz: minimizing 34995-byte crash input...
fuzz: elapsed: 3s, execs: 13821 (4604/sec), new interesting: 0 (total: 1)
fuzz: elapsed: 6s, execs: 13821 (2303/sec), new interesting: 0 (total: 1)
fuzz: elapsed: 9s, execs: 13821 (1535/sec), new interesting: 0 (total: 1)
--- FAIL: FuzzFoo (9.05s)
This is the same output it has while fuzzing, so if
minimization runs for a long time (default allows 1
minute), then it looks like minimization is hanging.
It's also confusing that the execs/sec would continually
decrease.
Now, when minimization is running, the command line
output will look something like this:
fuzz: minimizing 34995-byte crash input...
fuzz: elapsed: 3s, minimizing
fuzz: elapsed: 6s, minimizing
fuzz: elapsed: 9s, minimizing
fuzz: elapsed: 9s, minimizing
--- FAIL: FuzzFoo (9.05s)
The final "fuzz: elapsed: 6s, minimizing" could be
printed twice because we always print one final log
to the command line before we exit.
Updates #48820
Change-Id: Ie5b9fde48b8d4e36e13a81ae50a6d69bf4d0dbe3
Reviewed-on: https://go-review.googlesource.com/c/go/+/354371
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
CL 315281 changed the os package use wait6 on netbsd. This seems to be
causing frequent test failures as reported in #48789. Revert that change
using wait6 on netbsd for now.
Updates #13987
Updates #16028
For #48789
Change-Id: Ieddffc65611c7f449971eaa8ed6f4299a5f742c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/354249
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing implementation lacks consideration of running test on a
machine which has ipv6 address but no ipv4 address. Use net.IP.IsLoopback
and net.IP.IsUnspecified instead of hardcoded addresses.
Fixes: #48575
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
Change-Id: I9c3c26d2ba13c7a24065751b59a1e002098ed654
GitHub-Last-Rev: fc45adbf7b
GitHub-Pull-Request: golang/go#48850
Reviewed-on: https://go-review.googlesource.com/c/go/+/354609
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
On Wasm, wasm_exec.js puts command line arguments at the beginning
of the linear memory (following the "zero page"). Currently there
is no limit for this, and a very long command line can overwrite
the program's data section. Prevent this by limiting the command
line to 4096 bytes, and in the linker ensuring the data section
starts at a high enough address (8192).
(Arguably our address assignment on Wasm is a bit confusing. This
is the minimum fix I can come up with.)
Thanks to Ben Lubar for reporting this issue.
Fixes#48797
Fixes CVE-2021-38297
Change-Id: I0f50fbb2a5b6d0d047e3c134a88988d9133e4ab3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1205933
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/354571
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The old way of implementing it, float32(float64(x)), involves 2 roundings
which can cause accuracy errors in some strange cases. Implement a runtime
version of [u]int64tofloat32 which only does one rounding.
Fixes#48807
Change-Id: Ie580be480bee4f3a479e58ef8dce23032f231704
Reviewed-on: https://go-review.googlesource.com/c/go/+/354429
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Allows cgo to work with generics.
Updates #47781.
Change-Id: Id1a5d1a0a8193c5b157e3e671b1490d687d10384
Reviewed-on: https://go-review.googlesource.com/c/go/+/353882
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The CL 349613 causes this problem.
In fact, we want to use the outer i to find m.List[i],
but the newly created index variable i in the nearest
for range shadow the outer i.
Fixes#48838.
Change-Id: I10f0bd985340f9443eefaadda6fc56e4e7e9a10c
Reviewed-on: https://go-review.googlesource.com/c/go/+/354549
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
This is port of CL 354049 for types2 to go/type.
The change is identical, but for some tweaks to the error message/position
in tests, since when go/types reports the exact operation "cannot convert"
instead of the general "invalid operation" like types2.
Updates #48784
Change-Id: I3e99f2721501d23187fd0a8970eb1de28e0c41d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/354050
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In case of an invalid untyped nil conversion, the compiler's original
type checker leaves it to the caller to report a suitable error message.
But types2 does not, it always reports the invalid conversion.
CL 328053 made types2 report a better error message, and match the
original compiler behavior. But it ignored the case of untyped nil.
This CL adds that missing case, by checking whether the two operands can
be mixed when untyped nil is present.
Fixes#48784
Change-Id: Idc7d86eb0245aa18ca428e278f4416d6b3679058
Reviewed-on: https://go-review.googlesource.com/c/go/+/354049
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a port of CL 354432 from types2 to go/types
with minor adjustments:
- an error message has a different position
- the constraint literals are wrapped in interfaces
because the interface-free notation has not been
ported yet
Change-Id: I167094b57b39027566f2b7ce3aa97a071bae4da5
Reviewed-on: https://go-review.googlesource.com/c/go/+/354489
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For now, the underlying types of the the argument types' constraints
must be a single type that is a slice (the source operand may also
be a string).
Change-Id: I9e705e3349c9242f126b9c3e0af65e9ffb25fe6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354432
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The (*http.Cookie).String method used by SetCookie will silently discard
or sanitize any fields it deems invalid, making it difficult to tell
whether a cookie will be sent as expected.
This change introduces a new (*http.Cookie).Valid method which may be
used to check if any cookie fields will be discarded or sanitized prior
to calling (*http.Cookie).String.
Fixes#46370
Change-Id: I2db80078de190d267a9c675a9717c8be8acc8704
Reviewed-on: https://go-review.googlesource.com/c/go/+/338590
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
I've noticed for a while that there is some duplicated and some useful
information being put out in -W=3 mode after the comment marker (besides
the position).
dumpNodeHeader puts out a comment marker '#' before putting out the
position of a node (which is for almost all nodes). Therefore, we shouldn't
print out anything on the same line after calling dumpNodeHeader().
But we happen to be putting out a duplicate type of the node in some
cases. Also, we put out the Sym() associate with the node after
dumpNodeHeader(). So, I got rid of the duplicate type print-out, and moved
the print-out of n.Sym() to be inside dumpNodeHeader() before the
position information. Also, moved the tc flag to be right after the type
information, which seems like it makes more sense.
Change-Id: I05210fbf9f3b2d8e3b73fc0ceab26a7bce5dc104
Reviewed-on: https://go-review.googlesource.com/c/go/+/354355
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TestTicker is sensitive to overloaded or slow systems, where a 20ms
ticker running for 10 ticks has a total run time out of the range
[110ms, 290ms]. To counter this flakiness, it tries five times to
get a successful result. This is insufficient--an overloaded test
machine can introduce more than 100ms of delay across the test.
Reduce the five attempts to two, but use a 1s ticker for 8 ticks
in the second attempt.
Updates #46474.
Updates #35692.
Change-Id: Ibd5187b00ccceeb981b652f2af9a1c3766357b78
Reviewed-on: https://go-review.googlesource.com/c/go/+/339892
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use typecheck.Conv; it does the same thing.
Change-Id: I6bf27b8e929f8016ffc8350931c8320e36584a3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/354350
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The tree has package main files scattered around
in it for the purposes of running go generate.
They're all marked "// +build ignore",
which gets special handling in TestDependencies.
It would be nice to be able to use other build tags,
such as "generate", as suggested by the go generate
design doc. Plus the build tag syntax is changing.
This change skips all "package main" files.
By definition these aren't importable,
so they can't contribute to the dependency tree.
We can't quite eliminate the "// +build ignore"
check, as it is used by packages runtime and syscall.
But it's still a step in the right direction.
Change-Id: Ib9449acfdba75f570b87a4200afe944910d76222
Reviewed-on: https://go-review.googlesource.com/c/go/+/339592
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Accept a uint32 instead of a uintptr to make call sites simpler.
Do less work in the common case in which len(textsectmap) == 1.
Change-Id: Idd6cdc3fdad7a9356864c83790463b5d3000171b
Reviewed-on: https://go-review.googlesource.com/c/go/+/354132
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Somehow CL 353390 managed to update the vendored code to d2e5035098b3,
but not the go.mod and other version references. Fix.
Change-Id: Ic265c10f7bd7ec982671b46c5d9ae50636a13309
Reviewed-on: https://go-review.googlesource.com/c/go/+/354391
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The encoding/binary little- and big-endian load and store routines are
frequently used in performance sensitive code. They look fairly complex
to the inliner. Though the routines themselves can be inlined,
code using them typically cannot be.
Yet they typically compile down to an instruction or two
on architectures that support merging such loads.
This change teaches the inliner to treat calls to these methods as cheap,
so that code using them will be more inlineable.
It'd be better to teach the inliner that this pattern of code is cheap,
rather than these particular methods. However, that is difficult to do
robustly when working with the IR representation. And the broader project
of which that would be a part, namely to model the rest of the compiler
in the inliner, is probably a non-starter. By way of contrast, imperfect
though it is, this change is an easy, cheap, and useful heuristic.
If/when we base inlining decisions on more accurate information obtained
later in the compilation process, or on PGO/FGO, we can remove this
and other such heuristics.
Newly inlineable functions in the standard library:
crypto/cipher.gcmInc32
crypto/sha512.appendUint64
crypto/md5.appendUint64
crypto/sha1.appendUint64
crypto/sha256.appendUint64
vendor/golang.org/x/crypto/poly1305.initialize
encoding/gob.(*encoderState).encodeUint
vendor/golang.org/x/text/unicode/norm.buildRecompMap
net/http.(*http2SettingsFrame).Setting
net/http.http2parseGoAwayFrame
net/http.http2parseWindowUpdateFrame
Benchmark impact for encoding/gob (the only package I measured):
name old time/op new time/op delta
EndToEndPipe-8 2.25µs ± 1% 2.21µs ± 3% -1.79% (p=0.000 n=28+27)
EndToEndByteBuffer-8 93.3ns ± 5% 94.2ns ± 5% ~ (p=0.174 n=30+30)
EndToEndSliceByteBuffer-8 10.5µs ± 1% 10.6µs ± 1% +0.87% (p=0.000 n=30+30)
EncodeComplex128Slice-8 1.81µs ± 0% 1.75µs ± 1% -3.23% (p=0.000 n=28+30)
EncodeFloat64Slice-8 900ns ± 1% 847ns ± 0% -5.91% (p=0.000 n=29+28)
EncodeInt32Slice-8 1.02µs ± 0% 0.90µs ± 0% -11.82% (p=0.000 n=28+26)
EncodeStringSlice-8 1.16µs ± 1% 1.04µs ± 1% -10.20% (p=0.000 n=29+26)
EncodeInterfaceSlice-8 28.7µs ± 3% 29.2µs ± 6% ~ (p=0.067 n=29+30)
DecodeComplex128Slice-8 7.98µs ± 1% 7.96µs ± 1% -0.27% (p=0.017 n=30+30)
DecodeFloat64Slice-8 4.33µs ± 1% 4.34µs ± 1% +0.24% (p=0.022 n=30+29)
DecodeInt32Slice-8 4.18µs ± 1% 4.18µs ± 0% ~ (p=0.074 n=30+28)
DecodeStringSlice-8 13.2µs ± 1% 13.1µs ± 1% -0.64% (p=0.000 n=28+28)
DecodeStringsSlice-8 31.9µs ± 1% 31.8µs ± 1% -0.34% (p=0.001 n=30+30)
DecodeBytesSlice-8 8.88µs ± 1% 8.84µs ± 1% -0.48% (p=0.000 n=30+30)
DecodeInterfaceSlice-8 64.1µs ± 1% 64.2µs ± 1% ~ (p=0.173 n=30+28)
DecodeMap-8 74.3µs ± 0% 74.2µs ± 0% ~ (p=0.131 n=29+30)
Fixes#42958
Change-Id: Ie048b8976fb403d8bcc72ac6bde4b33e133e2a47
Reviewed-on: https://go-review.googlesource.com/c/go/+/349931
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
They're only used in a single place.
Instead of calculating the end every time,
calculate it in the linker.
It'd be nice to recalculate baseaddr-vaddr,
but that generates relocations that are too large.
While we're here, remove some pointless uintptr -> uintptr conversions.
Change-Id: I91758f9bff11b365bc3a63fee172dbdc3d90b966
Reviewed-on: https://go-review.googlesource.com/c/go/+/354089
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Tests that require instrumentation must be in
a test script which only runs for architectures
where coverage is supported.
Change-Id: Ia56b1cef1071f848c9dce8c87597207937fdb6c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/354372
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This is a clean port of CL 354329 from types2 to go/types.
For #48819.
Change-Id: I9efdcdbfa6432f3cee64d924a4c67ecc6793cf86
Reviewed-on: https://go-review.googlesource.com/c/go/+/354349
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL reverses the change in CL 284254 (which was ported
to types2) which originated in CL 240901 to address a crash
in a test created by a fuzzer (that crash appears to be
avoided in other ways, now).
This exposed another bug in typeset.go where we don't look
for the underlying type when testing if a type is an interface
or not. Fixed that as well.
Adjusted a test case that now doesn't report an error anymore
(which is good).
Fixes#48819.
Change-Id: I611d68e053d6b8a2f7176d0cd5a44da2df28ad21
Reviewed-on: https://go-review.googlesource.com/c/go/+/354329
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The type set notation has been accepted a while ago.
We're not going back to supporting the original
type list notation. Remove support for it in the
parser and type checker.
Change-Id: I860651f80b89fa43a3a5a2a02cf823ec0dae583c
Reviewed-on: https://go-review.googlesource.com/c/go/+/354131
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
By making off an int64 at the beginning,
the code gets a lot simpler. Cleanup only.
Change-Id: I4a2519f953e2f71081a4ff3032f8fd6da06c7e24
Reviewed-on: https://go-review.googlesource.com/c/go/+/354138
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
With the removal of SSE2 runtime detection made in
golang.org/cl/344350 we can remove this mechanism as there
are no required features anymore.
For making sure CPUs running a go program support all
the minimal hardware requirements the go runtime should
do feature checks early in the runtime initialization
before it is likely any compiler emitted but unsupported
instructions are used. This is already the case for e.g.
checking MMX support on 386 arch targets.
Change-Id: If7b1cb6f43233841e917d37a18314d06a334a734
Reviewed-on: https://go-review.googlesource.com/c/go/+/354209
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Martin Möhrmann <martin@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
As we use relative addressing for text symbols in functab, it is
important that the offsets we computed stay unchanged by the
external linker, i.e. all symbols in Textp should not be removed
by the external linker. Most of them are actually referenced (our
deadcode pass ensures that), except go.buildid which is generated
late and not used by the program. Keep it alive.
Should fix AIX builder.
Change-Id: Ibc4a8951be997b9d8d870d75c54754977d9b8333
Reviewed-on: https://go-review.googlesource.com/c/go/+/354369
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
In GOPATH mode, source files may import other packages using relative
(“local”) paths. In module mode, relative imports are never allowed:
import paths must always be fully specified.
When local imports are allowed, we pass a local-import prefix to the
compiler using the '-D' flag. That could theoretically change the
compiler's output, so it must be included in the cache key even when
-trimpath is set. (TODO: when -trimpath is set, the local-import
prefix ought to be trimmed anyway, so it still shouldn't matter.)
However, when local imports are disallowed, we should not pass the
local-import prefix and it should not affect cmd/go's cache key or the
final build ID of any artifact.
For #48557
Change-Id: I2d627d67d13e5da2cac6d411cd4e2d87e510876c
Reviewed-on: https://go-review.googlesource.com/c/go/+/352810
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This change also fixes a bug with calculating the
total interesting count. When fuzzing with an empty
corpus, the fuzzing engine adds an starting corpus
value in that run in order to start fuzzing. That
meant that the interesting total count was off by one:
it would start at 1, even though the cache was empty.
Added some tests for this as well.
Fixes#48787
Change-Id: I47acf96f0a0797214ebb24a95366d8460bf303bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/354150
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Many uses of Index/IndexByte/IndexRune/Split/SplitN
can be written more clearly using the new Cut functions.
Do that. Also rewrite to other functions if that's clearer.
For #46336.
Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448
Reviewed-on: https://go-review.googlesource.com/c/go/+/351711
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Anthony Knyszek
Robert Griesemer
Robert Findley
Cuong Manh Le
Than McIntosh
andig
Alexander Yastrebov
Keith Randall
Michael Matloob
Matt T. Proud
Archana R
Carlo Alberto Ferraris
Katie Hockman
Benjamin Peterson
wdvxdr
Bryan C. Mills
Joel Sing
Daniel Martí
180909
Meng Zhuo
Damien Neil
Lynn Boger
Richard Musiol
Gusted
Dan Scales
Michael Pratt
Jay Conrod
Brad Fitzpatrick
Tobias Klauser
Ian Lance Taylor
Matthew Dempsky
James Harris
Tamir Duberstein
Koichi Shiraishi
kjgorman
Amelia Downs
Forest Johnson
Mark Hansen
zhouguangyuan
helbing
nicksherron
Jake Ciolek
Cherry Mui
Paul E. Murphy
Nigel Tao
Russ Cox
Sean Liao
Alejandro García Montoro
Pedro Lopez Mareque
Caleb Spare
Jinwen Wo
Leonard Wang
John Kelly
Josh Bleecher Snyder
Martin Möhrmann