CL 60271 introduced this “AwfulBoringCryptoKludge.”
iant approved that CL saying “As long as it stays out of master...”
Now that the rsa and ecdsa code uses boring.Cache, the
“boring unsafe.Pointer” fields are gone from the key structs, and this
code is no longer needed. So delete it.
With the kludge deleted, we are one step closer to being able to merge
dev.boringcrypto into master.
For #51940.
Change-Id: Ie549db14b0b699c306dded2a2163f18f31d45530
Reviewed-on: https://go-review.googlesource.com/c/go/+/395884
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
In the original BoringCrypto port, ecdsa and rsa's public and private
keys added a 'boring unsafe.Pointer' field to cache the BoringCrypto
form of the key. This led to problems with code that “knew” the layout
of those structs and in particular that they had no unexported fields.
In response, as an awful kludge, I changed the compiler to pretend
that field did not exist when laying out reflect data. Because we want
to merge BoringCrypto in the main tree, we need a different solution.
Using boring.Cache is that solution.
For #51940.
Change-Id: Ideb2b40b599a1dc223082eda35a5ea9abcc01e30
Reviewed-on: https://go-review.googlesource.com/c/go/+/395883
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
In the original BoringCrypto port, ecdsa and rsa's public and private
keys added a 'boring unsafe.Pointer' field to cache the BoringCrypto
form of the key. This led to problems with code that “knew” the layout
of those structs and in particular that they had no unexported fields.
In response, as an awful kludge, I changed the compiler to pretend
that field did not exist when laying out reflect data. Because we want
to merge BoringCrypto in the main tree, we need a different solution.
The different solution is this CL's boring.Cache, which is a
concurrent, GC-aware map from unsafe.Pointer to unsafe.Pointer (if
generics were farther along we could use them nicely here, but I am
afraid of breaking tools that aren't ready to see generics in the
standard library yet).
More complex approaches are possible, but a simple, fixed-size hash
table is easy to make concurrent and should be fine.
For #51940.
Change-Id: I44062a8defbd87b705a787cffc64c6a9d0132785
Reviewed-on: https://go-review.googlesource.com/c/go/+/395882
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This API was added only for BoringCrypto, never shipped in standard
Go. This API is also not compatible with the expected future evolution
of crypto/x509, as we move closer to host verifiers on macOS and Windows.
If we want to merge BoringCrypto into the main tree, it is best not to
have differing API. So instead of a hook set by crypto/tls, move the
actual check directly into crypto/x509, eliminating the need for
exposed API.
For #51940.
Change-Id: Ia2ae98c745de818d39501777014ea8166cab0b03
Reviewed-on: https://go-review.googlesource.com/c/go/+/395878
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
One annoying difference between dev.boringcrypto and master is that
there is not a clear separation between low-level (math/big-free)
crypto and high-level crypto, because crypto/internal/boring imports
both encoding/asn1 and math/big.
This CL removes both those problematic imports and aligns the
dependency rules in the go/build test with the ones in the main
branch.
To remove encoding/asn1, the crypto/internal/boring APIs change to
accepting and returning encoded ASN.1, leaving crypto/ecdsa to do the
marshaling and unmarshaling, which it already contains code to do.
To remove math/big, the crypto/internal/boring package defines
type BigInt []uint, which is the same representation as a big.Int's
internal storage. The new package crypto/internal/boring/bbig provides
conversions between BigInt and *big.Int. The boring package can then
be in the low-level crypto set, and any package needing to use bignum
APIs (necessarily in the high-level crypto set) can import bbig to
convert.
To simplify everything we hide from the test the fact that
crypto/internal/boring imports cgo. Better to pretend it doesn't and
keep the prohibitions that other packages like crypto/aes must not use
cgo (outside of BoringCrypto).
$ git diff origin/master src/go/build/deps_test.go
diff --git a/src/go/build/deps_test.go b/src/go/build/deps_test.go
index 6ce872e297..a63979cc93 100644
--- a/src/go/build/deps_test.go
+++ b/src/go/build/deps_test.go
@@ -402,9 +402,13 @@ var depsRules = `
NET, log
< net/mail;
+ NONE < crypto/internal/boring/sig;
+ sync/atomic < crypto/internal/boring/fipstls;
+ crypto/internal/boring/sig, crypto/internal/boring/fipstls < crypto/tls/fipsonly;
+
# CRYPTO is core crypto algorithms - no cgo, fmt, net.
# Unfortunately, stuck with reflect via encoding/binary.
- encoding/binary, golang.org/x/sys/cpu, hash
+ crypto/internal/boring/sig, encoding/binary, golang.org/x/sys/cpu, hash
< crypto
< crypto/subtle
< crypto/internal/subtle
@@ -413,6 +417,8 @@ var depsRules = `
< crypto/ed25519/internal/edwards25519/field, golang.org/x/crypto/curve25519/internal/field
< crypto/ed25519/internal/edwards25519
< crypto/cipher
+ < crypto/internal/boring
+ < crypto/boring
< crypto/aes, crypto/des, crypto/hmac, crypto/md5, crypto/rc4,
crypto/sha1, crypto/sha256, crypto/sha512
< CRYPTO;
@@ -421,6 +427,7 @@ var depsRules = `
# CRYPTO-MATH is core bignum-based crypto - no cgo, net; fmt now ok.
CRYPTO, FMT, math/big, embed
+ < crypto/internal/boring/bbig
< crypto/rand
< crypto/internal/randutil
< crypto/ed25519
@@ -443,7 +450,8 @@ var depsRules = `
< golang.org/x/crypto/hkdf
< crypto/x509/internal/macos
< crypto/x509/pkix
- < crypto/x509
+ < crypto/x509;
+ crypto/internal/boring/fipstls, crypto/x509
< crypto/tls;
# crypto-aware packages
@@ -653,6 +661,9 @@ func findImports(pkg string) ([]string, error) {
}
var imports []string
var haveImport = map[string]bool{}
+ if pkg == "crypto/internal/boring" {
+ haveImport["C"] = true // kludge: prevent C from appearing in crypto/internal/boring imports
+ }
fset := token.NewFileSet()
for _, file := range files {
name := file.Name()
For #51940.
Change-Id: I26fc752484310d77d22adb06495120a361568d04
Reviewed-on: https://go-review.googlesource.com/c/go/+/395877
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
The standard Go implementations are allocation-free.
Making the BoringCrypto ones the same helps avoid
surprises, including in some of our own tests.
For #51940.
Change-Id: Ic9c5dc46f5e29ca85f571244be2b380ec2cf89c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/395876
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The dev.boringcrypto branch has historically forced use of boringcrypto
with no additional configuration flags. The previous CL undid that.
This CL redoes it, so that direct uses of dev.boringcrypto don't lapse
unexpectedly into not having boringcrypto enabled.
When dev.boringcrypto is merged into master, we will undo this change
as part of the merge, so that the only final difference between master
and dev.boringcrypto will be this CL.
For #51940.
Change-Id: I816593a0b30b4e71093a7da9451bae7807d7167e
Reviewed-on: https://go-review.googlesource.com/c/go/+/402597
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A plain make.bash in this tree will produce a working,
standard Go toolchain, not a BoringCrypto-enabled one.
The BoringCrypto-enabled one will be created with:
GOEXPERIMENT=boringcrypto ./make.bash
For #51940.
Change-Id: Ia9102ed993242eb1cb7f9b93eca97e81986a27b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/395881
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Proposal #42477 asked for a way to apply conditional build tags
to syso files (which have no source code to hold //go:build lines).
We ended up suggesting that the standard answer should be to
put the syso in its own package and then import that package from
a source file that is itself conditionally compiled.
A followup comment on that issue pointed out a problem that I did
not understand until I tried to use this approach myself: the cgo
build fails by default, because the link step only uses syso files from
the current package. You have to override this explicitly by arranging
to pass a “ignore unresolved symbols” flag to the host linker.
Many users will not know how to do this.
(I don't know how to do this off the top of my head.)
If we want users to use this approach, we should make it work better.
This CL does that, by including the syso files from dependencies of
the current package in the link step.
For #51940.
Change-Id: I53a0371b2df17e39a000a645b7686daa6a98722d
Reviewed-on: https://go-review.googlesource.com/c/go/+/402596
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
When we add GOEXPERIMENT=boringcrypto, the bootstrap process
will not converge if the compiler itself depends on the boringcrypto
cgo-based implementations of sha1 and sha256.
Using notsha256 avoids boringcrypto and makes bootstrap converge.
Removing md5 is not strictly necessary but it seemed worthwhile to
be consistent.
For #51940.
Change-Id: Iba649507e0964d1a49a1d16e463dd23c4e348f14
Reviewed-on: https://go-review.googlesource.com/c/go/+/402595
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Package notsha256 implements the NOTSHA256 hash,
defined as bitwise NOT of SHA-256.
It will be used from the Go compiler toolchain where an
arbitrary hash is needed and the code currently reaches
for MD5, SHA1, or SHA256. The problem with all of those
is that when we add GOEXPERIMENT=boringcrypto, the
bootstrap process will not converge if the compiler itself
depends on the boringcrypto cgo code.
Using notsha256 avoids boringcrypto.
It is possible that I don't fully understand the convergence
problem and that there is a way to make the compiler converge
when using cgo, but keeping cgo out of the compiler seems safest.
It also makes clear that (except for the hack in codesign)
the code using this package doesn't care which hash is used.
For #51940.
Change-Id: Ie7c661183eacf8413a9d2074c96cbb9361e125ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/402594
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
There was no way to use an interface because the methods on the Point
types return concrete Point values, as they should.
A couple somewhat minor annoyances:
- Allocations went up due to #48849. This is fine here, where
math/big causes allocations anyway, but would probably not be fine
in nistec itself.
- Carrying the newPoint/newGenerator functions around as a field is
a little weird, even if type-safe. It also means we have to make
what were functions methods so they can access newPoint to return
the zero value. This is #35966.
For #52182
Change-Id: I050f3a27f15d3f189818da80da9de0cba0548931
Reviewed-on: https://go-review.googlesource.com/c/go/+/360015
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Not quite golang.org/wiki/TargetSpecific compliant, but almost.
The only substantial code change is in randFieldElement: it used to use
Params().BitSize instead of Params().N.BitLen(), which is semantically
incorrect, even if the two values are the same for all named curves.
For #52182
Change-Id: Ibc47450552afe23ea74fcf55d1d799d5d7e5487c
Reviewed-on: https://go-review.googlesource.com/c/go/+/315273
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This test tends to be flaky on 32-bit systems.
There's not enough bits in the hash output, so we
expect a nontrivial number of collisions, and it is
often quite a bit higher than expected.
Fixes#43130
Change-Id: If35413b7c45eed778a08b834dacf98009ceca840
Reviewed-on: https://go-review.googlesource.com/c/go/+/402456
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
This change refactors the scavenger into a type whose methods represent
the actual function and scheduling of the scavenger. It also stubs out
access to global state in order to make it testable.
This change thus also adds a test for the scavenger. In writing this
test, I discovered the lack of a behavior I expected: if the
pageAlloc.scavenge returns < the bytes requested scavenged, that means
the heap is exhausted. This has been true this whole time, but was not
documented or explicitly relied upon. This change rectifies that. In
theory this means the scavenger could spin in run() indefinitely (as
happened in the test) if shouldStop never told it to stop. In practice,
shouldStop fires long before the heap is exhausted, but for future
changes it may be important. At the very least it's good to be
intentional about these things.
While we're here, I also moved the call to stopTimer out of wake and
into sleep. There's no reason to add more operations to a context that's
already precarious (running without a P on sysmon).
Change-Id: Ib31b86379fd9df84f25ae282734437afc540da5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/384734
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change completes the proposal laid out in #44163. With #44313
resolved, we now ensure that stopped Ms are able to wake up and become
dedicated GC workers. As a result, idle GC workers are in theory no
longer required to be a proxy for scheduling dedicated mark workers.
And, with at least one dedicated mark worker running (which is
non-preemptible) we ensure the GC makes progress in all circumstances
when at least one is running. Currently we ensure at least one idle mark
worker is available at all times because it's possible before #44313
that a dedicated worker doesn't ever get scheduled, leading to a
deadlock if user goroutines block on a GC completing. But now that extra
idle mark worker should be unnecessary to ensure GC progress when at
least one dedicated mark worker is going to be scheduled.
Fixes#44163.
Change-Id: I62889ef2db4e69d44da883e8e6eebcfe5398c86d
Reviewed-on: https://go-review.googlesource.com/c/go/+/395634
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change moves several scheduling decisions made by schedule into
findrunnable. The main motivation behind this change is the fact that
stopped Ms can't become dedicated or fractional GC workers. The main
reason for this is that when a stopped M wakes up, it stays in
findrunnable until it finds work, which means it will never consider GC
work. On that note, it'll also never consider becoming the trace reader,
either.
Another way of looking at it is that this change tries to make
findrunnable aware of more sources of work than it was before. With this
change, any M in findrunnable should be capable of becoming a GC worker,
resolving #44313. While we're here, let's also make more sources of
work, such as the trace reader, visible to handoffp, which should really
be checking all sources of work. With that, we also now correctly handle
the case where StopTrace is called from the last live M that is also
locked (#39004). stoplockedm calls handoffp to start a new M and handle
the work it cannot, and once we include the trace reader in that, we
ensure that the trace reader gets scheduled.
This change attempts to preserve the exact same ordering of work
checking to reduce its impact.
One consequence of this change is that upon entering schedule, some
sources of work won't be checked twice (i.e. the local and global
runqs, and timers) as they do now, which in some sense gives them a
lower priority than they had before.
Fixes#39004.
Fixes#44313.
Change-Id: I5d8b7f63839db8d9a3e47cdda604baac1fe615ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/393880
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change reduces the maximum number of idle mark workers during
periodic (currently every 2 minutes) GC cycles to 1.
Idle mark workers soak up all available and unused Ps, up to GOMAXPROCS.
While this provides some throughput and latency benefit in general, it
can cause what appear to be massive CPU utilization spikes in otherwise
idle applications. This is mostly an issue for *very* idle applications,
ones idle enough to trigger periodic GC cycles. This spike also tends to
interact poorly with auto-scaling systems, as the system might assume
the load average is very low and suddenly see a massive burst in
activity.
The result of this change is not to bring down this 100% (of GOMAXPROCS)
CPU utilization spike to 0%, but rather
min(25% + 1/GOMAXPROCS*100%, 100%)
Idle mark workers also do incur a small latency penalty as they must be
descheduled for other work that might pop up. Luckily the runtime is
pretty good about getting idle mark workers off of Ps, so in general
the latency benefit from shorter GC cycles outweighs this cost. But, the
cost is still non-zero and may be more significant in idle applications
that aren't invoking assists and write barriers quite as often.
We can't completely eliminate idle mark workers because they're
currently necessary for GC progress in some circumstances. Namely,
they're critical for progress when all we have is fractional workers. If
a fractional worker meets its quota, and all user goroutines are blocked
directly or indirectly on a GC cycle (via runtime.GOMAXPROCS, or
runtime.GC), the program may deadlock without GC workers, since the
fractional worker will go to sleep with nothing to wake it.
Fixes#37116.
For #44163.
Change-Id: Ib74793bb6b88d1765c52d445831310b0d11ef423
Reviewed-on: https://go-review.googlesource.com/c/go/+/393394
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
OpenBSD has a coarse sleep granularity that rounds up to 10 ms
increments. This can cause significant STW delays, among other issues.
As far as I can tell, there's only 1 tightly timed sleep without an
explicit wakeup for which this actually matters.
Fixes#52475.
Change-Id: Ic69fc11096ddbbafd79b2dcdf3f912fde242db24
Reviewed-on: https://go-review.googlesource.com/c/go/+/401638
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Right now we export alloc count metrics via the runtime/metrics package
and mark them as monotonic, but that's not actually true. As an
optimization, the runtime assumes a span is always fully allocated
before being uncached, and updates the accounting as such. In the rare
case that it's wrong, the span has enough information to back out what
did not get allocated.
This change uses 16 bits of padding in the mspan to house another field
that represents the amount of mspan slots filled just as the mspan is
cached. This is information is enough to get an exact count, allowing us
to make the metrics truly monotonic.
Change-Id: Iaff3ca43f8745dc1bbb0232372423e014b89b920
Reviewed-on: https://go-review.googlesource.com/c/go/+/377516
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
sigtramp on openbsd-arm64 is teetering on the edge of the nosplit stack
limit. Add more headroom by calling sigtrampgo using ABIInternal, which
eliminates a 48-byte ABI wrapper frame.
openbsd-amd64 has slightly more space, but is also close to the limit,
so convert it as well.
Other operating systems don't have it as bad, but many have nearly
identical implementations of sigtramp, so I have converted them as well.
I've omitted darwin-arm64 and solaris, as those are quite different and
would benefit from not needing ifdef for both cases.
For #51485.
Change-Id: I70512645d4208b346a59d5e5d03836a45833b1d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/390814
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The previous implementation of helperCommand relied on running a
well-known Test function which implemented all known commands.
That not only added Skip noise in the test's output, but also (and
more importantly) meant that the commands could not write directly to
stdout in the usual way, since the testing package hijacks os.Stdout
for its own use.
The new implementation addresses the above issues, and also ensures
that all registered commands are actually used, reducing the risk of
an unused command sticking around after refactoring.
It also sets the subprocess environment variable directly in the test
process, instead of on each individual helper command's Env field,
allowing helper commands to be used without an explicit Env.
Updates #50599.
(Also for #50436.)
Change-Id: I189c7bed9a07cfe47a084b657b88575b1ee370b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/401934
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This makes clearer that skipStdinCopyError is always defined and never
overridden in tests.
Secondarily, it may also help reduce init-time work and allow the
linker and/or inliner to better optimize this package.
(Noticed while prototyping #50436.)
Change-Id: I4f3c1bc146384a98136a4039f82165ed106c14b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/401897
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
When we call time.Unix(s, ns), the internal representation is
s + 62135596800, where 62135596800 is the number of
seconds from Jan 1 1 to Jan 1 1970.
If quickcheck generates numbers too close to 2^63,
the addition can wraparound to make a very negative
internal 64-bit value. Wraparounds are not guarded
against, since they would not arise in any reasonable program,
so just avoid testing near them.
Fixes#52409.
Change-Id: Id466c8a34a49055ab26f2687a6b2b657cb64bed6
Reviewed-on: https://go-review.googlesource.com/c/go/+/402177
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Accept ~x as ordinary unary expression in the parser but recognize
such expressions as invalid in the type checker.
This change opens the door to recognizing complex type constraint
literals such as `*E|~int` in `[P *E|~int]` and parse them correctly
instead of reporting a parse error because `P*E|~int` syntactically
looks like an incorrect array length expression (binary expression
where the RHS of | is an invalid unary expression ~int).
As a result, the parser is more forgiving with expressions but the
type checker will reject invalid uses as before.
We could pass extra information into the binary/unary expression
parse functions to prevent the use of ~ in invalid situations but
it doesn't seem worth the trouble. In fact it may be advantageous
to allow a more liberal expression syntax especially in the presence
of errors (better parser synchronization after an error).
Preparation for fixing #49482.
Change-Id: I119e8bd9445dfa6460fcd7e0658e3554a34b2769
Reviewed-on: https://go-review.googlesource.com/c/go/+/402255
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This test occasionally fails on the dragonfly-amd64 builder with
"directory not empty". Since that is the only platform on which we
observe these failures, and since the test had a different (and also
invalid-looking) failure mode prior to this one (in #50716), we
suspect that it is due to either a bug in the platform or a
platform-specific Go bug.
For #52301.
Change-Id: Id36c499651b9c48e6b8b0107d01f73d2a7b6bab8
Reviewed-on: https://go-review.googlesource.com/c/go/+/402155
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
In CL 371574 PatchSet 18, we replaced all !{{Less}} with {{GreaterOrEqual}} to fix a problem(handle NaNs when sorting float64 slice) in exp/slices.
We don't actually need this change, because we don't guarantee that the slice will be sorted eventually if there are NaNs(we could have a[i] < a[j] for some i,j with i>j).
This CL reverts all the replacements in exp/slices and does not affect any codes in the sort package.
Change-Id: Idc225d480de3e2efef2add35c709ed880d1306cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/400534
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
These tests run the runtime, reflect, and sync package tests with the
two maymorestack hooks we have.
These tests only run on the longtest builders (or with
GO_TEST_SHORT=false) because we're running the runtime test two
additional times and the mayMoreStackMove hook makes it about twice as
slow (~230 seconds).
To run just these tests by hand, do
GO_TEST_SHORT=false go tool dist test -run mayMoreStack
Updates #48297.
This detected #49354, which was found as a flake on the dashboard, but
was reliably reproducible with these tests; and #49395.
Change-Id: If785a8b8d6e1b9ad4d2ae67493b54055ab6cbc85
Reviewed-on: https://go-review.googlesource.com/c/go/+/361212
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
There are a few tests of the scheduler run queue API that allocate a
local []g and test using those G's. However, the run queue API
frequently converts between *g and guintptr, which is safe for "real"
Gs because they're heap-allocated and hence don't move, but if these
tests get a stack movement while holding one of these local *g's as a
guintptr, it won't get updated and the test will fail.
Updates #48297.
Change-Id: Ifd424147ce1a1b53732ff0cf55a81df1a9beeb3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/402157
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Fix up TestEd25519Vectors to download files into its own temporary mod
cache, as opposed relying on whatever GOPATH or GOMODCACHE setting is
in effect when the test is run.
Change-Id: I523f1862f5874b0635a6c0fa83d35a6cfac6073b
Reviewed-on: https://go-review.googlesource.com/c/go/+/402154
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
OpenBSD has a default soft limit of 512 and hard limit of 1024 - as such,
attempting to open 1200 files is always going to fail unless the defaults
have been changed. On this platform use 768 instead such that it passes
without requiring customisation.
Fixes#51713
Change-Id: I7679c8fd73d4b263145129e9308afdb29d67bb54
Reviewed-on: https://go-review.googlesource.com/c/go/+/401594
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: 谢致邦 <xiezhibang@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
This CL adds support for debugger function calls on linux arm64
platform. The protocol is basically the same as in CL 109699, except for
the following differences:
1, The abi difference which affect parameter passing and frame layout.
2, Stores communication information in R20.
3, The closure register is R26.
4, Use BRK 0 instruction to generate a breakpoint. The saved PC in
sigcontext is the PC where the signal occurred, not the next PC.
In addition, this CL refactors the existing code (which is dedicated to
amd64) for easier multi-arch scaling.
Fixes#50614
Change-Id: I06b14e345cc89aab175f4a5f2287b765da85a86b
Reviewed-on: https://go-review.googlesource.com/c/go/+/395754
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Built using racebuild.
Note that racebuild fails when trying to test the .syso, because the
Go runtime doesn't think we support s390x race yet. But it builds the
.syso as a side effect which I grabbed. There's something of a
chicken-and-egg bootstrapping problem here, unfortunately.
Change-Id: Ibc6d04fd3a9bfb3224d08e8b78dcf09bb139a59d
Reviewed-on: https://go-review.googlesource.com/c/go/+/401714
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Jonathan Albrecht <jonathan.albrecht@ibm.com>
This fixes a deadlock-on-failure that I probably introduced in
CL 385314.
This doesn't explain why the failure observed in #52492 occurred, but
it will at least give us more information to diagnose the failure if
it happens again. (The deadlock currently prevents the t.Fatal log
message from being written to the test's output.)
Fixes#52492.
Change-Id: I9e7874985e2820a6a4b703abe4f8e2035d5138c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/401575
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Use error_.errorf for reporting related error information rather than
inlining the "\n\t". This aligns go/types with types2 in cases where the
related information has no position information. In other cases,
go/types needs to report a "continuation error" (starting with '\t') so
that users can access multiple error positions.
Change-Id: Ica98466596c374e0c1e502e7227c8d8c803b4c22
Reviewed-on: https://go-review.googlesource.com/c/go/+/400825
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
To begin aligning with types2 error reporting, use an error_ type to
hold unevaluated error information, to report via Checker.report.
Change-Id: Ic5ac515759961e55b81acc9eeaac4db25b61804c
Reviewed-on: https://go-review.googlesource.com/c/go/+/400824
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Checker.err was only called to report errors created with
Checker.newError or Checker.newErrorf. Update the API to pass around
*Error rather than error, eliminating unnecessary type assertions and
handling.
Change-Id: I995a120c7e87266e656b8ff3fd9ed3d368fd17fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/400823
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
With this patch, -asan option can detect the error memory
access to global variables.
So this patch makes a few changes:
1. Add the asanregisterglobals runtime support function,
which calls asan runtime function _asan_register_globals
to register global variables.
2. Create a new initialization function for the package
being compiled. This function initializes an array of
instrumented global variables and pass it to function
runtime.asanregisterglobals. An instrumented global
variable has trailing redzone.
3. Writes the new size of instrumented global variables
that have trailing redzones into object file.
4. Notice that the current implementation is only compatible with
the ASan library from version v7 to v9. Therefore, using the
-asan option requires that the gcc version is not less than 7
and the clang version is less than 4, otherwise a segmentation
fault will occur. So this patch adds a check on whether the compiler
being used is a supported version in cmd/go.
Change-Id: I664e74dcabf5dc7ed46802859174606454e8f1d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/321715
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Fannie Zhang <Fannie.Zhang@arm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 205457 added the flag -Wno-nullability-completeness to work
around a user-reported build breakage on macOS Catalina.
However, according to
https://golang.org/issue/35247#issuecomment-589115489 the root cause
of the breakage may be a toolchain misconfiguration on the host
(perhaps compiling the XCode stdlib using a Homebrew build of the
"clang" compiler?).
Adding an obscure warning flag to enable building stdlib.h with an
otherwise-broken toolchain seems clearly inappropriate to me.
If need be we can instead provide guidance to users on how to unbreak
their toolchain.
Updates #35247Fixes#49913
Change-Id: I84def34e101bed7911d8d78a991a29095b8791fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/368634
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The following Value methods are now inlineable:
Bool for ~bool
String for ~string (but not other kinds)
Bytes for []byte (but not ~[]byte or ~[N]byte)
Len for ~[]T (but not ~[N]T, ~chan T, ~map[K]V, or ~string)
Cap for ~[]T (but not ~[N]T or ~chan T)
For Bytes, we only have enough inline budget to inline one type,
so we optimize for unnamed []byte, which is far more common than
named []byte or [N]byte.
For Len and Cap, we only have enough inline budget to inline one kind,
so we optimize for ~[]T, which is more common than the others.
The exception is string, but the size of a string can be obtained
through len(v.String()).
Performance:
Bool 1.65ns ± 0% 0.51ns ± 3% -68.81% (p=0.008 n=5+5)
String 1.97ns ± 1% 0.70ns ± 1% -64.25% (p=0.008 n=5+5)
Bytes 8.90ns ± 2% 0.89ns ± 1% -89.95% (p=0.008 n=5+5)
NamedBytes 8.89ns ± 1% 8.88ns ± 1% ~ (p=0.548 n=5+5)
BytesArray 10.0ns ± 2% 10.2ns ± 1% +1.58% (p=0.048 n=5+5)
SliceLen 1.97ns ± 1% 0.45ns ± 1% -77.22% (p=0.008 n=5+5)
MapLen 2.62ns ± 1% 3.07ns ± 1% +17.24% (p=0.008 n=5+5)
StringLen 1.96ns ± 1% 1.98ns ± 2% ~ (p=0.151 n=5+5)
ArrayLen 1.96ns ± 1% 2.19ns ± 1% +11.46% (p=0.008 n=5+5)
SliceCap 1.76ns ± 1% 0.45ns ± 2% -74.28% (p=0.008 n=5+5)
There's a slight slowdown (~10-20%) for obtaining the length
of a string or map, but a substantial improvement for slices.
Performance according to encoding/json:
CodeMarshal 555µs ± 2% 562µs ± 4% ~ (p=0.421 n=5+5)
MarshalBytes/32 163ns ± 1% 157ns ± 1% -3.82% (p=0.008 n=5+5)
MarshalBytes/256 453ns ± 1% 447ns ± 1% ~ (p=0.056 n=5+5)
MarshalBytes/4096 4.10µs ± 1% 4.09µs ± 0% ~ (p=1.000 n=5+4)
CodeUnmarshal 3.16ms ± 2% 3.02ms ± 1% -4.18% (p=0.008 n=5+5)
CodeUnmarshalReuse 2.64ms ± 3% 2.51ms ± 2% -4.81% (p=0.016 n=5+5)
UnmarshalString 65.4ns ± 4% 64.1ns ± 0% ~ (p=0.190 n=5+4)
UnmarshalFloat64 59.8ns ± 5% 58.9ns ± 2% ~ (p=0.222 n=5+5)
UnmarshalInt64 51.7ns ± 1% 50.0ns ± 2% -3.26% (p=0.008 n=5+5)
EncodeMarshaler 23.6ns ±11% 20.8ns ± 1% -12.10% (p=0.016 n=5+4)
Add all inlineable methods of Value to cmd/compile/internal/test/inl_test.go.
Change-Id: Ifc192491918af6b62f7fe3a094a5a5256bfb326d
Reviewed-on: https://go-review.googlesource.com/c/go/+/400676
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Currently bufio.Writer implements forwarding to the underlying Writer
for large writes via Write, but it does not do the same for large
writes via WriteString.
If the underlying Writer is also a StringWriter, use the same "large
writes" logic also in WriteString while taking care to only check
once per call to WriteString whether the underlying Writer implements
StringWriter.
Change-Id: Id81901c07b035936816b9e41b1f5688e699ee8e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/380074
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This is a re-do of CL 388477, fixing #52472.
It is unsafe to call syscall.RawSyscall from syscall.Syscall with
-coverpkg=all and -race. This is because:
1. Coverage adds a sync/atomic call in RawSyscall to increment the
coverage counter.
2. Race mode instruments sync/atomic calls with TSAN runtime calls. TSAN
eventually calls runtime.racecallbackfunc, which expects
getg().m.p != 0, which is no longer true after entersyscall().
cmd/go actually avoids adding coverage instrumention to package runtime
in race mode entirely to avoid these kinds of problems. Rather than also
excluding all of syscall for this one function, work around by calling
RawSyscall6 instead, which avoids coverage instrumention both by being
written in assembly and in package runtime/*.
For #51087Fixes#52472
Change-Id: Iaffd27df03753020c4716059a455d6ca7b62f347
Reviewed-on: https://go-review.googlesource.com/c/go/+/401654
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
cmd/trace is currently somewhat painful to use in odd environments since
it depends on the presence of $GOROOT/misc/trace to serve the static
trace viewer content.
Use //go:embed to embed this content directly into cmd/trace for easier
use.
Change-Id: I83b7d97dbecc9773f3b5a6b3bc4a6597473bc01a
Reviewed-on: https://go-review.googlesource.com/c/go/+/378194
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Just like https://golang.org/cl/401454 removed the work from gofmt for a
nice ~5% speed-up in the default case, we can also use the option in the
equivalent go/format for programs which use it rather than gofmt,
as go/format makes no use of objects either.
No benchmark numbers as we already measured the ~5% speed-up with gofmt
in the other CL linked above.
See #46485.
Change-Id: Icbf98e6d46a616081314e2faa13f1dfade3bbaef
Reviewed-on: https://go-review.googlesource.com/c/go/+/401474
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
go/parser will by default resolve objects as per the go/ast.Object type,
which is then used by gofmt's rewrite and simplify flags.
However, none of that is needed if neither of the flags is set,
so we can avoid the work entirely for a nice speed-up.
benchcmd -n 8 GofmtSrcCmd gofmt -l ~/tip/src/cmd
name old time/op new time/op delta
GofmtSrcCmd 957ms ± 7% 908ms ± 7% -5.12% (p=0.028 n=8+8)
name old user-time/op new user-time/op delta
GofmtSrcCmd 11.2s ± 1% 10.4s ± 1% -7.23% (p=0.001 n=7+7)
name old sys-time/op new sys-time/op delta
GofmtSrcCmd 325ms ±29% 286ms ±22% ~ (p=0.065 n=8+8)
name old peak-RSS-bytes new peak-RSS-bytes delta
GofmtSrcCmd 295MB ±17% 276MB ±15% ~ (p=0.328 n=8+8)
See #46485.
Change-Id: Iad1ae294953710c233f7837d7eb02e23d11c6185
Reviewed-on: https://go-review.googlesource.com/c/go/+/401454
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This reverts CL400377, which restricted serials passed to
x509.CreateCertificate to <= 20 octets. Unfortunately this turns out to
be something _a lot_ of people get wrong. Since it's not particularly
obvious how to properly generate conformant serials, until we provide
an easier way for people to get this right, reverting this restriction
makes sense (possible solution discussed in #52444.)
Change-Id: Ia85a0ffe61e2e547abdaf1389c3e1ad29e28a2be
Reviewed-on: https://go-review.googlesource.com/c/go/+/401657
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When the user is trying to list or build a package in a module that's
outside of the workspace provide a more clear message hinting to the
user that they can add the module to the workspace using go work use.
Fixes#51604
Change-Id: I1202ecb2f22fd6351bfdec88ed613b8167687fb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/400014
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Future CLs will be changing the provenance of these functions. Move the
declarations to the individual OS files now so that future CLs can
change only 1 OS at a time rather than changing all at once.
For #51087
Change-Id: I5e1bca71e670263d8c0faa586c1b6b4de1a114b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/388474
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL exports the existing ir.UintptrKeepAlive via the new directive
//go:uintptrkeepalive. This makes the compiler insert KeepAlives for
pointers converted to uintptr in calls, keeping them alive for the
duration of the call.
//go:uintptrkeepalive requires //go:nosplit, as stack growth can't
handle these arguments (it cannot know which are pointers). We currently
check this on the immediate function, but the actual restriction applies
to all transitive calls.
The existing //go:uintptrescapes is an extension of
//go:uintptrkeepalive which forces pointers to escape to the heap, thus
eliminating the stack growth issue.
This pragma is limited to the standard library.
For #51087
Change-Id: If9a19d484d3561b4219e5539b70c11a3cc09391e
Reviewed-on: https://go-review.googlesource.com/c/go/+/388095
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
With #50599 implemented, base.AppendPWD is redundant if cmd.Env would
otherwise be nil, and calls to os.Environ followed by base.AppendPWD
can be replaced by a simpler call to cmd.Environ.
Updates #50599.
Change-Id: I94a22e2a4cc8e83c815ac41702ea0b1ee5034ecc
Reviewed-on: https://go-review.googlesource.com/c/go/+/401534
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Per RFC 4158 Section 2.4.2, when we are discarding candidate
certificates during path building, use the SANs as well as subject and
public key when checking whether a certificate is already present in
the built path. This supports the case where a certificate in the chain
(typically a leaf) has the exact same subject and public key as another
certificate in the chain (typically its parent) but has SANs which don't
match.
Change-Id: I212c234e94a1f6afbe9691e4a3ba257461db3a7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/401115
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Once #50599 is implemented, the entries will be observable via the
Environ method. I find it confusing for later entries in the list to
jump arbitrarily far forward based on entries for the same key that no
longer exist.
This also fixes the deduplication logic for the degenerate Windows
keys observed in #49886, which were previously deduplicated as empty
keys.
(It does not do anything about the even-more-degenerate keys observed
in #52436.)
For #50599.
Change-Id: Ia7cd2200ec34ccc4b9d18631cb513194dc420c25
Reviewed-on: https://go-review.googlesource.com/c/go/+/401339
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
There is an issue where 'go test' will hang after the tests complete if
a test starts a sub-process that does not exit (see #24050).
However, go test only exhibits that behavior when a package name is
explicitly passed as an argument. If 'go test' is invoked without any
package arguments then the package in the working directory is assumed,
however in that case (and only that case) os.Stdout is used as the test
process's cmd.Stdout, which does *not* cause 'go test' wait for the
sub-process to exit (see #23019).
This change wraps os.Stdout in an io.Writer struct in this case, hiding
the *os.File from the os/exec package, causing cmd.Wait to always wait
for the full output from the test process and any of its sub-processes.
In other words, this makes 'go test' exhibit the same behavior as
'go test .' (or 'go test ./...' and so on).
Update #23019
Update #24050
Change-Id: Ica09bf156f3b017f9a31aad91ed0f16a7837195b
Reviewed-on: https://go-review.googlesource.com/c/go/+/400877
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Andrew Gerrand <adg@golang.org>
Auto-Submit: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Support fastrand64 in the runtime, although fastrand uses wyrand to generate 64-bit random number, it still returns uint32. In some cases, we need to generate a 64-bit random number, the new API would be faster and easier to use, and at least we can use the new function in these places:
src/net/dnsclient.go:randInt()
src/hash/maphash/maphash.go:MakeSeed()
src/runtime/map.go:mapiterinit()
name time/op
Fastrand-16 0.09ns ± 5%
Fastrand64-16 0.09ns ± 6%
Change-Id: Ibb97378c7ca59bc7dc15535d4872fa58ea112e6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/400734
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
When we have an error in a function type used in an expression
we don't know until we see an opening { whether we have a function
literal or a function type. Use "function type" as context because
that's always correct in the specific error message.
Change-Id: I9aad8fcddf31ae53daa53cebd2c2001f08eabde0
Reviewed-on: https://go-review.googlesource.com/c/go/+/401316
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This test forces GOARCH to amd64, but currently uses the default GOOS.
This works on every OS that supports amd64, which is every OS we
support except AIX. Hence, on AIX this fails with an unsupported
GOOS/GOARCH combination.
Fix this by forcing GOOS to linux.
Fixes#52451.
Change-Id: I9321dd6386c7ef0fe2b47d77ed900aafc53f2a46
Reviewed-on: https://go-review.googlesource.com/c/go/+/401334
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
An error message like "could not import os/user (exit status 1)"
(observed in https://go.dev/issue/52407) is fairly inscrutable.
On the other hand, srcimporter doesn't report errors with quite enough
structure to dump the entire stderr output from 'go tool cgo' without
potentially overwhelming the caller. Here, we split the difference by
describing which command failed but not printing the output of that
command.
For #52407, that would at least provide a stronger clue connecting
to #52408.
Change-Id: Iabdc95b17ba20a0f6ff38e5c7084e5081e1ef5e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/400817
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Be explicit that we always mean non-interface types when we
talk about sets of types.
Also, clarify that the quantification "all non-interface types"
means all such types in all possible programs, not just the
current program.
Per suggestion from Philip Wadler.
Change-Id: Ibc7b5823164e547bfcee85d4e523e58c7c27ac8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/398655
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Be careful before accessing an operand's expr field (which may
be nil in some rare cases).
While at it, factor out position information so that it's only
computed when there's an error, which is almost never.
In go/types, remove an unnecessary argument to Checker.overflow.
The code is otherwise ok as it's structured slightly differently
due to the way positions are recorded in AST nodes.
Fixes#52401.
Change-Id: I447ebd9bb0c33eb6bff5e7b4d5aee37ceb0a4b14
Reviewed-on: https://go-review.googlesource.com/c/go/+/400798
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Before Go 1.18, an embedded type name in an interface could not be
parenthesized. With generalized embedding of types in interfaces,
where one might write ~(chan<- int) for clarity (making clear that
the ~ applies to the entire channel type), it also makes sense to
permit (chan<- int), or (int) for that matter.
Adjust the parser accordingly to match the spec.
(go/types already accepts the notation as specified by the spec.)
Fixes#52391.
Change-Id: Ifdd9a199c5ccc3473b2dac40dbca31d2df10d12b
Reviewed-on: https://go-review.googlesource.com/c/go/+/400797
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
The kernel's RNG is fast enough, and buffering means taking locks, which
we don't want to do. So just remove all buffering. This also means the
randomness we get is "fresher". That also means we don't need any
locking, making this potentially faster if multiple cores are hitting
GetRandom() at the same time on newer Linuxes.
Also, change the build tag of the tests to be 'unix' instead of
enumerating them.
Change-Id: Ia773fab768270d2aa20c0649f4171c5326b71d02
Reviewed-on: https://go-review.googlesource.com/c/go/+/390038
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
Auto-Submit: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're using bufio to batch reads of /dev/urandom to 4k, but we weren't
doing the same on newer platforms with getrandom/getentropy. Since the
overhead is the same for these -- one syscall -- we should batch reads
of these into the same 4k buffer. While we're at it, we can simplify a
lot of the constant dispersal.
This also adds a new test case to make sure the buffering works as
desired.
Change-Id: I7297d4aa795c00712e6484b841cef8650c2be4ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/370894
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
Auto-Submit: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The x + (-y) => x - y rule is hitted 75 times while building stage 3 and tools
and make the linux-amd64 go binary 0.007% smaller.
It transform:
NEG AX
ADD BX, AX
Into:
SUB BX, AX
Which is 2X faster (assuming this assembly in a vacum).
The x ^ (-1) => ^x rule is not hitted in the toolchain.
It transforms:
XOR $-1, AX
Into:
NOT AX
Which is more compact as it doesn't encode the immediate.
Cache usage aside, this does not affect performance
(assuming this assembly in a vacum).
On my ryzen 3600, with some surrouding code, this randomly might be 2X faster,
I guess this has to do with loading the immediate into a temporary register.
Combined to an other rule that already exists it also rewrite manual two's
complement negation from:
XOR $-1, AX
INC AX
Into:
NEG AX
Which is 2X faster.
The other rules just eliminates similar trivial cases and help constants
folding.
This should generalise to other architectures.
Change-Id: Ia1e51b340622e7ed88e5d856f3b1aa424aa039de
GitHub-Last-Rev: ce35ff2efd
GitHub-Pull-Request: golang/go#52395
Reviewed-on: https://go-review.googlesource.com/c/go/+/400714
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Even though the change in the behavior of 'runtime.GOROOT' was
not actually due to a change in the runtime package proper, I
suspect that users who notice it will look for the release note
in that section, not the 'cmd/go' section.
Fixes#51461.
Change-Id: I271752968d4152a7fdf3e170537e3072bf87ce86
Reviewed-on: https://go-review.googlesource.com/c/go/+/400814
Reviewed-by: Ian Lance Taylor <iant@google.com>
All APIs in the now-deprecated io/ioutil package have a direct
replacement in either the io or os package with the same signature,
with the notable exception of ioutil.ReadDir, as os.ReadDir has a
slightly different signature with fs.DirEntry rather than fs.FileInfo.
New code can easily make use of []fs.DirEntry directly,
but existing code may need to continue using []fs.FileInfo for backwards
compatibility reasons. For instance, I had a bit of code that exposed
the slice as a public API, like:
return ioutil.ReadDir(name)
It took me a couple of minutes to figure out what the exact equivalent
in terms of os.ReadDir would be, and a code sample would have helped.
Add one for future reference.
For #42026.
For #51927.
Change-Id: I76d46cd7d68fc609c873821755fdcfc299ffd56c
Reviewed-on: https://go-review.googlesource.com/c/go/+/399854
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The linker performs a global analysis of all nosplit call chains to
check they fit in the stack space ensured by splittable functions.
That analysis has two problems right now:
1. It's inefficient. It performs a top-down analysis, starting with
every nosplit function and the nosplit stack limit and walking *down*
the call graph to compute how much stack remains at every call. As a
result, it visits the same functions over and over, often with
different remaining stack depths. This approach is historical: this
check was originally written in C and this approach avoided the need
for any interesting data structures.
2. If some call chain is over the limit, it only reports a single call
chain. As a result, if the check does fail, you often wind up playing
whack-a-mole by guessing where the problem is in the one chain, trying
to reduce the stack size, and then seeing if the link works or reports
a different path.
This CL completely rewrites the nosplit stack check. It now uses a
bottom-up analysis, computing the maximum stack height required by
every function's call tree. This visits every function exactly once,
making it much more efficient. It uses slightly more heap space for
intermediate storage, but still very little in the scheme of the
overall link. For example, when linking cmd/go, the new algorithm
virtually eliminates the time spent in this pass, and reduces overall
link time:
│ before │ after │
│ sec/op │ sec/op vs base │
Dostkcheck 7.926m ± 4% 1.831m ± 6% -76.90% (p=0.000 n=20)
TotalTime 301.3m ± 1% 296.4m ± 3% -1.62% (p=0.040 n=20)
│ before │ after │
│ B/op │ B/op vs base │
Dostkcheck 40.00Ki ± 0% 212.15Ki ± 0% +430.37% (p=0.000 n=20)
Most of this time is spent analyzing the runtime, so for larger
binaries, the total time saved is roughly the same, and proportionally
less of the overall link.
If the new implementation finds an error, it redoes the analysis,
switching to preferring quality of error reporting over performance.
For error reporting, it computes stack depths top-down (like the old
algorithm), and reports *all* paths that are over the stack limit,
presented as a tree for compactness. For example, this is the output
from a simple test case from test/nosplit with two over-limit paths
from f1:
main.f1: nosplit stack overflow
main.f1
grows 768 bytes, calls main.f2
grows 56 bytes, calls main.f4
grows 48 bytes
80 bytes over limit
grows 768 bytes, calls main.f3
grows 104 bytes
80 bytes over limit
While we're here, we do a few nice cleanups:
- We add a debug output flag, which will be useful for understanding
what our nosplit chains look like and which ones are close to
running over.
- We move the implementation out of the fog of lib.go to its own file.
- The implementation is generally more Go-like and less C-like.
Change-Id: If1ab31197f5215475559b93695c44a01bd16e276
Reviewed-on: https://go-review.googlesource.com/c/go/+/398176
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The nosplit test was originally written when the stack limit was a
mere 128 bytes. Now it's much larger, but rather than rewriting all of
the tests, we apply a hack to just add the extra space into the stack
frames of the existing tests.
Unfortunately, we add it in the wrong place. The extra space should be
added just once per chain of nosplit functions, but instead we add it
to every frame that appears first on a line in the test's little
script language. This means that for tests like
start 0 call f1
f1 16 nosplit call f2
f2 16 nosplit call f3
f3 16 nosplit call f4
f4 16 nosplit call f5
f5 16 nosplit call f6
f6 16 nosplit call f7
f7 16 nosplit call f8
f8 16 nosplit call end
end 1000
REJECT
we add 672 bytes to *every* frame, meaning that we wind up way over
the stack limit by the end of the stanza, rather than just a little as
originally intended.
Fix this by instead adding the extra space to the first nosplit
function in a stanza. This isn't perfect either, since we could have a
nosplit -> split -> nosplit chain, but it's the best we can do without
a graph analysis.
Change-Id: Ibf156c68fe3eb1b64a438115f4a17f1a6c7e2bd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/398174
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Storing this information in the Arch eliminates some code duplication
between the compiler and linker. This information is entirely
determined by the Arch, so the current approach of attaching it to an
entire Ctxt is a little silly. This will also make it easier to use
this information from tests.
The next CL will be a rote refactoring to eliminate the
Ctxt.FixedFrameSize methods.
Change-Id: I315c524fa66a0ea99f63ae5a2a6fdc367d843bad
Reviewed-on: https://go-review.googlesource.com/c/go/+/400818
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When linking a PIE binary with the internal linker, TOC relative
relocations need to be generated. Update trampolines to indirect
call using R12 to more closely match the AIX/ELFv2 regardless of
buildmode, and work with position-indepdent code.
Likewise, update the check for offseting R_CALLPOWER relocs to
make a local call. It should be checking ldr.AttrExternal, not
ldr.IsExternal. This offset should not be adjusted for external
(non-go) object files, it is handled when ELF reloc are translated
into go relocs.
And, update trampoline tests to verify these are generated correctly
and produce a working binary using -buildmode=pie on ppc64le.
Fixes#52337
Change-Id: I8a2dea06c3237bdf0e87888b56a17b6c4c99a7de
Reviewed-on: https://go-review.googlesource.com/c/go/+/400234
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This allows the caller to decide whether MapIter should be
stack allocated or heap allocated based on whether it escapes.
In most cases, it does not escape and thus removes the utility
of MapIter.Reset (#46293). In fact, use of sync.Pool with MapIter
and calling MapIter.Reset is likely to be slower.
Change-Id: Ic93e7d39e5dd4c83e7fca9e0bdfbbcd70777f0e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/400675
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
These timeouts are empirically sometimes (but rarely) too short on
slower builders, and at any rate if this test fails “for real” we'll
want a goroutine dump in order to debug it anyway. A goroutine dump is
exactly what we get if we let the test time out on its own.
Fixes#52414.
Change-Id: Id2dd3839977bd8a41f296d67d1cccbf068fd73f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/400816
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Endlineno is lost when we call "genericSubst" to create the new
instantiation of the generic function. This will cause "readFuncLines"
to fail to read the target function.
To fix this issue, as @mdempsky pointed out, add the line in
cmd/compile/internal/noder/stencil.go:
newf.Endlineno = gf.Endlineno
Fixes#51988
Change-Id: Ib408e4ed0ceb68df8dedda4fb551309e8385aada
Reviewed-on: https://go-review.googlesource.com/c/go/+/399057
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This improves performance for memclr for sizes >= 64 and < 512 by
unrolling the loop to clear 64 bytes at a time, whereas before it was
doing 32 bytes.
On a power9, the improvement is:
Memclr/64 6.07ns ± 0% 5.17ns ± 0% -14.86% (p=1.000 n=1+1)
Memclr/256 11.8ns ± 0% 8.3ns ± 0% -30.10% (p=1.000 n=1+1)
GoMemclr/64 5.58ns ± 0% 5.02ns ± 0% -10.04% (p=1.000 n=1+1)
GoMemclr/256 12.0ns ± 0% 8.8ns ± 0% -26.62% (p=1.000 n=1+1)
Change-Id: I929389ae9e50128cba81e0c412e7ba431da7facc
Reviewed-on: https://go-review.googlesource.com/c/go/+/399895
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This code was trying to iterate codepoints, but didn't reslice the string,
so it was reading the first codepoint over and over, if the string length was
not a multiple of the first codepoint length, this would cause to overshoot
past the end of the string.
This was a latent bug introduced in CL 384265 but was revealed to
Ngolo-fuzzing in OSS-Fuzz in CL 397277.
Fixes#52353
Change-Id: I13f0352e6ad13a42878927f3b1c18c58360dd40c
GitHub-Last-Rev: 424f6cfad1
GitHub-Pull-Request: golang/go#52356
Reviewed-on: https://go-review.googlesource.com/c/go/+/400240
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
No test because we already have a test in the syscall package.
The issue reports 1 failure per 100,000 iterations, which is rare enough
that our builders won't catch the problem.
Fixes#52226
Change-Id: I17633ff6cf676b6d575356186dce42cdacad0746
Reviewed-on: https://go-review.googlesource.com/c/go/+/400315
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
There are some symbol attributes that are encoded in the object
file. Currently, they are lost when cloning a symbol to external.
Copy them over.
Also delete CopyAttributes as it is no longer called anywhere.
Change-Id: I1497e3223a641704bf35aa3e904dd0eda2f8ec3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/400574
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The current implementation, although more succinct, relies on a runtime
lookup to a "constant" unexported map (which also needs to be
initialized at runtime).
The proposed implementation is able to be optimized by the compiler at
build-time, resulting in *much* more efficient instructions.
Additionally, unused string literals may even be removed altogether
from the generated binary in some cases.
This change is fully backwards-compatible behavior-wise with the
existing implementation.
Change-Id: I36450320aacff5b322195820552f2831d4fecd52
GitHub-Last-Rev: e2058f132e
GitHub-Pull-Request: golang/go#49811
Reviewed-on: https://go-review.googlesource.com/c/go/+/367201
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Refuse to create certificates with negative serial numbers, as they
are explicitly disallowed by RFC 5280.
We still allow parsing certificates with negative serial numbers,
because in the past there were buggy CA implementations which would
produce them (although there are currently *no* trusted certificates
that have this issue). We may want to revisit this decision if we can
find metrics about the prevalence of this issue in enterprise settings.
Change-Id: I131262008db99b6354f542f335abc68775a2d6d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/400494
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This adds a straight-forward implementation of the functionality.
A more performant version could be added that unrolls the loop
as is done in google.golang.org/protobuf/encoding/protowire,
but usages that demand high performance can use that package instead.
Fixes#51644
Change-Id: I9d3b615a60cdff47e5200e7e5d2276adf4c93783
Reviewed-on: https://go-review.googlesource.com/c/go/+/400176
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
In issue #17671, there are a endless loop if printing
the panic value panics, CL 30358 has fixed that.
As issue #52257 pointed out, above change should not
discard the value from panic while panicking.
With this CL, when we recover from a panic in error.Error()
or stringer.String(), and the recovered value is string,
then we can print it normally.
Fixes#52257
Change-Id: Icfcc4a1a390635de405eea04904b4607ae9e3055
Reviewed-on: https://go-review.googlesource.com/c/go/+/399874
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The noopt builder is broken, because with -N we get two OpSB opcodes
(one for the function as a whole, one introduced by the jumptable
rewrite rule), and they fight each other for a register.
Without -N, the two OpSB get CSEd, so optimized builds are ok.
Maybe we fix regalloc to deal with this case, but it's simpler
(and maybe more correct?) to disable jump tables with -N.
Change-Id: I75c87f12de6262955d1df787f47c53de976f8a5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/400455
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reorganize the way we rewrite expression switches on strings, so that
jump tables are naturally used for the outer switch on the string length.
The changes to the prove pass in this CL are required so as to not repeat
the test for string length in each case.
name old time/op new time/op delta
SwitchStringPredictable 2.28ns ± 9% 2.08ns ± 5% -9.04% (p=0.000 n=10+10)
SwitchStringUnpredictable 10.5ns ± 1% 9.5ns ± 1% -9.08% (p=0.000 n=9+10)
Update #5496
Update #34381
Change-Id: Ie6846b1dd27f3e472f7c30dfcc598c68d440b997
Reviewed-on: https://go-review.googlesource.com/c/go/+/395714
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
So that the inliner knows all the other cases are dead and doesn't
accumulate any cost for them.
The canonical case for this is switching on runtime.GOOS, which occurs
several places in the stdlib.
Fixes#50253
Change-Id: I44823aaebb6c1b03c9b0c12d10086db81954350f
Reviewed-on: https://go-review.googlesource.com/c/go/+/399694
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Performance is kind of hard to exactly quantify.
One big difference between jump tables and the old binary search
scheme is that there's only 1 branch statement instead of O(n) of
them. That can be both a blessing and a curse, and can make evaluating
jump tables very hard to do.
The single branch can become a choke point for the hardware branch
predictor. A branch table jump must fit all of its state in a single
branch predictor entry (technically, a branch target predictor entry).
With binary search that predictor state can be spread among lots of
entries. In cases where the case selection is repetitive and thus
predictable, binary search can perform better.
The big win for a jump table is that it doesn't consume so much of the
branch predictor's resources. But that benefit is essentially never
observed in microbenchmarks, because the branch predictor can easily
keep state for all the binary search branches in a microbenchmark. So
that benefit is really hard to measure.
So predictable switch microbenchmarks are ~useless - they will almost
always favor the binary search scheme. Fully unpredictable switch
microbenchmarks are better, as they aren't lying to us quite so
much. In a perfectly unpredictable situation, a jump table will expect
to incur 1-1/N branch mispredicts, where a binary search would incur
lg(N)/2 of them. That makes the crossover point at about N=4. But of
course switches in real programs are seldom fully unpredictable, so
we'll use a higher crossover point.
Beyond the branch predictor, jump tables tend to execute more
instructions per switch but have no additional instructions per case,
which also argues for a larger crossover.
As far as code size goes, with this CL cmd/go has a slightly smaller
code segment and a slightly larger overall size (from the jump tables
themselves which live in the data segment).
This is a case where some FDO (feedback-directed optimization) would
be really nice to have. #28262
Some large-program benchmarks might help make the case for this
CL. Especially if we can turn on branch mispredict counters so we can
see how much using jump tables can free up branch prediction resources
that can be gainfully used elsewhere in the program.
name old time/op new time/op delta
Switch8Predictable 1.89ns ± 2% 1.27ns ± 3% -32.58% (p=0.000 n=9+10)
Switch8Unpredictable 9.33ns ± 1% 7.50ns ± 1% -19.60% (p=0.000 n=10+9)
Switch32Predictable 2.20ns ± 2% 1.64ns ± 1% -25.39% (p=0.000 n=10+9)
Switch32Unpredictable 10.0ns ± 2% 7.6ns ± 2% -24.04% (p=0.000 n=10+10)
Fixes#5496
Update #34381
Change-Id: I3ff56011d02be53f605ca5fd3fb96b905517c34f
Reviewed-on: https://go-review.googlesource.com/c/go/+/357330
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Name the arguments in a way that is more self-describing.
Many code editor tools show a snippet of the function and
its arguments. However, "x" and "y" are not helpful in determining
which is the sign and which is the magnitude,
short of reading the documentation itself.
Name the sign argument as "sign" to be explicit.
This follows the same naming convention as IsInf.
Change-Id: Ie3055009e475f96c92d5ea7bfe9828eed908c78b
Reviewed-on: https://go-review.googlesource.com/c/go/+/400177
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
In CreateCertificate, if there are no extensions, don't include the
extensions SEQUENCE in the encoded certificate.
Why, you might ask, does the encoding/asn1 tag 'optional' not do
the same thing as 'omitempty'? Good question, no clue, fixing that
would probably break things in horrific ways.
Fixes#52319
Change-Id: I84fdd5ff3e4e0b0a59e3bf86e7439753b1e1477b
Reviewed-on: https://go-review.googlesource.com/c/go/+/399827
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
The -trust flag has become obsolete.
A list of individual reviewers may become out of date, and these
scripts (and their backports) are probably not the optimal place
for it.
Change-Id: Ibf1bc508f0192b160c955e3deabae34f4d1ab54c
Reviewed-on: https://go-review.googlesource.com/c/go/+/399538
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The ABI mangling code skips symbols that are not loaded from Go
objects. Usually that is fine, as other symbols don't need name
mangling. But trampolines are linker generated and have the same
symbol version (ABI) as the underlying symbol. We need to avoid
symbol name collisions for trampolines, such as a trampoline to
f<ABI0> and a trampoline to f<ABIInternal>. We could explicitly
incorportate the ABI into the trampoline name. But as we already
have the name mangling scheme we could just use that.
The original code excludes external symbols probably because
symbols from C object don't need mangling. But a C symbol and a
Go symbol shouldn't have same name, and so the condition won't
apply.
Also exclude static symbols as they don't need mangling.
Change-Id: I298eb1d64bc0c3da0154f0146b95c4d26ca2f47a
Reviewed-on: https://go-review.googlesource.com/c/go/+/399894
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
They are already in a good order. The sort here does nothing, as
all the SymValues are 0. Sorting just arbitrarily permutes items
because everything is equal and the sort isn't stable.
Not sure why the ordering of these symbols matter. That ordering was
added in CL 243223.
Change-Id: Iee153394afdb39387701cfe0375bc022cf4bd489
Reviewed-on: https://go-review.googlesource.com/c/go/+/399540
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
check_testdata/check_testdata.go used the encoding of the corpus entry
file, rather than the input string itself, when checking the expected
size of the minimized value. Instead, use the actual byte length, which
should bypass flakiness.
While we are here, use somewhat simpler fuzz targets, that use byte
slices rather than strings, and only execute the targets when fuzzing (
skipping the 'run' phase.)
Fixes#52285
Change-Id: I48c3780934891eec4a9e38d93abb4666091cb580
Reviewed-on: https://go-review.googlesource.com/c/go/+/399814
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
The Faccessat call checks the user, group, or other permission bits of a
file to see if the calling process can access it. The test to see if the
group permissions should be used was made with the wrong group id, using
the process's group id rather than the file's group id. Fix this to use
the correct group id.
No test since we cannot easily change file permissions when not running
as root and the test is meaningless if running as root.
For #52313
Change-Id: I4e2c84754b0af7830b40fd15dedcbc58374d75ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/399539
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When we added VCS stamping in the Go 1.18 release, we defaulted to
-buildvcs=true, on the theory that most folks will actually want VCS
information stamped.
We also made -buildvcs=true error out if a VCS directory is found and
no VCS tool is available, on the theory that a user who builds with
'-buildvcs=true' will be very surprised if the VCS metadata is
silently missing.
However, that causes a problem for CI environments that don't have the
appropriate VCS tool installed. (And we know that's a common situation
because we're in that situation ourselves — see #46693!)
The new '-buildvcs=auto' setting provides a middle ground: it stamps
VCS information by default when the tool is present (and reports
explicit errors if the tool errors out), but omits the metadata
when the tool isn't present at all.
Fixes#51748.
Updates #51999.
Change-Id: Iebc955c2af0abca9b7517f62ca48b1d944eb2df4
Reviewed-on: https://go-review.googlesource.com/c/go/+/398855
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The existing implementation of `load.resolveEmbed`
uses an expression like `path[len(pkgdir)+1:]`.
Though the `+1` is intended to remove a prefix slash,
the expression returns an incorrect path when `pkgdir`
is "/". (ex.: when removing "/" from "/foo", want "foo",
but got "oo")
It seems that `str.TrimFilePathPrefix` would solve
the problem, but the function contains the same bug.
So, this commit fixes `str.TrimFilePathPrefix` then
applies it to `load.resolveEmbed` to solve the issue.
The fix is quite simple. First, remove prefix. Then
check whether the remained first letter is equal to
`filepath.Separator`. If so, remove it then return.
Fixed#49570
Change-Id: I26ab727ee4dfcbf51ed9bd0a573957ced2154515
Reviewed-on: https://go-review.googlesource.com/c/go/+/396694
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Code generators may reasonably expect to find the GOROOT for which the
code is being generated.
If the generator invokes 'go run' (which ought to be reasonable to do)
and the user has set 'GOFLAGS=trimpath' (which also ought to be
reasonable), then either 'go generate' or 'go run' needs to set GOROOT
explicitly.
I would argue that it is more appropriate for 'go generate' to set
GOROOT than for 'go run' to do so, since a user may reasonably invoke
'go run' to reproduce a user-reported bug in a standalone Go program,
but should not invoke 'go generate' except to regenerate code for a Go
package.
Updates #51461.
Change-Id: Iceba233b4eebd57c40cf5dcd4af9031d210dc9d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/399157
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
After CL 398014 fixed a compiler deadlock on syntax errors,
this CL adds a test case and more details for that.
How it was fixed:
CL 57751 introduced a channel "sem" to limit the number of
simultaneously open files.
Unfortunately, when the number of syntax processing goroutines
exceeds this limit, will easily trigger deadlock.
In the original implementation, "sem" only limited the number
of open files, not the number of concurrent goroutines, which
will cause extra goroutines to block on "sem". When the p.err
of the following iteration happens to be held by the blocking
goroutine, it will fall into a circular wait, which is a deadlock.
CL 398014 fixed the above deadlock, also see issue #52127.
First, move "sem <- struct{}{}" to the outside of the syntax
processing goroutine, so that the number of concurrent goroutines
does not exceed the number of open files, to ensure that all
goroutines in execution can eventually write to p.err.
Second, move the entire syntax processing logic into a separate
goroutine to avoid blocking on the producer side.
Change-Id: I1bb89bfee3d2703784f0c0d4ded82baab2ae867a
Reviewed-on: https://go-review.googlesource.com/c/go/+/399054
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Now that gofmt is reformatting these, we can't get away with
not knowing about directives such as //export and //extern (for gccgo).
Otherwise "//export foo" and "//extern foo" turn into "// export foo",
and "// extern foo", which are completely different meanings.
For #51082.
Change-Id: Id0970331fa0b52ab5fa621631b5fa460767068bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/399734
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
[This CL is part of a sequence implementing the proposal #51082.
The design doc is at https://go.dev/s/godocfmt-design.]
Use go/doc/comment to reformat doc comments into a
standard form, enabling future expansion later and generally
making it easier to edit and read doc comments.
For #51082.
Change-Id: I6ab3b80846f03d781951111e4c36f86f47d21bb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/384264
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
[This CL is part of a sequence implementing the proposal #51082.
The design doc is at https://go.dev/s/godocfmt-design.]
Implement wrapping of text output, for the “go doc” command.
The algorithm is from D. S. Hirschberg and L. L. Larmore,
“The least weight subsequence problem,” FOCS 1985, pp. 137-143.
For #51082.
Change-Id: I07787be3b4f1716b8ed9de9959f94ecbc596cc43
Reviewed-on: https://go-review.googlesource.com/c/go/+/397283
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
[This CL is part of a sequence implementing the proposal #51082.
The design doc is at https://go.dev/s/godocfmt-design.]
Implement just the data structures of the new API for
parsing and printing doc comments, as well as a syntax tree
form for inspecting and manipulating them.
The API itself was discussed and accepted as part of the
proposal process in #51082.
For #51082.
Change-Id: Iae7fbc85705964585273b970c5c62e394feb1288
Reviewed-on: https://go-review.googlesource.com/c/go/+/397276
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the load tests, we only want to test the assembly produced by
the load operations. If we use the global variable sink, it will produce
one load operation and one store operation(assign to sink).
For example:
func load_be64(b []byte) uint64 {
sink64 = binary.BigEndian.Uint64(b)
}
If we compile this function with GOAMD64=v3, it may produce MOVBEQload
and MOVQstore or MOVQload and MOVBEQstore, but we only want MOVBEQload.
Discovered when developing CL 395474.
Same for the store tests.
Change-Id: I65c3c742f1eff657c3a0d2dd103f51140ae8079e
Reviewed-on: https://go-review.googlesource.com/c/go/+/397875
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
The zip reader checks that the uncompressed file size is valid
after all compressed files read until EOF.
However in between reading each file, there could have already
been an overflow where nread > UncompressedSize64 hence this
change will now return ErrFormat in such situations.
Fixes#49791
Change-Id: If3584a57d173de6a97bf35c07d2a99ff6972f820
Reviewed-on: https://go-review.googlesource.com/c/go/+/366854
Trust: mzh <mzh@golangcn.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
For various reasons Intel has suspended viewing web pages in the .ru
domain, so change the domain of the documents cited in the code
to the .com domain. In addition, the chapter numbers in the document
were updated and fix it.
Change-Id: I718be1548ec46f05ebc4f73873d4635c1d5fc76d
Reviewed-on: https://go-review.googlesource.com/c/go/+/399060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
It is not necessary to expand the key twice for each direction,
the decrypt key can be stored in reverse simultaneously.
Likewise, there is no need to store the key length alongside the
expanded keys, this is now inferred by the key length slice.
Noteably, the key expansion benchmark assumes the key array size
is the exact size of the expanded key.
Now, the ppc64le aes asm interface is identical to the generic
asm interface. Callsites and usage is updated to reflect this.
Performance uplift on POWER9 is substantial:
name old time/op new time/op delta
Expand 167ns ± 0% 49ns ± 0% -70.55%
Change-Id: I3fdaf9c27e8860e8150d4683eb4046d97a53293a
Reviewed-on: https://go-review.googlesource.com/c/go/+/398894
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Paul Murphy <murp@ibm.com>
Call initCommonHeader in canonicalMIMEHeaderKey to ensure that
commonHeader is initialized before use. Remove all other calls to
initCommonHeader, since commonHeader is only used in
canonicalMIMEHeaderKey.
This prevents a race condition: read of commonHeader before
commonHeader has been initialized.
Add regression test that triggers the race condition which can be
detected by the race detector.
Fixes#46363
Change-Id: I00c8c52c6f4c78c0305978c876142c1b388174af
Reviewed-on: https://go-review.googlesource.com/c/go/+/397575
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
After CL 379474 has landed, the only remaining cgo export header
incompatibility with MSVC is the use of the _Complex macro,
which is not supported in MSVC even when it is part of the ISO C99
standard (1).
Since MSVC 2015 (2), complex math are supported via _Fcomplex and
_Dcomplex, which are equivalent to float _Complex and double _Complex.
As MSVC and C complex types have the same memory layout, we should
be able to typedef GoComplex64 and GoComplex128 to the appropriate
type in MSVC.
It is important to note that this CL is not adding MSVC support to cgo.
C compilers should still be GCC-compatible.
This CL is about allowing to include, without further modifications,
a DLL export header generated by cgo, normally using Mingw-W64 compiler,
into a MSVC project. This was already possible if the export header
changes introduced in this CL were done outside cgo, either manually or
in a post-build script.
Fixes#36233
1: https://docs.microsoft.com/en-us/cpp/c-runtime-library/complex-math-support
2: https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?c-standard-library-features-1
Change-Id: Iad8f26984b115c728e3b73f3a8334ade7a11cfa1
Reviewed-on: https://go-review.googlesource.com/c/go/+/397134
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Auto-Submit: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
It has been agreed that we should prefer the US spelling of words like
"canceling" over "cancelling"; for example, see https://go.dev/cl/14526.
Fix a few occurrences of the "canceling" inconsistency, as well as:
* signaling
* tunneling
* marshaling
Change-Id: I99f3ba0a700a9f0292bc6c1b110af31dd05f1ff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/398734
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The ported cryptogam implementation uses a subtle and tricky mechanism
using lxv/vperm/lvsl to load unaligned vectors. This is difficult to
read, and may read and write unrelated bytes if reading from an
unaligned address.
Instead, POWER8 instructions can be used to load from unaligned memory
with much less overhead. Alignment interrupts only occur when reading
or writing cache-inhibited memory, which we assume isn't used in go
today, otherwise alignment penalties are usually marginal.
Instead lxvd2x+xxpermdi and xxpermdi+stxvd2x can be used to emulate
unaligned LE bytewise loads, similar to lxv/stxv on POWER9 in
little-endian mode.
Likewise, a custom permute vector is used to emulate BE bytewise
storage operations, lxvb16x/stxvb16x, on POWER9.
This greatly simplifies the code, and it makes it much easier to store
the keys in reverse (which is exactly how the decrypt keys are expected
to be stored).
Change-Id: I2334337e31a8fdf8d13ba96231142a039f237098
Reviewed-on: https://go-review.googlesource.com/c/go/+/395494
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Paul Murphy <murp@ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
With this change, the shift checking code matches the corresponding
go/types code, but for the differences in the internal error reporting,
and call of check.overflow.
The change leads to the recording of an untyped int value if the RHS
of a non-constant shift is an untyped integer value. Adjust the type
in the compiler's irgen accordingly. Add test/shift3.go to verify
behavior.
Change-Id: I20386fcb1d5c48becffdc2203081fb70c08b282d
Reviewed-on: https://go-review.googlesource.com/c/go/+/398236
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This reverts a behavior change introduced in Go 1.18 (commit 9f69a443;
CL 340049). In Go 1.17 and earlier, draw.Draw(etc, draw.Src) with
image.NRGBA dst and src images would pass through a (heap allocated)
color.Color interface value holding a color.NRGBA concrete value.
Threading that color.NRGBA value all the way through preserves
non-premultiplied alpha transparency information (distinguishing e.g.
transparent blue from transparent red).
CL 340049 optimized out that heap allocation (per pixel), calling new
SetRGBA64At and RGBA64At methods instead. However, these methods (like
the existing image/color Color.RGBA method) work in premultiplied alpha,
so any distinction between transparent colors is lost.
This commit re-introduces the preservation of distinct transparencies,
when dst and src are both *image.NRGBA (or both *image.NRGBA64) and the
op is draw.Src.
Fixes#51893
Change-Id: Id9c64bfeeaecc458586f169f50b99d6c8aa52a7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/396795
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
In fields that start with the same character as the right delimiter, the
whole delimiter needs to be checked. The first character alone is not
sufficient.
Fixes#52165
Change-Id: I1e4086048417693757f34d0e9ff3bf86aba0d35c
Reviewed-on: https://go-review.googlesource.com/c/go/+/398475
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
The source of these errors is undiagnosed, but they have only been
observed on netbsd builders (on a variety of architectures).
Tested manually by injecting this code into the test's handler:
if mrand.Intn(4) == 0 {
if conn, _, err := w.(Hijacker).Hijack(); err == nil {
conn.(*net.TCPConn).SetLinger(0)
conn.Close()
return
}
}
and temporarily disabling the 'runtime.GOOS' part of the condition.
For #52168.
Change-Id: I10965803e5a0d493ac4a000575de8b5f0266989c
Reviewed-on: https://go-review.googlesource.com/c/go/+/398635
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Adds a new, cryptobyte based, CRL parser, which returns a
x509.RevocaitonList, rather than a pkix.CertificateList. This allows us
to return much more detailed information, as well as leaving open the
option of adding further information since RevocationList is not a
direct ASN.1 representation like pkix.CertificateList. Additionally
a new method is added to RevocationList, CheckSignatureFrom, which is
analogous to the method with the same name on Certificate, which
properly checks that the signature is from an issuing certiifcate.
This change also deprecates a number of older CRL related functions and
types, which have been replaced with the new functionality introduced
in this change:
* crypto/x509.ParseCRL
* crypto/x509.ParseDERCRL
* crypto/x509.CheckCRLSignature
* crypto/x509/pkix.CertificateList
* crypto/x509/pkix.TBSCertificateList
Fixes#50674
Change-Id: I27dc219e39bef09a396e666b4fccaa32578fd913
Reviewed-on: https://go-review.googlesource.com/c/go/+/390834
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
'go tool dist env' outputs different (and fewer) environment variables
than 'go env'. The 'go tool dist env' variables should be
authoritative, whereas many printed by 'go env' are merely
informational (and not intended to be overridden in the actual
environment).
Fixes#52009
Change-Id: Ic0590153875183135cebf7ca55ead7c2b4038569
Reviewed-on: https://go-review.googlesource.com/c/go/+/398061
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
cmd/internal/moddeps is currently failing on the longtest builders
because vendored third-party dependencies were accidentally edited as
part of CL 384262 (a global cleanup of the standard library).
Updates #51082
Change-Id: I6f79c8f1177420a51128ce42d6c14fa5dcc4bd7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/398455
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For very small inputs, h.Reset+h.Write+h.Sum64 is fundamentally
slower than a single operation, by about a factor of two, because
Write must copy the data into h's buffer, just in case there is another
Write before the Sum64.
A single function doing the whole sequence knows there is no extra
write that will happen, so it doesn't need the buffer, so it avoids the copy.
Fixes#42710.
Change-Id: Icc79c68ccb10827f6640071d026df86b4940fcc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/392494
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
A future change to gofmt will rewrite
// Doc comment.
//go:foo
to
// Doc comment.
//
//go:foo
Apply that change preemptively to all comments (not necessarily just doc comments).
For #51082.
Change-Id: Iffe0285418d1e79d34526af3520b415a12203ca9
Reviewed-on: https://go-review.googlesource.com/c/go/+/384260
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
go/doc in all its forms applies this replacement when rendering
the comments. We are considering formatting doc comments,
including doing this replacement as part of the formatting.
Apply it to our source files ahead of time.
For #51082.
Change-Id: Ifcc1f5861abb57c5d14e7d8c2102dfb31b7a3a19
Reviewed-on: https://go-review.googlesource.com/c/go/+/384262
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If we run out of time on the first subtest, we don't want to start the
second one with essentially no time remaining. (Moreover, there is no
compelling reason not to run these tests in parallel, since they send
signals to separate processes.)
For #51054.
Change-Id: I0424e08c3a9d2db986568d5a5c004859b52f7c51
Reviewed-on: https://go-review.googlesource.com/c/go/+/398454
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Henrique Vicente de Oliveira Pinto <henriquevicente@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change does four things:
* removes the chain cache
* during path building, equality is determined by checking if the
subjects and public keys match, rather than checking if the entire
certificates are equal
* enforces EKU suitability during path building
* enforces name constraints on intermediates and roots which have
SANs during path building
The chain cache is removed as it was causing duplicate chains to be
returned, in some cases shadowing better, shorter chains if a longer
chain was found first.
Checking equality using the subjects and public keys, rather than the
entire certificates, allows the path builder to ignore chains which
contain cross-signature loops.
EKU checking is done during path building, as the previous behavior
of only checking EKUs once the path had been built caused the path
builder to incorrectly ignore valid paths when it encountered a path
which would later be ruled invalid because of unacceptable EKU usage.
Name constraints are applied uniformly across all certificates, not
just leaves, in order to be more consistent.
Fixes#48869Fixes#45856
Change-Id: I4ca1cd43510d061e148f953d6c1ed935100fdb10
Reviewed-on: https://go-review.googlesource.com/c/go/+/389555
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Cherry Mui <cherryyz@google.com>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
cmd/dist may set and/or unset variables before building, and at any
rate it is fragile to run 'go install' before sourcing env.bat.
The build-stamp information embedded by the 'go' command is currently
sensitive to whether CGO_* variables are implicit or explicit, so running
'go install' before env.bat may cause stamped metadata to become stale.
(Explicitly setting to the default arguably ought to produce the same
metadata as leaving the variables unset, but that's a separate issue
and a bigger cleanup.)
Moreover, run.bat is supposed to parallel run.bash, and run.bash
already hasn't invoked 'go install' itself since CL 6531!
For #52009
Change-Id: Ie35217913f02cc7e0c3f9b12874abd7416473478
Reviewed-on: https://go-review.googlesource.com/c/go/+/398060
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
These fields have been parsed as quoted fields since CL 334732,
but we missed the unparsing side in 'go env'.
Certain scripts (notably make.ba{sh,t}) expect to be able to set the
environment to exactly what 'go env' reports, so for round-trip
purposes it is important to match the marshaling and unmarshaling
functions.
(Noticed while debugging #52009.)
Updates #41400
Change-Id: I0ff39b7a6e1328111c285c97cd23f79b723f3c73
Reviewed-on: https://go-review.googlesource.com/c/go/+/398058
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It had not been doing anything since CL 233939, because the Params
method was getting upgraded to the assembly one. We could make it use
genericParamsForCurve, but really we need lower-level, targeted Go 1.18
fuzz targets in nistec now.
Change-Id: I5b198a309aa90ecef9c04aaa6c107d5c0a41a44b
Reviewed-on: https://go-review.googlesource.com/c/go/+/396254
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
rand.Prime does not guarantee the precise prime selection algorithm as
part of its contract. For example, it changed slightly in CL 387554. We
want to ensure that no tests come to rely on it staying the same, so
just like other cryptographic functions that use randomness in an
unspecified way (ECDSA signing, RSA PKCS #1 v1.5 encryption, RSA key
generation), make it randomly read an extra byte or not.
Change-Id: Ib9079c03360812d412b7c21d5a06caadabb4a8bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/391554
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
In the Type identity section, the example provides various types as givens.
The example refers to the type *T5, but it is not provided in the givens.
I am assuming this was a typo, and was meant to refer to *A1 or *B1.
*B1 seems to be in alignment with the rest of the provided examples.
Change-Id: I554319ee8bca185c3643559321417e8b2a544ba0
GitHub-Last-Rev: e80560d32a
GitHub-Pull-Request: golang/go#52143
Reviewed-on: https://go-review.googlesource.com/c/go/+/398075
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
When using Go 1.4 this doesn't matter, but when using Go 1.17,
the bootstrap toolchain will complain about unknown GOEXPERIMENT settings.
Clearly GOEXPERIMENT is for the toolchain being built, not the bootstrap.
Already submitted as CL 395879 on the dev.boringcrypto branch,
but needed on master to set up GOEXPERIMENT=boringcrypto
builder ahead of merge.
For #51940.
Change-Id: Ib6a4099cca799b4d5df1974cdb5471adb0fd557d
Reviewed-on: https://go-review.googlesource.com/c/go/+/397894
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The SHRX/SHLX instruction can take any general register as the shift count operand, and can read source from memory. This CL introduces some operators to combine load and shift to one instruction.
For #47120
Change-Id: I13b48f53c7d30067a72eb2c8382242045dead36a
Reviewed-on: https://go-review.googlesource.com/c/go/+/385174
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Now that there's a native go/types importer for unified IR, the
compiler no longer needs to stay backwards compatible with old iexport
importers.
This CL also updates the go/types and go/internal/gcimporter tests to
expect that the unified IR importer sets the receiver parameter type
to the underlying Interface type, rather than the Named type. This is
a temporary workaround until we make a decision on #49906.
Notably, this makes `GOEXPERIMENT=unified go test` work on generics
code without requiring `-vet=off` (because previously cmd/vet was
relying on unified IR's backwards-compatible iexport data, which
omitted generic types).
Change-Id: Iac7a2346bb7a91e6690fb2978fb702fadae5559d
Reviewed-on: https://go-review.googlesource.com/c/go/+/386004
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL ports unified IR's types2 importer back to the go/types
API. Notably, it drops support for lazy importing, because those APIs
aren't exposed yet via go/types.
Also, it supports unified IR's "final" data format, which wholey
replaces the iexport data format rather than the current
backwards-compatible hack that cmd/compile uses. The next CL will
switch the compiler to using this same format.
Change-Id: I44e1744bbdc384c9c354119975e68befdc117cff
Reviewed-on: https://go-review.googlesource.com/c/go/+/386002
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The existing code errors out immediately if the argument is not
"comparable", making it impossible to test a slice, map, and so
on from being compared to nil.
Fix by delaying the "comparable" error check until we encounter
an actual check between two non-comparable, non-nil values.
Note for the future: reflect makes it unnecessarily clumsy
to deal with nil values in cases like this. For instance, it
should be possible to check if a value is nil without stepping
around a panic. See the new functions isNil and canCompare
for my (too expensive) workaround.
Fixes#51642
Change-Id: Ic4072698c4910130ea7e3d76e7a148d8a8b88162
Reviewed-on: https://go-review.googlesource.com/c/go/+/392274
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Disable SHA-1 signature verification in Certificate.CheckSignatureFrom,
but not in Certificate.CheckSignature. This allows verification of OCSP
responses and CRLs, which still use SHA-1 signatures, but not on
certificates.
Updates #41682
Change-Id: Ia705eb5052e6fc2724fed59248b1c4ef8af6c3fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/394294
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Jordan Liggitt <liggitt@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
On PPC64LE, the C ABI requires SP to be 16-byte aligned. Also, in
the C ABI the callee may save LR, CR, R2 etc. to the 4 reserved
words of the caller's frame. This CL aligns the SP and reserves
the space on stack.
Change-Id: I738880028815b7d3402647e4ebbdae37f45acc77
Reviewed-on: https://go-review.googlesource.com/c/go/+/397675
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Per the spec, "the type sets of all non-interface terms must be
pairwise disjoint (the pairwise intersection of the type sets must
be empty)" in a union.
For the overlap test, the existing implementation casually mixed
syntactic union terms (which may have interface type) with type set
terms (which are normalized/expanded and must not have interface
type). As a consequence, in some cases the overlap test failed.
This change skips terms with interface types in the overlap test.
Fixes#51607.
Change-Id: I8ae9953db31f0a0428389c6a45a6696aa2450219
Reviewed-on: https://go-review.googlesource.com/c/go/+/397695
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The fix for #51112 introduced a depth check but used
ErrInternalError to avoid introduce new API in a CL that
would be backported to earlier releases.
New API accepted in proposal #51684.
This CL adds a distinct error for this case.
For #51112.
Fixes#51684.
Change-Id: I068fc70aafe4218386a06103d9b7c847fb7ffa65
Reviewed-on: https://go-review.googlesource.com/c/go/+/384617
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The return value "abi" of func "funcLayout" is the same as package
"internal/abi", which currently works fine, but it is more reliable to
avoid conflicts.
Change-Id: I83715dd79beff7cb3fc25747fef186dc0e2dfa8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/385414
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
LZCNT is similar to BSR, but BSR(x) is undefined when x == 0, so using
LZCNT can avoid a special case for zero input. Except that case,
LZCNTQ(x) == 63-BSRQ(x) and LZCNTL(x) == 31-BSRL(x).
And according to https://www.agner.org/optimize/instruction_tables.pdf,
LZCNT instructions are much faster than BSR on AMD CPU.
name old time/op new time/op delta
LeadingZeros-8 0.91ns ± 1% 0.80ns ± 7% -11.68% (p=0.000 n=9+9)
LeadingZeros8-8 0.98ns ±15% 0.91ns ± 1% -7.34% (p=0.000 n=9+9)
LeadingZeros16-8 0.94ns ± 3% 0.92ns ± 2% -2.36% (p=0.001 n=10+10)
LeadingZeros32-8 0.89ns ± 1% 0.78ns ± 2% -12.49% (p=0.000 n=10+10)
LeadingZeros64-8 0.92ns ± 1% 0.78ns ± 1% -14.48% (p=0.000 n=10+10)
Change-Id: I125147fe3d6994a4cfe558432780408e9a27557a
Reviewed-on: https://go-review.googlesource.com/c/go/+/396794
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add GenerateConsoleCtrlEvent call to internal syscall package.
Define ErrProcessDone while reviewing handling of os.Signal().
Update test to run for windows using the added call.
Fixes#42311Fixes#46354
Change-Id: I460955efc76c4febe04b612ac9a0670e62ba5ff3
Reviewed-on: https://go-review.googlesource.com/c/go/+/367495
Trust: Patrik Nyblom <pnyb@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Octal values over 255, like \400 or \777, are illegal. It wasn't clear if the expected behavior was a compile error, encoding the value as two characters, or if the value would be capped at 255.
This example explicitly shows that octal values over 255 are illegal.
Change-Id: I45d94680107029c5f083e5d434e6270cc5b258c1
GitHub-Last-Rev: f6bef0379f
GitHub-Pull-Request: golang/go#52111
Reviewed-on: https://go-review.googlesource.com/c/go/+/397555
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
CL 337529 introduced upfront type-checking of constant shift operands,
to avoid converting their type to uint (per the spec). However, it
had an oversight in that the checks intended for non-constant operands
still ran after the explicit checking of constant operands. As a
result, there are at least two bugs:
- When GoVersion is < 1.13, we report spurious errors for untyped
constant shift operands.
- When the operand is an untyped float constant, we still convert to
uint (this was a known bug reported in #47410).
Looking at this now, it seems clear that we can avoid both of these bugs
by simply not running the additional checks in the case of a constant
operand. However, this should be considered with some care, as shifts
are notoriously tricky.
Updates #47410Fixes#52031
Change-Id: Ia489cc5470b92a8187d3de0423d05b309daf47bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/396775
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For whatever reason (perhaps some tool does this), a handful of comments,
including some doc comments, have TODOs formatted like:
// TODO(name): Text here and
// more text aligned
// under first text.
In doc comments the second line turns into a <pre> block,
which is undesirable in this context.
Rewrite those to unindent, like this instead:
// TODO(name): Text here and
// more text aligned
// at left column.
For #51082.
Change-Id: Ibf5145659a61ebf9496f016752a709a7656d2d4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/384258
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
A run of lines that are indented with any number of spaces or tabs
format as a <pre> block. This commit fixes various doc comments
that format badly according to that (standard) rule.
For example, consider:
// - List item.
// Second line.
// - Another item.
Because the - lines are unindented, this is actually two paragraphs
separated by a one-line <pre> block. This CL rewrites it to:
// - List item.
// Second line.
// - Another item.
Today, that will format as a single <pre> block.
In a future release, we hope to format it as a bulleted list.
Various other minor fixes as well, all in preparation for reformatting.
For #51082.
Change-Id: I95cf06040d4186830e571cd50148be3bf8daf189
Reviewed-on: https://go-review.googlesource.com/c/go/+/384257
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Following CL 333529, update syso files for other architectures.
Windows/AMD64 is not updated, waiting for Than for C toolchain
updates.
OpenBSD/AMD64 is not updated as upstream LLVM TSAN removed OpenBSD
support (#52090).
Linux/PPC64LE is not updated due to a test failure. Will look into
it.
Change-Id: I46441fd3bb0f2c9e372d3e7fd43744ffafaf87a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/397494
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The dwarf.Reader "SeekPC" method was not properly handling the case
of a truncated/empty unit (something that has header information
but an empty abbrev table and no DIEs). Add some guards to handle
this case.
Fixes#52045.
Change-Id: I978163eca3b610f7528058693b840931e90d3f63
Reviewed-on: https://go-review.googlesource.com/c/go/+/397054
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When printing the usage message, recover panics when calling String
methods on reflect-constructed flag.Value zero values. Collect the panic
messages and include them at the end of the PrintDefaults output so that
the programmer knows to fix the panic.
Fixes#28667
Change-Id: Ic4378a5813a2e26f063d5580d678add65ece8f97
Reviewed-on: https://go-review.googlesource.com/c/go/+/396574
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Trust: Andrew Gerrand <adg@golang.org>
The previous code treats some operands such as EQ, LT, etc. as special
registers. However, they are not. This CL adds a new AddrType TYPE_SPOPD
and a new class C_SPOPD to support this kind of special operands, and
refactors the relevant code.
This patch is a copy of CL 260861, contributed by Junchen Li(junchen.li@arm.com).
Co-authored-by: Junchen Li(junchen.li@arm.com)
Change-Id: I57b28da458ee3332f610602632e7eda03af435f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/302849
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently using the SYS instruction will report the "illegal combination"
error. This is because the assembler parser treats the register operand
as p.To, while optab defines it as p.Reg. This CL fixes this bug.
Change-Id: I57799a7c19934b0c62278948f4efaa41001593a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/396796
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Eric Fang <eric.fang@arm.com>
These tests sometimes hang on Windows 10 on ARM64, due to what appears
to be a platform bug. Since we have not yet observed any such hangs on
the windows-arm64-11 builder, I am leaving the tests otherwise enabled
on the theory that the platform bug may have been fixed in Windows 11.
Fixes#52082 (at least for now).
Change-Id: I79161f485b1921f083ebcf01865d6e7b0178ef70
Reviewed-on: https://go-review.googlesource.com/c/go/+/397315
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
“If you have a procedure with ten parameters, you probably missed some.”
― attr. Alan J. Perlis
I argue that the same is true for hard-coded special cases.
In TestGroupCleanupUserNamespace, instead of a curated list of strings
observed in the wild we now check for a prefix, as was done for
TestGroupCleanup in CL 24670.
Updates #16224.
Updates #16303.
Updates #19938.
Updates #34547.
Updates #46752.
Fixes#52088.
Change-Id: I59c5b0c048113e306996c0f8247e09c714d2423a
Reviewed-on: https://go-review.googlesource.com/c/go/+/397316
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current implementation fails to identify that an argument to go work
use is a file when expecting a directory, and panics when attempting to
access it as a directory. This change checks arguments are directories
and generates an error otherwise.
Fixes#51749
Change-Id: If8f69d233409e93fcf391a8774bace74c031c986
Reviewed-on: https://go-review.googlesource.com/c/go/+/393615
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
This fixes two independent problems:
We normally propagate desired registers backwards through opcodes that
are marked resultInArg0. Unfortunately for the desired register
computation, ADDQconst is not marked as resultInArg0. This is because
the amd64 backend can write it out as LEAQ instead if the input and
output registers don't match. For desired register purposes, we want
to treat ADDQconst as resultInArg0, so that we get an ADDQ instead of
a LEAQ if we can.
Desired registers don't currently work for tuple-generating opcodes.
Declare that the desired register applies to the first element of the
tuple, and propagate the desired register back through Select0.
Noticed when fixing #51964
Change-Id: I83346b988882cd58c2d7e7e5b419a2b9a244ab66
Reviewed-on: https://go-review.googlesource.com/c/go/+/396035
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change lifts all non-platform-specific code out of sys* functions
for each platform up into wrappers, and moves documentation about the OS
virtual memory abstraction layer from malloc.go to mem.go, which
contains those wrappers.
Change-Id: Ie803e4447403eaafc508b34b53a1a47d6cee9388
Reviewed-on: https://go-review.googlesource.com/c/go/+/393398
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Currently, the ReadMemStats (really this is all happening in
readmemstats_m, but that's just a direct call from ReadMemStats) call
chain first populates some fields in memstats, then copies those into
the final MemStats location. This used to make a lot of sense when
memstats' structure aligned with MemStats, and the values were just
copied from one to other. Sometime in the last few releases, we switched
to populating the MemStats manually because a lot of fields had diverged
from their internal representation. Now, we're left with a lot of fields
in memstats that pollute the structure: they only exist to be updated
for the sake of ReadMemStats. Since we're going to be adding more fields
to memstats in further CLs, this is a good opportunity to clean up.
As a result of this change, updatememstats, which used to just update
the aforementioned intermediate fields in memstats, is no longer
necessary, so it is removed.
Change-Id: Ifabfb3ac3002641105af62e9509a6351165dcd87
Reviewed-on: https://go-review.googlesource.com/c/go/+/393397
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
When doing external linking on windows, the existing Go linker code
assumed that the external linker defaulted to "--no-dynamicbase" (if
no explicit option was given). This assumption doesn't hold for LLD,
which turns on "--dynamicbase" by default for 64-bit apps. Change the
linker to detect whether a more modern toolchain is in use and to
explicitly pass "--dynamicbase" either way , so as to take the
external linker default out of the equation. This also applies to the
"--high-entropy-va" option as well.
Updates #35006.
Change-Id: I3e12cf6d331c9d003e3d2bd566d45de5710588b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/384156
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Tweak the cgo recipe for the TestCgoHandlesWlORIGIN testpoint to avoid
using "-rpath" on Windows, where it doesn't make sense to use it. This
change needed to avoid an "unknown flag -rpath" from clang/ldd on
windows.
Updates #35006.
Change-Id: I4fcd649df4687aa3aff5690e11a15fc0e0f42332
Reviewed-on: https://go-review.googlesource.com/c/go/+/384155
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Disable the new TestReadCOFFSymbolAuxInfo testpoint on big endian
systems, pending resolution of issue 52079. The newly added interfaces
for reading symbol definition aux info is not working properly when
reading PE objects obj big-endian systems.
Updates #52079.
Change-Id: I8d55c7e4c03fc6444ef06a6a8154cb50596ca58a
Reviewed-on: https://go-review.googlesource.com/c/go/+/397294
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, in most cases the compiler generates a func value
symbol when it is referenced, except when building a shared object
it generates the func value symbol when the function is declared.
The comment says this was necessary because we cannot deduplicate
DUPOK symbols across DSO boundaries. But the dynamic linker is
just fine to resolve symbols with the same name across DSO
boundaries.
Another problem may be that the address of the PLT stub may be
used. When such a func value is deferred, when the runtime needs
to scan its arguments, it cannot look up the PC to find the
function and therefore cannot find its stack map. This is not a
problem now as deferred functions always have no arguments.
Remove the special case for shared linkage.
Change-Id: Id7df0b0ada6d3d7f85741a9ab09581975509516c
Reviewed-on: https://go-review.googlesource.com/c/go/+/396534
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This flag is not supported by clang, so remove it from the cgo cflags
when building for windows. It is clear that it was needed at some
point in the past, but it doesn't appear to be needed at the moment,
since all.bash passes on windows without it now.
Updates #35006.
Change-Id: Ib06c891f516654138e3363e06645cd187e46ce4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/383838
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add some rudimentary support to the PE file loader for handling
sections in COMDAT when reading host object files. This is needed
in order to link programs with support libraries that are of a more
modern vintage than GCC 5.X.
If a given section XYZ is in COMDAT, the symbol for that section will
be flagged, e.g. section 'Characteristics' field will have the
IMAGE_SCN_LNK_COMDAT bit set, and the symbol will be followed by an
"aux" symbol that includes the COMDAT handling strategy that the
linker needs to use.
This patch supports two COMDAT strategies (IMAGE_COMDAT_SELECT_ANY and
IMAGE_COMDAT_SELECT_SAME_SIZE); more work will have to be done in the
future to support other flavors if it turns out that they are needed.
Updates #35006.
Change-Id: I516e825c30ed3df94ba08323b8a24fb847e10c1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/383835
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add hooks to support reading of section definition symbol aux data
(including COMDAT information) from the aux symbols associated with
section definition symbols. The COFF symbol array made available by
"pe.File" includes entries for aux symbols, but doesn't expose their
structure (since it varies depending on the type of aux symbol). This
patch adds a function for returning a specific class of aux symbol
("type 5") that immediately follows a COFF symbol corresponding to a
section definition.
Updates #35006.
Updates #51868.
Change-Id: I21fcc057150f7a3c64f01a5961aabca0fa43399e
Reviewed-on: https://go-review.googlesource.com/c/go/+/394534
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When doing an internal link on Windows, it's possible to see
unresolved references to the symbols "__CTOR_LIST__" and/or
"__DTOR_LIST__" (which are needed in some circumstances). If these are
still unresolved at the point where we're done reading host objects,
then synthesize dummy versions of them.
Updates #35006.
Change-Id: I408bf18499bba05752710cf5a41621123bd84a3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/383836
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The spec says "In a union, a term cannot be a type parameter,...",
but it's really the type in a term that cannot be a type parameter.
(Also, for the spec's purposes, a single term is still a union.)
This CL changes the current error message from:
"cannot use type parameter in typeset"
to one of two messages:
"term cannot be a type parameter" (for term of form P)
"type in term ~P cannot be a type parameter (for term of form ~P)
which are more specific and match the spec more closely.
Fixes#50420.
Change-Id: Id48503efc8416cabc03d5c40d8e64d5b3a7f078e
Reviewed-on: https://go-review.googlesource.com/c/go/+/396874
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For Windows internal linking with CGO, when using more modern
LLVM-based compilers, we may need to read in the object file "crt2.o"
so as to have a definition of "atexit" (for example when linking the
runtime/cgo test), and we also need to allow for the possibility that
a given host archive might have to be looked at more than once. The goal
here is to get all.bash working on Windows when using an up to date
mingw C compiler (including those based on clang + LLD).
This patch also adds a new "hostObject" helper routine, similar to
"hostArchive" but specific to individual object files. There is also a
change to hostArchive to modify the pseudo-package name assigned when
reading archive elements: up until this point, a package name of
"libgcc" was used (even when reading a host archive like
"libmingex.a"), which led to very confusing errors messages if symbols
were missing or there were duplicate definitions.
Updates #35006.
Change-Id: I19c17dea9cfffa9e79030fc23064c7c63a612097
Reviewed-on: https://go-review.googlesource.com/c/go/+/382838
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The existing PE file loader has a special case for the symbol
"__acrt_iob_func", whose hosting object file contains both an actual
definition and also a DLL import symbol "__imp___acrt_iob_func". The
normal way of handling __imp_XXX symbols is for the host object loader
to rename them to their intended target (e.g. "XXX") however if the
target is also defined locally, you get a duplicate definition.
This patch generalizes the def/import symbol detection to apply to all
symbols in the object file being loaded (not just a hard-coded set),
since it will be needed when reading things like crt2.o.
Updates #35006.
Change-Id: I0d0607c27bb7d5f3cb415bc95db816aa13746ba2
Reviewed-on: https://go-review.googlesource.com/c/go/+/382837
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rewrite the helper "readpesym()" and the code that calls it to pass in
most of the values it needs via a state object (the signature was
getting a bit too busy/lengthy). No change in functionality, this is
just a refactor.
Updates #35006.
Change-Id: I6153ee3a9be3eb885694323ae8e07ec4c8eed646
Reviewed-on: https://go-review.googlesource.com/c/go/+/382836
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
After CL 24430, reflect.DeepEqual no longer returns true when comparing
a *Rat built with (*Rat).SetString("0") with one built with
(*Rat).SetInt64(0).
These should be equivalent, but because (*Rat).SetString does not call
norm() when returning the zero value, the result of reflect.DeepEqual
will be false.
One could suggest that developers should use (*Rat).Cmp instead
of relying on reflect.DeepEqual, but if a (*Rat) is part of a
larger struct that is being compared, this can be cumbersome.
This is fixed by calling z.norm() when returning zero in SetString.
Fixes#50944
Change-Id: Ib84ae975bf82fe02d1203aa9668a01960c0fd59d
Reviewed-on: https://go-review.googlesource.com/c/go/+/364434
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
__SIZE_TYPE__ is a GCC type which has been superseded
by size_t -define in stddef.h- since ISO C99.
cmd/cgo already uses size_t in many places, but still generates several
files using __SIZE_TYPES__, most notably the _cgo_export.h.
This change replaces all __SIZE_TYPES__ occurrences with size_t.
Updates #36233
Change-Id: Id8a99b5d7763caab9333eab9b585e78249a37415
Reviewed-on: https://go-review.googlesource.com/c/go/+/379474
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
If a package could not be imported for whatever reason, the type checker
creates fake package with which it continues for more tolerant type
checking.
Do not report an "imported but not used" error in that case.
Clarify a few comments along the way.
Fixes#43109.
Change-Id: Ifeec0daa688fbf666412dc9176ff1522d02a23ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/396875
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For syntax errors in various (syntactic) lists, instead of reporting
a set of "expected" tokens (which may be incomplete), provide context
and mention "possibly missing" tokens. The result is a friendlier and
more accurate error message.
Fixes#49205.
Change-Id: I38ae7bf62febfe790075e62deb33ec8c17d64476
Reviewed-on: https://go-review.googlesource.com/c/go/+/396914
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(Also rename it to no longer describe itself in terms of sleeping.)
This test previously relied on the scheduler to wake up a goroutine to
write the "--- PASS: TestFast" line within 100ms of TestFast actually
finishing. On some platforms, even that long a delay is apparently too
short.
Instead, we now use a deterministic "=== RUN" line instead of a
timing-dependent "--- PASS" line to interrupt the output.
Fixes#51221
Change-Id: I3997640fb7577e29e3866a82d4d49a3a70a4b033
Reviewed-on: https://go-review.googlesource.com/c/go/+/386154
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
findgoversion has some logic from before the go1 release that only
has effect when on a release branch without a VERSION file.
Starting with release-branch.go1 and the go1 tag a decade ago,
release branch have always had a VERSION file checked in.
(The commit that adds/updates the VERSION file is what is tagged.)
Since we have no need to support old branches like release-branch.r60,
and such scenarios don't come up in modern Go, delete it to simplify
this code a bit. Should the VERSION file situation change, we'd need
to rework this code anyway.
Fixes#42345.
Change-Id: I13f27babd37aaa5cec30fefde1b8e6ccce816461
Reviewed-on: https://go-review.googlesource.com/c/go/+/393954
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When parsing method declarations in an interface, the parser has
for historic reasons gracefully handled a list of method names with
a single (common) signature, and then reported an error. For example
interface {
m1, m2, m3 (x int)
}
This code originally came from the very first parser for Go which
initially permitted such declarations (or at least assumed that
people would write such declarations). Nobody is doing this at this
point, so there's no need for being extra careful here. Remove the
respective code and adjust the corresponding test.
Change-Id: If6f9b398bbc9e425dcd4328a80d8bf77c37fe8b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/396654
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Generics have landed; we cannot revert the syntax anymore. Remove
ability to choose between non-generic and generic code. Also remove
mode to enable method type parameters. Adjust code accordingly.
Also remove a couple of TODOs that are not relevant anymore.
Remove tests from types2 which were focussed on method type parameters,
make types2 and go/types tests match up where there was a difference in
this regard.
Change-Id: I989bdcb19eea7414214af739187fa013a044295d
Reviewed-on: https://go-review.googlesource.com/c/go/+/396634
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- Use .go suffix for test files as go fmt doesn't descend into testdata
directories.
- Move test files from testdata/go2 into testdata directory.
- Delete some test files that contained type-checker ERROR markers that
were ignored by the TestParseGo2 test but would be considered by the
TestSyntaxErrors test if the files were moved unchanged into the
testdata directory.
- Remove one (type checker) ERROR marker in testdata/slices.go to make
it pass the syntax error tests.
- Delete TestParseGo2 test. There's enough coverage with the existing
TestSyntaxErrors test.
- Add missing copyright notice to testdata/chans.go and gofmt the file.
Change-Id: I449913fe1bd2119987ba33f7152e5e4ba5f3fe31
Reviewed-on: https://go-review.googlesource.com/c/go/+/396518
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When using Go 1.4 this doesn't matter, but when using Go 1.17,
the bootstrap toolchain will complain about unknown GOEXPERIMENT settings.
Clearly GOEXPERIMENT is for the toolchain being built, not the bootstrap.
For #51940.
Change-Id: Iff77204391a5a66f7eecab1c7036ebe77e1a4e82
Reviewed-on: https://go-review.googlesource.com/c/go/+/395879
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The 'docker' command line tool is no longer available on my Linux laptop
due to Docker's new licensing rules. 'sudo podman' seems to work fine,
so suggest that instead.
Change-Id: Ib80211404dadb567c8741720ece2a73a6ad4040a
Reviewed-on: https://go-review.googlesource.com/c/go/+/395874
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 367755 added soleComponent for handling 1-byte type interface conversion.
This implementation must be kept in sync with Type.SoleComponent, but it
does not. When seeing a blank field in struct, we must continue looking
at the field type to find sole component, if any. The current code just
terminate immediately, which causes wrong sole component type returned.
Fixes#52020
Change-Id: I4f506fe094fa7c5532de23467a4f9139476bb0a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/396614
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There are several of places that save and restore the C callee-saved registers,
the operation is the same everywhere, so this CL defines several macros
to do this, which will help reduce code redundancy and unify the operation.
This CL also replaced consecutive MOVD instructions with STP and LDP instructions
in several places where these macros do not apply.
Change-Id: I815f39fe484a9ab9b6bd157dfcbc8ad99c1420fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/374397
Trust: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL adds
- spill functions used by runtime
- ABIInternal to functions
Adding new stubs_riscv64 file to eliminate vet issues while compiling.
Change-Id: I2a9f6088a1cd2d9708f26b2d97895b4e5f9f87e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/360296
Trust: mzh <mzh@golangcn.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Use the 1.17 compiler error message together with the receiver base type.
Also, simplify and flatten the receive testing logic for clarity.
Change-Id: I71e58f261900dd7a85d2eb89a310c36b68d1b0b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/396298
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
These are the opcodes required to lower math/bits.Add64 and
math/bits.Sub64 directly into ssa form. Likewise, opcodes which
clobber CA are marked.
This does not alter code generation. It prepares for future changes
to support scheduling carry chaining ops more effectively, and then
changes to lower into PPC64 opcodes.
Change-Id: I2723deee4a98b3c365f691857512df53280ae40f
Reviewed-on: https://go-review.googlesource.com/c/go/+/394594
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If a GC related task preempts between hitting the main.main breakpoint
and stepping, the test program may halt forever waiting on a GC
operation. This happens if gdb is configured to halt other threads
while executing a step.
Configure gdb to continue running all threads during a step by
setting the scheduler-locking option to off.
Fixes#49852
Change-Id: Iacc9732cbd23526bde0a295e6fa8a0d90f733f59
Reviewed-on: https://go-review.googlesource.com/c/go/+/370775
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Cherry Mui <cherryyz@google.com>
This is the first step towards decomposing aggregate operations
which create or consume the CA bit of the XER.
This helps optimize the canned sequence of Add64Carry (and
Sub64Borrow if it were implemented similarly) by minimizing
extraneous operations related to loading the CA bit,
reloading CA in chained operations, or extracting it when
unused.
Likewise, mark the operations which clobber CA.
Change-Id: I33e6dd2654a8cc39fcdbb9690a495f03558cdc97
Reviewed-on: https://go-review.googlesource.com/c/go/+/346869
Trust: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
net.ParseCIDR already rejects input in the form of 2001:db8::%a/32, but
netip.ParsePrefix previously accepted the input and silently dropped the
zone. Make the two consistent by always returning an error if an IPv6
zone is present in CIDR input for ParsePrefix.
Fixes#51899.
Change-Id: Iee7d8d4a5161e0b54a4ee1bd68b02c1a287ff399
Reviewed-on: https://go-review.googlesource.com/c/go/+/396299
Trust: Matt Layher <mdlayher@gmail.com>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Damien Neil <dneil@google.com>
This updates the cmd/compile/internal/importer to natively support the
"final" unified IR export format. This is really just for unit tests
and symmetry with go/internal/gcimporter though, since
cmd/compile/internal/noder has its own types2.Importer.
Change-Id: I52fbb6134dbc0a903d62c1b04f95d33bd29e0414
Reviewed-on: https://go-review.googlesource.com/c/go/+/388617
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
So far unified IR has been relying on the backwards-compat iexport
data to supply package fingerprints for imports. To be able to drop
the iexport data and natively use unified IR everywhere.
This CL applies basically the same idea that iexport used: simply
hash all of the export data as it's being written out, and then tack
on an 8-byte hash at the end.
Change-Id: Iaca5fbfd7443088bc7f422a1c58be3e762c29014
Reviewed-on: https://go-review.googlesource.com/c/go/+/396196
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
At least on some platforms (e.g. PE dynamic loader) relocations
need to be sorted in address order. Currently we don't always emit
relocations in address order: e.g. for array literal with out-of-
order element initializers, or out-of-order DATA instructions in
assembly code. Sort them.
No test for now as I can't reproduce the failure for #51923.
Fixes#51923.
Change-Id: Ifec5d3476e027bb927bcefd6e45c40ebeccee4ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/396195
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
We are limited to 64 registers in the allocator today, and PPC64
has not been allocating F0,F26-F31 for quite some time without
performance impact.
Change-Id: If9d60be5037c94991fdd90a44461c3a6b96315cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/395835
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
These FP registers on PPC64 have no restrictions, they can
be used like the others. F27-F31 were sequested long ago for
scratch storage which has long since been reverted, but they
weren't added back to the allocator pool.
Change-Id: I9074660e2fc91a2044c9768f700a8215802cba51
Reviewed-on: https://go-review.googlesource.com/c/go/+/395834
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Use bytealg.IndexByteString(str, 0) instead of looping through the
string to check for a zero byte. A quick and dirty benchmark shows 10x
performance improvement (on amd64 machine, using go 1.17.3).
BytePtrFromString is used by many functions with string arguments.
This change should make many functions in os package, such as those
accepting a filename (os.Open, os.Stat, etc.), a tad faster.
PS I am aware that syscall package is deprecated and frozen, but this
change is mainly for the os package and the likes. The alternative
would be for os to switch to x/sys, which is a much bigger change.
Change-Id: I18fdd50f9fbfe0a23a4a71bc4bd0a5f5b0eaa475
Reviewed-on: https://go-review.googlesource.com/c/go/+/368457
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 390474 removed last usages of ConstValue, it can now be removed, and
also Float64Val, since when it's only used by ConstValue.
CanInt64 is un-used for a long time, its original form last usage was
removed in CL 221802.
Change-Id: Id142b0da49c319faca73ef1b2090325f81431321
Reviewed-on: https://go-review.googlesource.com/c/go/+/396078
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The existing implementation of the xml decoder uses the line number
only for reporting syntax errors. The line number of the last read
token and the column within the line is useful for the users even
in non-error conditions.
Fixes#45628
Change-Id: I37b5033ff5ff8411793d8f5180f96aa4537e83f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/311270
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
When we have x.M(args) where x is a value of type parameter type, we
currently cast x to the bound of that type parameter (which is an interface)
and then invoke the method on that interface. That's pretty inefficient
because:
1) We need to convert x to an interface, which often requires allocation.
With CL 378178 it is at least stack allocation, but allocation nontheless.
2) We need to call through wrapper functions to unpack the interface
into the right argument locations for the callee.
Instead, let's just call the target directly. The previous CL to this one
added method expression closures to the dictionary, which is a simple
captureless closure that implements T.M for type parameter T and method M.
So to implement x.M(args) for x of type T, we use methodexpr(T,M)(x, args).
We just need to move x from the receiver slot to the first argument, and
use the dictionary entry to implement the polymorphism. This works because
we stencil by shape, so we know how to marshal x for the call even though
we don't know its exact type.
We should be able to revert CL 378178 after this one, as that optimization
will no longer be necssary as we're not converting values to interfaces
to implement this language construct anymore.
Update #50182
Change-Id: I813de4510e41ab63626e58bd1167f9ae93016202
Reviewed-on: https://go-review.googlesource.com/c/go/+/385274
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently we do quite a dance for method expressions on generic
types. We write a new closure, and in that closure convert the
receiver to an interface with the required method, then call the
target using an interface call.
Instead in this CL, we just allocate a (captureless) closure in the
dictionary which implements that method expression.
This CL makes method expressions faster and simpler. But the real win
is some followon CLs, where we can use the same closure to implement
bound method calls using the same closure, instead of converting to
interface and having wrappers convert back. Much faster and simpler.
Still thinking about how to do method values. The receiver still
needs to be captured, so there must be some closure involved, I think.
Update #50182
Change-Id: I1fbd57e7105663f8b049955b8f4111649a5f4aa8
Reviewed-on: https://go-review.googlesource.com/c/go/+/385254
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Historically, we sometimes recorded imports based on either package
path ("net/http") or object file path ("net/http.a"). But modern Go
build systems always use package path, and the extra ".a" suffix
doesn't mean anything anyway.
Change-Id: I6060ef8bafa324168710d152a353f4d8db062133
Reviewed-on: https://go-review.googlesource.com/c/go/+/395254
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The correct (or at least mostly commonly used) name for addresses of the
form ::ffff:192.0.2.128 is "IPv4-mapped IPv6". Some of the comments in
the netip package used that name, but others used "IPv6-mapped IPv4" or
"v6-mapped". This change makes the usage of the term consistent.
Change-Id: Ic01309ddf9252705a2387322d940b777e88800a5
GitHub-Last-Rev: 56044dcb97
GitHub-Pull-Request: golang/go#51950
Reviewed-on: https://go-review.googlesource.com/c/go/+/395914
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
The detection of the "unknown charset" case was too tailored
to one specific address parser. Make it generalize, so that custom
address parsers behave the same way as the default one
for character sets they do not handle.
Fixes#41625.
Change-Id: I347d4bb6844d0a1f23e908b776d21e8be5af3874
Reviewed-on: https://go-review.googlesource.com/c/go/+/283632
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
For 1-byte type, we have a special case for converting to interface
type. But we missed an optimization for sole component-ed types, this CL
add that one.
goos: linux
goarch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
Benchmark_BoolField-8 1000000000 0.6473 ns/op
Benchmark_ByteField-8 1000000000 0.6094 ns/op
Benchmark_Uint8Field-8 1000000000 0.6385 ns/op
Benchmark_Int16Field-8 785179434 1.481 ns/op
Benchmark_Int32Field-8 796127782 1.539 ns/op
Benchmark_Int64Field-8 718815478 1.657 ns/op
Fixes#49879
Change-Id: Idc0e9d3ff738c8c8081b8e8d65093dacf2bcf392
Reviewed-on: https://go-review.googlesource.com/c/go/+/367755
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If the http.Request passed to ReverseProxy.ServeHTTP has a context
with a non-nil Done channel, don't watch the ResponseWriter's
CloseNotify channel.
Avoids starting an extra background goroutine in the common case.
Change-Id: I1328f3e02d3025caa0f446a2f20dfc14ef604c64
Reviewed-on: https://go-review.googlesource.com/c/go/+/376415
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Damien Neil <dneil@google.com>
This CL updates test/run.go to compile xxx.dir/x.go with a package
path of "test/x" instead of just "x". This prevents collisions with
standard library packages.
It also requires updating a handful of tests to account for the
updated package paths.
Fixes#25693.
Change-Id: I49208c56ab3cb229ed667d547cd6e004d2175fcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/395258
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
I was testing edge cases in gofumpt, a fork of gofmt,
and noticed that gofmt will return a bare io error on empty files,
as demonstrated by the added test case without a fix:
> ! exec $GOROOT/bin/gofmt empty.go nopackage.go
[stderr]
EOF
nopackage.go:1:1: expected 'package', found not
The problem is the code that detects concurrent modifications.
It relies on ReadFull and correctly deals with io.ErrUnexpectedEOF,
but it did not pay attention to io.EOF, which can happen when size==0.
Change-Id: I6092391721edad4584fb5922d3e3a8fb3da86493
Reviewed-on: https://go-review.googlesource.com/c/go/+/393757
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
The file names reported in error messages by the compiler are
printed unchanged from the file names provided to the compiler;
the -L flag has no impact on the file names themselves, contrary
to what the old flag description suggested.
If an error is reported on a line that is affected by a //line
directive, an error message reports the file name and line as
controlled by the directive (i.e., the actual source position
is not known).
If the -L flag is provided, the actual source position is also
reported in square brackets.
This change documents this with an updated help string for the
flag.
For #36988.
Change-Id: I39ee35e6ff6cd5cfa44d87dabb05b8d78575d631
Reviewed-on: https://go-review.googlesource.com/c/go/+/395115
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
bug302 compiles p.go with -p=p, and then manually creates a pp.a
archive, and imports it as both "p" and "pp". This is a misuse of
cmd/compile's -p flag, and it isn't representative of how any actual
Go build systems work anyway.
This test made sense back when cmd/compile still wrote out bare object
files, which was then split into separate __.PKGDEF and _go_.o archive
entries when added to a pack archive. But since CL 102236, cmd/compile
always writes out pack files.
Updates #51734.
Change-Id: I4b5de22d348ecc0a72c98b512351c2d267c77736
Reviewed-on: https://go-review.googlesource.com/c/go/+/393896
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, run.go's *dir tests allow "x.go" to be imported
interchangeably as either "x" or "./x". This is generally fine, but
can cause problems when "x" is the name of a standard library
package (e.g., "fixedbugs/bug345.dir/io.go").
This CL is an automated rewrite to change all `import "x"` directives
to use `import "./x"` instead. It has no effect today, but will allow
subsequent CLs to update test/run.go to resolve "./x" to "test/x" to
avoid stdlib collisions.
Change-Id: Ic76cd7140e83b47e764f8a499e59936be2b3c876
Reviewed-on: https://go-review.googlesource.com/c/go/+/395116
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The code iterates through the func table to find a function with
a given file and line number. The code panics if it sees a non-
real function (e.g. go.buildid), because its CU offset is -1,
which causes an index-out-of-bounds error. The debug/gosym package
recovers the panic and returns "not found", without looping
through the rest of the entries.
Skip the non-real functions. They cannot be looked up by line
number anyway.
Fixes#51890.
Change-Id: I96f64c17b4a53ffdce047c8244b35a402a0d39ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/395074
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
For a non-generic defined type, we generate its type descriptor
symbol only in the defining package. So there is no duplicate and
it doesn't need to be dupok.
For unnamed types and instantiated types, the type descriptor can
be generated in multiple packages and so still need to be dupok.
Change-Id: I92ed68c998ad68c5917b77b1dfd62eac4ced6bcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/394636
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
With the previous CL the compiler emits an unlinkable object if
the -p flag is not specified. It is actually okay (and convenient)
to omit the -p flag for (just) the main package. This CL makes it
so.
Change-Id: I978d54d14c45b3bb9ed7471e40a2c47f269b56f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/394834
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The importer type param index used package name type parameter key,
causing type parameters to be reused/overwritten if two packages in the
import graph had the same combination of (name, declaration name, type
parameter name).
Fix this by instead using the *Package in the key.
Fixes#51836
Change-Id: I881ceaf3cf7c1ab4e0835962350feb552e79b233
Reviewed-on: https://go-review.googlesource.com/c/go/+/394219
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Restructure TestCPUProfileMultithreadMagnitude so it will run again with
a longer duration on failure. Log the split between the user vs system
CPU time that rusage reports.
For #50232
Change-Id: Ice5b38ee7594dbee1eaa5686d32b968c306e3e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/393934
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
For unlinkable object the link will fail, but it opens the output
file in writable mode first then delete it on failure. This fails
if the current directory is not writable. Write to the temporary
directory instead.
Change-Id: Iefd73b5cc8efdc0f11b12edc0920169a8ad3f37c
Reviewed-on: https://go-review.googlesource.com/c/go/+/394755
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The glibc loader explicitly sets the first doubleword on the stack (R1)
to $0 to indicate it was dynamically loaded.
An ELFv2 ABI compliant loader will set R3/R4 to argc/argv when starting
the process, and R13 to TLS. musl is not compliant. Instead it passes
argc/argv like the kernel, but R3/R4 are in an undefined state and R13
is valid.
With the knowledge above, the startup code can be modified to
dynamically handle all three cases when linked internally.
Fixes#51787
Change-Id: I5de33862c161900d9161817388bbc13a65fdc69c
Reviewed-on: https://go-review.googlesource.com/c/go/+/394654
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Paul Murphy <murp@ibm.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Symbol's content hash used to depend on package path expansion in
symbol names, so we have special logic handling hashed symbols
when path expansion is needed. As we required -p in the compiler
the symbol names are now fully expanded. Remove that logic.
Change-Id: I888574f63ea3789455d96468a6abd500e0958230
Reviewed-on: https://go-review.googlesource.com/c/go/+/394218
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 391014 requires the compiler to be invoked with the -p flag, to
specify the package path. People are used to run "go tool compile"
from the command line with the -p flag. This is mostly for simple
testing, or debugging the compiler. The produced object file is
almost never intended to be linked.
This CL makes the compiler allow "go tool compile" without the -p
flag again. It will produce an unlinkable object. If the linker
sees such an object it will error out.
Change-Id: I7bdb162c3cad61dadd5c456d903b92493a3df20f
Reviewed-on: https://go-review.googlesource.com/c/go/+/394217
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
First law of cmd/compile frontend development: thou shalt not rely on
types.Sym.
This CL replaces Type.OrigSym with Type.OrigType, which semantically
matches what all of the uses within the frontend actually care about,
and avoids using types.Sym, which invariably leads to mistakes because
symbol scoping in the frontend doesn't work how anyone intuitively
expects it to.
Fixes#51765.
Change-Id: I4affe6ee0718103ce5006ab68aa7e1bb0cac6881
Reviewed-on: https://go-review.googlesource.com/c/go/+/394274
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The type checker implements additional built-in functions (assert
and trace) that are useful for debugging. Only permit them in
manual tests (go test -run Manual), not for other tests where they
are not needed.
Change-Id: Idc7723d9e3f6b2c27769b34743561e9d0339565c
Reviewed-on: https://go-review.googlesource.com/c/go/+/393659
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Also, manually renamed some irregularly numbered files to
make their file names more regular.
With this rename, all test files now end uniformly in .go.
go fmt doesn't descend into testdata directories, so this
is fine and makes all test files behave like regular .go
files in editors with Go language support.
Change-Id: I3abde32c35c494b94b17787788cd3d7e35662296
Reviewed-on: https://go-review.googlesource.com/c/go/+/393658
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
With all the unification/type-inference fixes in place now, we
should not see stack overflows anymore. Re-enable the panic if
we do overflow, so we can address those issues should they arise.
Fixes#51377.
Change-Id: Ied64435ea5936811504cb30bda1126c7d85980f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/392755
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
These fields were used for tracking the last scope/position that an
identifier was declared, so that we could report redeclaration
errors. However, redeclaration errors are now diagnosed by types2 (and
typecheck.Redeclared was removed in CL 388537), so these fields can be
safely pruned.
Updates #51691.
Change-Id: Ifd5ea3f6795fadb420913298d59287c95e4669a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/394276
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When developing register ABI, for early testing the compiler
recognized a few magic names to trigger enabling register ABI.
After the development it is disabled (changed to a name that
cannot be spelled in the source code). Later in the development of
register ABI for ARM64 and PPC64, I don't think the magic names
were used. I think they can now be removed.
Keep the magic pragma for now in case it helps development.
Change-Id: Icbc34e2786a80fd8fffe4a464c569dc03a54cd09
Reviewed-on: https://go-review.googlesource.com/c/go/+/393877
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The -trimpath flag has a strong effect on the resulting binary:
in particular, it determines whether runtime.GOROOT can report
a meaningful path in the absence of an explicit GOROOT environment variable.
For #51461
Change-Id: Id0d55572c0a0a4e2e4724363ed80dfa05b202186
Reviewed-on: https://go-review.googlesource.com/c/go/+/391810
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also update cmd/dist to avoid setting gcflags and ldflags explicitly
when the set of flags to be set is empty (a verbose way of specifying
the default behavior).
Stamping was disabled for the Go standard library in CL 356014 due to
the cmd/dist flags causing cmd/go to (correctly) report the resulting
binaries as stale.
With cmd/dist fixed, we can also remove the special case in cmd/go,
which will allow tests of binaries in 'cmd' to read the build info
embedded in the test binary. That build info may be useful to
determine (say) whether runtime.GOROOT ought to work without GOROOT
set in the environment.
For #51483
Updates #37475
Change-Id: I64d04f5990190094eb6c0522db829d3bdfa50ef3
Reviewed-on: https://go-review.googlesource.com/c/go/+/391809
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously, runtime.GOROOT() would return the string "go" in a binary
build with -trimpath. This change stamps the empty string instead,
using a sentinel value passed from cmd/go that looks like the GOROOT
environment variable (either "$GOROOT" or "%GOROOT%", depending on the
platform).
Fixes#51461
Change-Id: I1f10ef2435016a7b6213bd8c547df911f7feeae7
Reviewed-on: https://go-review.googlesource.com/c/go/+/390024
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the beginning the Go compiler was in C, and C had a function
'getgoroot' that returned GOROOT from either the environment or a
generated constant. 'getgoroot' was mechanically converted to Go
(as obj.Getgoroot) in CL 3046.
obj.Getgoroot begat obj.GOROOT. obj.GOROOT begat objabi.GOROOT,
which begat buildcfg.GOROOT.
As far as I can tell, today's buildcfg.GOROOT is functionally
identical to runtime.GOROOT(). Let's reduce some complexity by
defining it in those terms.
While we're thinking about buildcfg.GOROOT, also check whether it is
non-empty: if the toolchain is built with -trimpath, the value of
GOROOT might not be valid or meaningful if the user invokes
cmd/compile or cmd/link directly, or via a build tool other than
cmd/go that doesn't care as much about GOROOT. (As of CL 390024,
runtime.GOROOT will return the empty string instead of a bogus one
when built with -trimpath.)
For #51461.
Change-Id: I9fec020d5fa65d4aff0dd39b805f5ca93f86c36e
Reviewed-on: https://go-review.googlesource.com/c/go/+/393155
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Invoking a VCS tool requires that the VCS tool be installed, and also
adds latency to build commands. Unfortunately, we had been mistakenly
loading VCS metadata for tests of "main" packages.
Users almost never care about versioning for test binaries, because
'go test' runs the test in the source tree and test binaries are only
rarely used outside of 'go test'. So the user already knows exactly
which version the test is built against, because the source code is
right there — it's not worth the overhead to stamp.
Fixes#51723.
Change-Id: I96f191c5a765f5183e5e10b6dfb75a0381c99814
Reviewed-on: https://go-review.googlesource.com/c/go/+/393894
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
When the test binary is built with the -trimpath flag,
runtime.GOROOT() is invalid, and must not be used to locate
GOROOT/lib/time/zoneinfo.zip. (We can use other sources instead.)
However, the test for the package expects zoneinfo.zip to definitely
exist. 'go test' runs the test binary in the directory containing its
source code — in this case GOROOT/src/time — so we can use that
information to find the zoneinfo.zip file when runtime.GOROOT isn't
available.
For #51483
Change-Id: I9de35252a988d146b5d746794323214d400e64e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/391814
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
They should not share a shape with regular pointers. We could coalesce
multiple pointer-to-not-in-heap types, but doesn't seem worth it - just
make them fully stenciled.
Fixes#51733
Change-Id: Ie8158177226fbc46a798e71c51897a82f15153df
Reviewed-on: https://go-review.googlesource.com/c/go/+/393895
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is an in-process (non-exec'ing) replacement for cmd/internal/diff.
It uses an O(n log n) algorithm instead of the O(n²) algorithm
in standard diff binaries. It does not produce the absolute
shortest diffs, but the results are often more meaningful
than the standard diff, because it doesn't try to align
random blank lines or other noise.
Adding so that tests inside std (especially go/printer)
can print diffs.
Replacing cmd/internal/diff because we don't need two.
Change-Id: I9155dd925e4a813f5bfa84a8ad3dec8ffdbf8550
Reviewed-on: https://go-review.googlesource.com/c/go/+/384255
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
Trust: Peter Weinberger <pjw@google.com>
In last cycle we developed register ABI for ARM64, enabled by
default as a GOEXPERIMENT. This cycle we turn it on all the time.
Later CLs will clean up fallback code.
To support in-development platforms (e.g. RISC-V), separate the
boolean variables for in-development platforms and always-on
platforms.
Change-Id: I97c27f6aeccc85ccc57eed2abd783b176da3ad80
Reviewed-on: https://go-review.googlesource.com/c/go/+/393364
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
cmd/go/internal/cfg duplicates many of the fields of
internal/buildcfg, but initializes them from a Go environment file in
addition to the usual process environment.
internal/buildcfg doesn't (and shouldn't) know or care about that
environment file, but prior to this CL it exposed hooks for
cmd/go/internal/cfg to write data back to internal/buildcfg to
incorporate information from the file. It also produced quirky
GOEXPERIMENT strings when a non-trivial default was overridden,
seemingly so that 'go env' would produce those same quirky strings in
edge-cases where they are needed.
This change reverses that information flow: internal/buildcfg now
exports a structured type with methods — instead of top-level
functions communicating through global state — so that cmd/go can
utilize its marshaling and unmarshaling functionality without also
needing to write results back into buildcfg package state.
The quirks specific to 'go env' have been eliminated by distinguishing
between the raw GOEXPERIMENT value set by the user (which is what we
should report from 'go env') and the cleaned, canonical equivalent
(which is what we should use in the build cache key).
For #51461.
Change-Id: I4ef5b7c58b1fb3468497649a6d2fb6c19aa06c70
Reviewed-on: https://go-review.googlesource.com/c/go/+/393574
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
With the previous CL, internal/abi.IntArgRegs and FloatArgRegs
is controlled by RegabiArgs (or always enabled), so there is no
need to check for that goexperiment.
There are a few places we guard register-ABI specific code and
tests with the RegabiArgs flag. Switch to checking for the number
of argument registers instead.
Change-Id: I79fff9fd1e919684ffaf73aba9e7e85d5a9e1629
Reviewed-on: https://go-review.googlesource.com/c/go/+/393363
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
regabireflect goexperiment was helpful in the register ABI
development, to control code paths for reflect calls, before the
compiler can generate register ABI everywhere. It is not necessary
for now. Drop it.
Change-Id: I2731197d2f496e29616c426a01045c9b685946a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/393362
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
pthread_attr_init on freebsd properly initializes the pthread_attr,
there is no need to zero it before the call. The comment and code were
probably copied from the linux/arm implementation.
This aligns the implementation on freebsd/arm with the implementation on
other freebsd architectures.
Fixes#44248
Change-Id: If82ebb115b877b6c6f4862018a9419ba8d870f12
Reviewed-on: https://go-review.googlesource.com/c/go/+/393617
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
Trust: Hajime Hoshi <hajimehoshi@gmail.com>
When ASan is enabled, treat conversions to unsafe.Pointer as
an escaping operation. In this way, all pointer operations on
the stack objects will become operations on the escaped heap
objects. As we've already supported ASan detection of error
memory accesses to heap objects. With this trick, we can use
-asan option to report errors on bad stack operations.
Add test cases.
Updates #44853.
Change-Id: I6281e77f6ba581d7008d610f0b24316078b6e746
Reviewed-on: https://go-review.googlesource.com/c/go/+/393315
Trust: Fannie Zhang <Fannie.Zhang@arm.com>
Run-TryBot: Fannie Zhang <Fannie.Zhang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eric Fang <eric.fang@arm.com>
IsIdentRune may be installed by a client of the scanner. If the
installed function accepts EOF as a valid identifier rune, Scan
calls may not terminate.
Check for EOF when a user-defined IsIdentRune is used.
Fixes#50909.
Change-Id: Ib104b03ee59e2d58faa71f227c3b51ba424f7f61
Reviewed-on: https://go-review.googlesource.com/c/go/+/393254
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some systems set an artificially low soft limit on open file count,
for compatibility with code that uses select and its hard-coded
maximum file descriptor (limited by the size of fd_set).
Go does not use select, so it should not be subject to these limits.
On some systems the limit is 256, which is very easy to run into, even
in simple programs like gofmt when they parallelize walking a file tree.
After a long discussion on go.dev/issue/46279, we decided the best
approach was for Go to raise the limit unconditionally for itself, and
then leave old software to set the limit back as needed. Code that
really wants Go to leave the limit alone can set the hard limit, which
Go of course has no choice but to respect.
Take 2, after CL 392415 was rolled back for macOS and OpenBSD failures.
The macOS failures should be handled by the new call to sysctl("kern.maxfilesperproc"),
and the OpenBSD failures are handled by skipping the test (and filing #51713).
Fixes#46279.
Change-Id: I45c81b94590b447b483018a05ae980b8f02dc5de
Reviewed-on: https://go-review.googlesource.com/c/go/+/393354
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 376356 changes syscall.Syscall to call ABIInternal entersyscall
and exitsyscall. As mentioned in the CL description, it is
important to call entersyscall without ABI wrapper, but it is not
important to call exitsyscall this way. In fact, it is actually
problematic -- on Plan 9, syscall may clobber our fixed G register,
and we did not restore it. This CL changes it back to ABI0
exitsyscall, which will restore the G register through the wrapper.
Should fix Plan 9/AMD64 build.
Change-Id: I1f03d553f03e7b9f36d64686f20f2b2df0a0bf79
Reviewed-on: https://go-review.googlesource.com/c/go/+/393494
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When plugin is used, we already mark all exported methods
reachable. However, when the plugin and the host program share
a common package, an unexported method could also be reachable
from both the plugin and the host via interfaces. We need to mark
them as well.
Fixes#51621.
Change-Id: I1a70d3f96b66b803f2d0ab14d00ed0df276ea500
Reviewed-on: https://go-review.googlesource.com/c/go/+/393365
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
typecheckdef used to be used to handle references to package-level
declarations that hadn't yet been typechecked yet. It's no longer
needed, as the current IR frontends construct package-level
declarations with proper types upfront.
Exception: this code is still used for compiler-generated function
declarations, so that code needs to be kept. Eventually that code can
be moved elsewhere, but for now this CL makes it obvious that the rest
of the code paths really are unused.
Updates #51691.
Change-Id: I5322edb686aaf5dc4627288f3d9ba910a017b41d
Reviewed-on: https://go-review.googlesource.com/c/go/+/393256
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
OIOTA used to be used to represent "iota" in the pre-typechecked IR,
before we knew whether it was safe to replace it with a constant
(because it could be redefined as a global symbol later).
However, now types2 handles constant folding, including handling of
"iota". So this can go away.
Updates #51691.
Change-Id: I3cec45b22c4c8f1c357dcc4003292c21ae32aa90
Reviewed-on: https://go-review.googlesource.com/c/go/+/393255
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Type.Broke and Node.Diag were used in the legacy typechecker to allow
reporting of multiple errors in a compilation unit, while suppressing
unhelpful follow-on errors. However, that's no longer needed now that
types2 handles (most) user-visible diagnostics.
Updates #51691.
Change-Id: I919c1598d8acebe5703939256bdca3e8d021f7ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/392918
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Unified IR currently relies on typecheck to diagnose invalid
//go:notinheap conversions, which prevents removing all of
its (otherwise) dead error-reporting code.
This CL updates the unified IR reader to instead proactively diagnose
these invalid conversions. This logic can be removed again once #46731
is implemented, but in the mean time it allows progress on #51691.
Updates #46731.
Updates #51691.
Change-Id: Ifae81aaad770209ec7a67bc10b55660f291e403e
Reviewed-on: https://go-review.googlesource.com/c/go/+/392917
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
We have no guarantee in general that there is any 'go' command in
$PATH at all, let alone the correct one. However, we can expect that
if a 'go' command is not in scope, the Importer should have a correct
GOROOT setting: otherwise, it would not be able to import anything
from 'std' at all.
Given that information, when we run `go tool cgo` we should use
GOROOT/bin/go specifically, not whatever 'go' we find in $PATH.
This fixes a failure in go/types.TestStdlib that manifests as a
timeout in when the 'go' command is not present in $PATH, due to
repeated retries for every package that transitively depends on
runtime/cgo.
For #51461
Change-Id: I30cc4613f6f02a04e83c8d55657ef01888c7770f
Reviewed-on: https://go-review.googlesource.com/c/go/+/391807
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This used to be cmd/go/internal/txtar,
and then it was moved to golang.org/x/tools/txtar
and revendored from there into cmd/vendor/golang.org/x/tools/txtar.
We have a use for txtar in a new test in the standard library,
which cannot access cmd/vendor. But we also don't really want
to vendor it into the standard library as is, because that would
be the first vendoring of x/tools in std, and it would be better
to keep std separate from x/tools, even for testing.
Instead, since a little copying is better than a little dependency,
just make a copy in internal/txtar. The package does not change.
Having done that, replace the uses in cmd/go so that there's
only one copy in the main repo.
Change-Id: I70b5cc05da3f6ebcc0fd9052ebcb3d369fb57956
Reviewed-on: https://go-review.googlesource.com/c/go/+/384254
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, when register ABI is used, syscall.Syscall calls
entersyscall via a wrapper, so the actual entersyscall records the
caller PC and SP of the wrapper. At the point of the actual
syscall, the wrapper frame is gone, so the recorded PC and SP are
technically invalid. Furthermore, in some functions on some
platforms (e.g. Syscall9 on NetBSD/AMD64), that frame is
overwritten. If we unwind the stack from the recorded syscallpc
and syscallsp, it may go wrong. Fix this by calling the
ABIInternal function directly.
exitsyscall calls are changed as well. It doesn't really matter,
just changed for consistency.
Change-Id: Iead8dd22cf32b05e382414fef664b7c4c1719b7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/376356
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When ASan is enabled, treat conversions to unsafe.Pointer as
an escaping operation. In this way, all pointer operations on
the stack objects will become operations on the escaped heap
objects. As we've already supported ASan detection of error
memory accesses to heap objects. With this trick, we can use
-asan option to report errors on bad stack operations.
Add test cases.
Updates #44853.
CustomizedGitHooks: yes
Change-Id: I4e7fe46a3ce01f0d219e6a67dc50f4aff7d2ad87
Reviewed-on: https://go-review.googlesource.com/c/go/+/325629
Trust: Fannie Zhang <Fannie.Zhang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
A long time ago, gofmt insisted on inserting tabs in /* */ comments
at the top level of the file, like this:
/*
Package doc comment.
*/
package p
Gofmt still insists on the tab for comments not at top level,
but it has relaxed the rules about top-level comments.
A few very old doc comments are indented, left over from the old rule.
We are considering formatting doc comments, and so to make
everything consistent, standardize on unindented doc comments
by removing tabs in the few doc comments that are still indented this way.
Also update some cmd/gofmt testdata to match.
Change-Id: I293742e39b52f8a48ec41f72ca4acdafa7ce43bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/384261
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some systems set an artificially low soft limit on open file count,
for compatibility with code that uses select and its hard-coded
maximum file descriptor (limited by the size of fd_set).
Go does not use select, so it should not be subject to these limits.
On some systems the limit is 256, which is very easy to run into, even
in simple programs like gofmt when they parallelize walking a file tree.
After a long discussion on go.dev/issue/46279, we decided the best
approach was for Go to raise the limit unconditionally for itself, and
then leave old software to set the limit back as needed. Code that
really wants Go to leave the limit alone can set the hard limit, which
Go of course has no choice but to respect.
Fixes#46279.
Change-Id: Id6107503437d47a870a41be25e822fc79cea08b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/392415
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL fixes encoding of PrefetchStreamed on PPC64 to be consistent
with what is implemented on AMD64 and ARM64 platforms which is
prefetchNTA (prefetch non-temporal access). Looking at the definition
of prefetchNTA, the closest corresponding Touch hint (TH) value to be
used on PPC64 is 16 that states that the address is accessed in a
transient manner. Current usage of TH=8 may cause degraded
performance.
Change-Id: I393bf5a9b971a22f632b3cbfb4fa659062af9a27
Reviewed-on: https://go-review.googlesource.com/c/go/+/390316
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Some arithmetic operation instructions such as ADD and SUB support two
formats of left shift (<<) operation, namely shifted register format and
extended register format. And the encoding, supported registers and shifted
amount are both different.
The assembly parser doesn't distinguish them and parses them into TYPE_SHIFT
type, because the parser can't tell them apart and in most cases extended
left-shift can be replaced by shifted left-shift. The only exception is
when the second source register or the destination register is RSP.
This CL converts this case into the extended format in the preprocess stage,
which helps to simplify some of the logic of the new assembler implementation
and also makes this situation look more reasonable.
Change-Id: I2cd7d2d663b38a7ba77a9fef1092708b8cb9bc3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/311709
Trust: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trivial fix: We must skip space after either of these keywords
before we expect a closing delimiter.
Also delete the stutter-generating extra 'in' in the error message.
(See what I did there?)
Fixes#51670
Change-Id: If5415632c36eaac6699bdc0aa6ce18be956c9b53
Reviewed-on: https://go-review.googlesource.com/c/go/+/392615
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're guaranteed we won't infinite loop on deadcode-only changes,
because each change converts valid -> invalid, and there are only a
finite number of valid values.
The loops this test is looking for are those generated by rule
applications, so it isn't useful to check for loops when rules aren't
involved.
Fixes#51639
Change-Id: Idf1abeab9d47baafddc3a1197d5064faaf07ef78
Reviewed-on: https://go-review.googlesource.com/c/go/+/392760
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Having the proposal numbers recorded in the API files
should help significantly when it comes time to audit
the new API additions at the end of each release cycle.
Change-Id: Id18e8cbdf892228a10ac17e4e21c7e17de5d4ff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/392414
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test uses testgo to run 'go list', so it should use the correct
GOROOT for testgo. (This may be particularly relevant when the test
binary itself is build with -trimpath, in which case runtime.GOROOT()
is not valid.)
Updates #51483
Change-Id: I79b310f88e3a200122d6289073df1385e3e97cca
Reviewed-on: https://go-review.googlesource.com/c/go/+/391801
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Previously, myscheme:/path and myscheme:///path were treated as the same URL
although materially different. The distinction made clear by RFC 3986 sec. 5.3 where
a different recomposition behavior is expected when a URI reference has an undefined
host(authority) as in myscheme:/path vs. one with an empty host(authority)
as in myscheme:///path.
This change fixes the Parse/String roundtrip limitation for URLs with an undefined
host and a single slash.
Fixes#46059
Change-Id: I1b8d6042135513616374ff8c8dfb1cdb640f8efe
Reviewed-on: https://go-review.googlesource.com/c/go/+/391294
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
- Allow for a type parameter as length/capacity to make.
- Be slightly more precise in prose for append.
- Add a couple of links.
Change-Id: Ib97e528bab1ab55d271beeeb53d9bb7a07047b9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/391754
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- Remove "Draft" disclaimer. We're not done but the spec
is in usable shape with respect to generics features.
- Remove section on "Earlier version" and fold information
into the "Intro" section.
- Remove caveat for shifts: the rules for arithmetic operators
on type parameters apply for them as well.
- Simply state that we don't support arguments of type parameter
type for the built-ins real, imag, and complex.
Fixes#51182.
Change-Id: I6df1427de685cfe7055b64e91753aa7ebff70565
Reviewed-on: https://go-review.googlesource.com/c/go/+/391695
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For hidden closure built during stenciling to implement a function
instantiation, the function may come from other package, not local
package, which causes the ICE for code that re-export the hidden closure
after inlining.
To fix it, use the closure package for export writer when writing out
the closure itself.
Fixes#51423
Change-Id: I23b067ba14e2d602a0fc3b2e99bd9317afbe53ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/391574
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
When minimizing a value, if the value cannot be minimized (i.e. it is
the final value is the same value as was sent for minimization) return
the initial coverage map, rather than the coverageSnapshot, which is
actually the coverage map for the final minimization step and may not
accurately reflect whether the input actually expands the coverage set
or not.
Updates #48326
Change-Id: I01f0eebe5841e808b6799647d2e5fe3aa45cd2e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/391614
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The removed assertion was never incorrect, as signatures may
be from methods in interfaces, and (some) interfaces set the
receivers of their methods (so we have a position for error
reporting).
This CL changes the issue below from a release blocker to an
issue for Go 1.19.
For #51593.
Change-Id: I0c5f2913b397b9ab557ed74a80cc7a715e840412
Reviewed-on: https://go-review.googlesource.com/c/go/+/391615
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rather than naively making a slice of capacity 2*c+n,
rely on the append(..., make(...)) pattern to allocate a
slice that aligns up to the closest size class.
Performance:
name old time/op new time/op delta
BufferWriteBlock/N4096 3.03µs ± 6% 2.04µs ± 6% -32.60% (p=0.000 n=10+10)
BufferWriteBlock/N65536 47.8µs ± 6% 28.1µs ± 2% -41.32% (p=0.000 n=9+8)
BufferWriteBlock/N1048576 844µs ± 7% 510µs ± 5% -39.59% (p=0.000 n=8+9)
name old alloc/op new alloc/op delta
BufferWriteBlock/N4096 12.3kB ± 0% 7.2kB ± 0% -41.67% (p=0.000 n=10+10)
BufferWriteBlock/N65536 258kB ± 0% 130kB ± 0% -49.60% (p=0.000 n=10+10)
BufferWriteBlock/N1048576 4.19MB ± 0% 2.10MB ± 0% -49.98% (p=0.000 n=10+8)
name old allocs/op new allocs/op delta
BufferWriteBlock/N4096 3.00 ± 0% 3.00 ± 0% ~ (all equal)
BufferWriteBlock/N65536 7.00 ± 0% 7.00 ± 0% ~ (all equal)
BufferWriteBlock/N1048576 11.0 ± 0% 11.0 ± 0% ~ (all equal)
The performance is faster since the growth rate is capped at 2x,
while previously it could grow by amounts potentially much greater than 2x,
leading to significant amounts of memory waste and extra copying.
Credit goes to Martin Möhrmann for suggesting the
append(b, make([]T, n)...) pattern.
Fixes#42984
Updates #51462
Change-Id: I7b23f75dddbf53f8b8b93485bb1a1fff9649b96b
Reviewed-on: https://go-review.googlesource.com/c/go/+/349994
Trust: Joseph Tsai <joetsai@digital-static.net>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
go/token has had a global "keywords" map filled at init time for years.
Overall, the package's init time cost is small, as per GODEBUG=inittrace=1:
init go/token @0.51 ms, 0.004 ms clock, 1776 bytes, 5 allocs
init go/token @0.44 ms, 0.003 ms clock, 1776 bytes, 5 allocs
init go/token @0.45 ms, 0.003 ms clock, 1568 bytes, 4 allocs
However, adding the map size hint does help with the allocations:
init go/token @0.45 ms, 0.002 ms clock, 944 bytes, 2 allocs
init go/token @0.46 ms, 0.002 ms clock, 944 bytes, 2 allocs
init go/token @0.55 ms, 0.003 ms clock, 1152 bytes, 3 allocs
Three samples are rather unscientific, and the clock time is basically
unchanged, but we might as well reduce the allocs.
Change-Id: I48121a4cea4113d991882e32f274d7b7736800dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/391094
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
- Change section title from "Type parameters lists" to
"Type parameter declarations" as the enclosing section
is about declarations.
- Correct section on parsing ambiguity in type parameter
lists.
- Rephrase paragraphs on type parameters for method receivers
and adjust examples.
- Remove duplicate prose in section on function argument type
inference.
- Clarified "after substitution" column in Instantiations section.
Change-Id: Id76be9804ad96a3f1221e5c4942552dde015dfcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/390994
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Specific types were introduced to explain rules for operands of
type parameter type. Specific types are really an implementation
mechanism to represent (possibly infinite) type sets in the machine;
they are not needed in the specification.
A specific type is either standing for a single named or unnamed
type, or it is the underlying (unnamed) type of an infinite set of
types. Each rule that applies to a type T of the set of specific
types must also apply to all types T' in the type set for which T
is a representative of. Thus, in the spec we can simply refer to
the type set directly, infinite or not.
Rather then excluding operands with empty type sets in each instance,
leave unspecified what happens when such an operand is used. Instead
give an implementation some leeway with an implementation restriction.
(The implementation restriction also needs to be formulated for types,
such as in conversions, which technically are not "operands". Left for
another CL.)
Minor: Remove the two uses of the word "concrete" to refer to non-
interface types; instead just say "non-interface type" for clarity.
Change-Id: I67ac89a640c995369c9d421a03820a0c0435835a
Reviewed-on: https://go-review.googlesource.com/c/go/+/390694
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Pointer types may appear in expressions *P and we don't know if
we have an indirection (P is a pointer value) or a pointer type
(P is a type) until we type-check P. Don't forget to check that
a type P must be an ordinary (not a constraint) type in this
special case.
Fixes#51578.
Change-Id: If782cc6dd2a602a498574c78c99e40c3b72274a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/391275
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Address several areas where documentation was inaccurate or unclear
regarding generic types. Also prefer the use of the word 'generic' over
'parameterized', and add additional documentation for the use of
SetConstraint.
For #49593
Change-Id: Iccac60d1b3e2c45a57a3d03b3c10984293af57dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/391154
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The -p flag specifies the import path of the package being compiled.
This CL makes it required when invoking the compiler and
adjusts tests that invoke the compiler directly to conform to this
new requirement. The go command already passes the flag, so it
is unmodified in this CL. It is expected that any other Go build systems
also already pass -p, or else they will need to arrange to do so before
updating to Go 1.19. Of particular note, Bazel already does for rules
with an importpath= attribute, which includes all Gazelle-generated rules.
There is more cleanup possible now in cmd/compile, cmd/link,
and other consumers of Go object files, but that is left to future CLs.
Additional historical background follows but can be ignored.
Long ago, before the go command, or modules, or any kind of
versioning, symbols in Go archive files were named using just the
package name, so that for example func F in math/rand and func F in
crypto/rand would both be the object file symbol 'rand.F'. This led to
collisions even in small source trees, which made certain packages
unusable in the presence of other packages and generally was a problem
for Go's goal of scaling to very large source trees.
Fixing this problem required changing from package names to import
paths in symbol names, which was mostly straightforward. One wrinkle,
though, is that the compiler did not know the import path of the
package being compiled; it only knew the package name. At the time,
there was no go command, just Makefiles that people had invoking 6g
(now “go tool compile”) and then copying the resulting object file to
an importable location. That is, everyone had a custom build setup for
Go, because there was no standard one. So it was not particularly
attractive to change how the compiler was invoked, since that would
break approximately every Go user at the time. Instead, we arranged
for the compiler to emit, and other tools reading object files to
recognize, a special import path (the empty string, it turned out)
denoting “the import path of this object file”. This worked well
enough at the time and maintained complete command-line compatibility
with existing Go usage.
The changes implementing this transition can be found by searching
the Git history for “package global name space”, which is what they
eliminated. In particular, CL 190076 (a6736fa4), CL 186263 (758f2bc5),
CL 193080 (1cecac81), CL 194053 (19126320), and CL 194071 (531e6b77)
did the bulk of this transformation in January 2010.
Later, in September 2011, we added the -p flag to the compiler for
diagnostic purposes. The problem was that it was easy to create import
cycles, especially in tests, and these could not be diagnosed until
link time. You'd really want the compiler to diagnose these, for
example if the compilation of package sort noticed it was importing a
package that itself imported "sort". But the compilation of package
sort didn't know its own import path, and so it could not tell whether
it had found itself as a transitive dependency. Adding the -p flag
solved this problem, and its use was optional, since the linker would
still diagnose the import cycle in builds that had not updated to
start passing -p. This was CL 4972057 (1e480cd1).
There was still no go command at this point, but when we introduced
the go command we made it pass -p, which it has for many years at this
point.
Over time, parts of the compiler began to depend on the presence of
the -p flag for various reasonable purposes. For example:
In CL 6497074 (041fc8bf; Oct 2012), the race detector used -p to
detect packages that should not have race annotations, such as
runtime/race and sync/atomic.
In CL 13367052 (7276c02b; Sep 2013), a bug fix used -p to detect the
compilation of package reflect.
In CL 30539 (8aadcc55; Oct 2016), the compiler started using -p to
identify package math, to be able to intrinsify calls to Sqrt inside
that package.
In CL 61019 (9daee931; Sep 2017), CL 71430 (2c1d2e06; Oct 2017), and
later related CLs, the compiler started using the -p value when
creating various DWARF debugging information.
In CL 174657 (cc5eaf93; May 2019), the compiler started writing
symbols without the magic empty string whenever -p was used, to reduce
the amount of work required in the linker.
In CL 179861 (dde7c770; Jun 2019), the compiler made the second
argument to //go:linkname optional when -p is used, because in that
case the compiler can derive an appropriate default.
There are more examples. Today it is impossible to compile the Go
standard library without using -p, and DWARF debug information is
incomplete without using -p.
All known Go build systems pass -p. In particular, the go command
does, which is what nearly all Go developers invoke to build Go code.
And Bazel does, for go_library rules that set the importpath
attribute, which is all rules generated by Gazelle.
Gccgo has an equivalent of -p and has required its use in order to
disambiguate packages with the same name but different import paths
since 2010.
On top of all this, various parts of code generation for generics
are made more complicated by needing to cope with the case where -p
is not specified, even though it's essentially always specified.
In summary, the current state is:
- Use of the -p flag with cmd/compile is required for building
the standard library, and for complete DWARF information,
and to enable certain linker speedups.
- The go command and Bazel, which we expect account for just
about 100% of Go builds, both invoke cmd/compile with -p.
- The code in cmd/compile to support builds without -p is
complex and has become more complex with generics, but it is
almost always dead code and therefore not worth maintaining.
- Gccgo already requires its equivalent of -p in any build
where two packages have the same name.
All this supports the change in this CL, which makes -p required
and adjusts tests that invoke cmd/compile to add -p appropriately.
Future CLs will be able to remove all the code dealing with the
possibility of -p not having been specified.
Change-Id: I6b95b9d4cffe59c7bac82eb273ef6c4a67bb0e43
Reviewed-on: https://go-review.googlesource.com/c/go/+/391014
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is a feature that is not understood well enough and may have
subtle repercussions impacting future changes. Disable for Go 1.18.
The actual change is trivial: disable a branch through a flag.
The remaining changes are adjustments to tests.
Fixes#51576.
Change-Id: Ib77b038b846711a808315a8889b3904e72367bce
Reviewed-on: https://go-review.googlesource.com/c/go/+/391135
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When building the inlining deck, correctly identify which is the last
frame in the deck. Otherwise, when some forms of inlining cause a PC to
expand to multiple frames, the length of the deck's two slices will
diverge.
Fixes#51567
Change-Id: I24e7ba32cb16b167f4307178b3f03c29e5362c4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/391134
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Than McIntosh <thanm@google.com>
Unified IR wasn't marking instantiated generic functions as DUPOK,
even though they can appear in multiple compilation units, which
evidently interfered with cmd/link's dead code elimination logic.
Manually confirmed to fix the issue, but non-trivial to test within
$GOROOT/test currently, because it's only reproducible when
cmd/compile is invoked with -p. @rsc is currently investigating
updating test/run.go appropriately, after which I'll revisit writing a
test case.
Fixes#51519.
Change-Id: I74a79ed0ca15b25b826e419714af5ceb6e567012
Reviewed-on: https://go-review.googlesource.com/c/go/+/390956
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
In function prologue and epilogue, we save and restore FP and LR
registers, and adjust RSP. The current instruction sequence is as
follow.
For frame size <= 240B,
prologue:
MOVD.W R30, -offset(RSP)
MOVD R29, -8(RSP)
epilogue:
MOVD -8(RSP), R29
MOVD.P offset(RSP), R30
For frame size > 240B,
prologue:
SUB $offset, RSP, R27
MOVD R30, (R27)
MOVD R27, RSP
MOVD R29, -8(RSP)
epilogue:
MOVD -8(RSP), R29
MOVD (RSP), R30
ADD $offset, RSP
Each sequence uses two load or store instructions, actually we can load
or store two registers with one LDP or STP instruction. This CL changes
the sequences as follow.
For frame size <= 496B,
prologue:
STP (R29, R30), -(offset+8)(RSP)
SUB $offset, RSP, RSP
epilogue:
LDP -8(RSP), (R29, R30)
ADD $offset, RSP, RSP
For frame size > 496B,
prologue:
SUB $offset, RSP, R20
STP (R29, R30), -8(R20)
MOVD R20, RSP
epilogue:
LDP -8(RSP), (R29, R30)
ADD $offset, RSP, RSP
Change-Id: Ia58af85fc81cce9b7c393dc38df43bffb203baad
Reviewed-on: https://go-review.googlesource.com/c/go/+/379075
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Given that we have seen failures with the same failure mode on both
openbsd/arm and android/arm64, it seems likely that the underlying bug
affects at least all ARM-based architectures.
It appears that either these architectures are not able to sample at
the frequency expected by the test, or the samples are for some reason
being dropped.
For #50218
Change-Id: I42a6c8ecda57448f8068e8facb42a4a2cecbbb37
Reviewed-on: https://go-review.googlesource.com/c/go/+/383997
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Knowing whether test failures are correlated with specific CPU models on
has proven useful on several issues. Log it for prior to testing so it
is always available.
internal/sysinfo provides the CPU model, but it is not available in the
bootstrap toolchain, so we can't access this in cmd/dist. Instead use a
separate binary which cmd/dist will only build once testing begins.
The addition of new data to the beginning of cmd/dist output will break
x/build/cmd/coordinator's banner parsing, leaving extra lines in the log
output, though information will not be lost.
https://golang.org/cl/372538 fixes up the coordinator and should be
submitted and deployed before this CL is submitted.
This is a redo of CL 371474. It switches back to the original approach
of using a separate binary, as the bootstap toolchain won't allow
cmd/dist to import internal packages.
For #46272.
For #49209.
For #50146.
Change-Id: I906bbda987902a2120c5183290a4e89a2440de58
Reviewed-on: https://go-review.googlesource.com/c/go/+/378589
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When describing call stacks that include inlined function calls, the
runtime uses "fake" PCs to represent the frames that inlining removed.
Those PCs correspond to real NOP instructions that the compiler inserts
for this purpose.
Describing the call stack in a protobuf-formatted profile requires the
runtime/pprof package to collapse any sequences of fake call sites back
into single PCs, removing the NOPs but retaining their line info.
But because the NOP instructions are part of the function, they can
appear as leaf nodes in a CPU profile. That results in an address that
should sometimes be ignored (when it appears as a call site) and that
sometimes should be present in the profile (when it is observed
consuming CPU time).
When processing a PC address, consider it first as a fake PC to add to
the current inlining deck, and then as a previously-seen (real) PC.
Fixes#50996
Change-Id: I80802369978bd7ac9969839ecfc9995ea4f84ab4
Reviewed-on: https://go-review.googlesource.com/c/go/+/384239
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This test was failing locally in my clone of the go repo due to a Git
branch ending in ".go", which the test found and was attempting to
parse as a file. It's fragile to try to parse .go files in
GOROOT/.git, and wasteful to scan GOROOT/pkg and other non-source
directories; instead, let's only parse the directories we actually
expect to contain source files.
(I was running the test for #51461.)
Change-Id: I5d4e31ec2bcd9b4b6840ec32ad9b12bf44f349a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/390023
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Also switch float64 NaN encoding to use hexadecimal, and accept
hexadecimal encoding for all other integer types too. (That gives us
the flexibility to change the encodings in either direction in the
future without breaking earlier Go versions.)
Out-of-range runes encoded using "%q" were previously replaced with
the Unicode replacement charecter, losing their values.
Out-of-range ints and uints on 32-bit platforms were previously
rejected. Now they are wrapped instead: an “interesting” case with a
large int or uint found on a 64-bit platform likely remains
interesting on a 32-bit platform, even if the specific values differ.
To verify the above changes, I have made TestMarshalUnmarshal accept
(and check for) arbitrary differences between input and output, and
added tests cases that include values in valid but non-canonical
encodings.
I have also added round-trip fuzz tests in the opposite direction for
most of the types affected by this change, verifying that a marshaled
value unmarshals to the same bitwise value.
Updates #51258
Updates #51526Fixes#51528
Change-Id: I7727a9d0582d81be0d954529545678a4374e88ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/390424
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
If you attempt to instantiate a generic type or func and run 'go build'
with a language version < 1.18 in the 'go' directive inside the go.mod
file, cmd/compile emits a friendly message that includes the suggestion
to 'check go.mod':
type instantiation requires go1.18 or later (-lang was set to go1.17; check go.mod)
However, if the code instead only declares a generic type or func
without instantiating, cmd/compile currently emits a less friendly
message:
type parameters require go1.18 or later
With this CL, the error in that situation becomes:
type parameter requires go1.18 or later (-lang was set to go1.17; check go.mod)
Within cmd/compile/internal/types2, it already calls check.versionErrorf
in a dozen or so places, including three existing calls to
check.versionErrorf within typeset.go (e.g., for embedding a constraint
interface).
This CL adds two more calls to check.versionErrorf, replacing calls to
check.softErrorf. Both check.versionErrorf and check.softErrorf call
check.err(at, <string>, true) after massaging the string message.
Fixes#51531
Change-Id: If54e179f5952b97701d1dfde4abb08101de07811
GitHub-Last-Rev: b0b7c1346f
GitHub-Pull-Request: golang/go#51536
Reviewed-on: https://go-review.googlesource.com/c/go/+/390578
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
The fieldtrack support is experimental and used mainly inside Google,
where we have included this change for years. No reason not to make
it in the public copy.
Change-Id: I5233e4e775ccce60a17098c007aed8c82a0425d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/387355
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The old code picks a random number n and then tests n, n+2, n+4, up to
n+(1<<20) for primality before giving up and picking a new n.
(The chance of finishing the loop and picking a new n is infinitesimally
small.) This approach, called “incremental search” in the Handbook of
Applied Cryptography, section 4.51, demands fewer bits from the random
source and amortizes some of the cost of the small-prime division
checks across the incremented values.
This commit deletes the n+2, n+4, ... checks, instead picking a series
of random n and stopping at the first one that is probably prime.
This approach is called “rejection sampling.”
Reasons to make this change, in decreasing order of importance:
1. Rejection sampling is simpler, and simpler is more clearly correct.
2. The main benefit of incremental search was performance, and that is
less important than before. Incremental search required fewer random
bits and was able to amortize the checks for small primes across the
entire sequence. However, both random bit generation and primality
checks have gotten faster much quicker than typical primes have
gotten longer, so the benefits are not as important today.
Also, random prime generation is not typically on the critical path.
Negating any lingering concerns about performance, rejection sampling
no slower in practice than the incremental search, perhaps because
the incremental search was using a somewhat inefficient test to
eliminate multiples of small primes; ProbablyPrime does it better.
name old time/op new time/op delta
Prime/MathRand 69.3ms ±23% 68.0ms ±37% ~ (p=0.531 n=20+19)
Prime/CryptoRand 69.2ms ±27% 63.8ms ±36% ~ (p=0.076 n=20+20)
(Here, Prime/MathRand is the current Prime benchmark,
and Prime/CryptoRand is an adaptation to use crypto/rand.Reader
instead of math/rand's non-cryptographic randomness source,
just in case the quality of the bits affects the outcome.
If anything, rejection sampling is even better with cryptographically
random bits, but really the two are statistically indistinguishable
over 20 runs.)
3. Incremental search has a clear bias when generating small primes:
a prime is more likely to be returned the larger the gap between
it and the next smaller prime. Although the bias is negligible in
practice for cryptographically large primes, people can measure the
bias for smaller prime sizes, and we have received such reports
extrapolating the bias to larger sizes and claiming a security bug
(which, to be clear, does not exist).
However, given that rejection sampling is simpler, more clearly
correct and at least no slower than incremental search, the bias
is indefensible.
4. Incremental search has a timing leak. If you can tell the incremental
search ran 10 times, then you know that p is such that there are no
primes in the range [p-20, p). To be clear, there are other timing
leaks in our current primality testing, so there's no definitive
benefit to eliminating this one, but there's also no reason to keep
it around.
(See https://bugs.chromium.org/p/boringssl/issues/detail?id=238 for
all the work that would be needed to make RSA key generation
constant-time, which is definitely not something we have planned for
Go crypto.)
5. Rejection sampling moves from matching OpenSSL to matching BoringSSL.
As a general rule BoringSSL is the better role model.
(Everyone started out using incremental search; BoringSSL switched
to rejection sampling in 2019, as part of the constant-time work
linked above.)
Change-Id: Ie67e572a967c12d8728c752045c7e38f21804f8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/387554
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Type inference for types was always a "nice to have" feature.
Given the under-appreciated complexity of making it work in all
cases, and the fact that we don't have a good understanding of
how it might affect readability of generic code, require explicit
type arguments for generic types.
This matches the current implementation.
Change-Id: Ie7ff6293d3fbea92ddc54c46285a4cabece7fe01
Reviewed-on: https://go-review.googlesource.com/c/go/+/390577
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When framesize <= objabi.StackSmall, 128B, the stacksplit prologue is:
MOVD 16(g), R16
MOVD SP, R17
CMP R16, R17
BLS morestack_label
The second instruction is not necessary, we can compare R16 with SP
directly, so the sequence becomes:
MOVD 16(g), R16
CMP R16, SP
BLS morestack_label
This CL removes this instruction.
Change-Id: I0567ac52e9be124880957271951e1186da203612
Reviewed-on: https://go-review.googlesource.com/c/go/+/379076
Trust: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This patch allows to zerocopy using MultiReader.
This is done by MultiReader implementing WriterTo.
Each sub reader is copied using usual io copy helper and thus use
WriterTo or ReadFrom with reflection.
There is a special case for when a subreader is a MultiReader.
Instead of using copyBuffer which would call multiReader.WriteTo,
multiReader.writeToWithBuffer is used instead, the difference
is that the temporary copy buffer is passed along, saving
allocations for nested MultiReaders.
The workflow looks like this:
- multiReader.WriteTo (allocates 32k buffer)
- multiReader.writeToWithBuffer
- for each subReader:
- is instance of multiReader ?
- yes, call multiReader.writeToWithBuffer
- no, call copyBuffer(writer, currentReader, buffer)
- does currentReader implements WriterTo ?
- yes, use use currentReader.WriteTo
- no, does writer implement ReadFrom ?
- yes, use writer.ReadFrom
- no, copy using Read / Write with buffer
This can be improved by lazy allocating the 32k buffer.
For example a MultiReader of such types:
MultiReader(
bytes.Reader, // WriterTo-able
bytes.Reader, // WriterTo-able
bytes.Reader, // WriterTo-able
)
Doesn't need any allocation, all copy can be done using bytes.Reader's
internal data slice. However currently we still allocate a 32k buffer
for nothing.
This optimisation has been omitted for a future patch because of high
complexity costs for a non obvious performance cost (it needs a benchmark).
This patch at least is on par with the previous MultiReader.Read
workflow allocation wise.
Fixes#50842
Change-Id: Ib070c8f36337d9dd86090df8a703c5df97a773ae
GitHub-Last-Rev: 8ebe60ceac
GitHub-Pull-Request: golang/go#51502
Reviewed-on: https://go-review.googlesource.com/c/go/+/390215
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
This change includes several smaller changes based on feedback
received so far.
These changes were reviewed at CL 385536. The only additional
change here is to the current date in the subtitle.
Change-Id: I653eb4a143e3b86c5357a2fd3b19168419c9f432
Reviewed-on: https://go-review.googlesource.com/c/go/+/390634
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
go/build is one of the packages that contributes the most towards
cmd/go's init cost, which adds up to any call to the tool.
One piece of low-hanging fruit is knownOS and knownArch,
maps which are filled via an init func from a space-separated list.
Using GODEBUG=inittrace=1, we can get three samples:
init go/build @0.36 ms, 0.024 ms clock, 6568 bytes, 74 allocs
init go/build @0.33 ms, 0.025 ms clock, 6888 bytes, 76 allocs
init go/build @0.36 ms, 0.025 ms clock, 6728 bytes, 75 allocs
After using a static map instead, we see an improvement:
init go/build @0.33 ms, 0.018 ms clock, 5096 bytes, 69 allocs
init go/build @0.36 ms, 0.021 ms clock, 5096 bytes, 69 allocs
init go/build @0.33 ms, 0.019 ms clock, 5096 bytes, 69 allocs
The speedup isn't huge, but it helps, and also reduces allocs.
One can also imagine that the compiler may get better with static,
read-only maps in the future, whereas the init func will likely always
have a linear cost and extra allocations.
Change-Id: I430212bad03d25358d2cc7b1eab4536ad88d05a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/390274
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In Checker.typInternal, the SelectorExpr case was the only case that
didn't either set or pass along the incoming def *Named type.
Handle this by passing it along to Checker.selector and report a
cycle if one is detected.
Fixes#51509.
Change-Id: I6c2d46835f225aeb4cb25fe0ae55f6180cef038b
Reviewed-on: https://go-review.googlesource.com/c/go/+/390314
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The comparable bit was handled incorrectly. This CL establishes
a clear invariant for a type set's terms and its comparable bit
and correctly uses the bit when computing term intersections.
Relevant changes:
- Introduce a new function intersectTermLists that does the
correct intersection computation.
Minor:
- Moved the comparable bit after terms in _TypeSet to make it
clearer that they belong together.
- Simplify and clarify _TypeSet.IsAll predicate.
- Remove the IsTypeSet predicate which was only used for error
reporting in union.go, and use the existing predicates instead.
- Rename/introduce local variables in computeInterfaceTypeSet
for consistency and to avoid confusion.
- Update some tests whose output has changed because the comparable
bit is now only set if we have have the set of all types.
For instance, for interface{comparable; int} the type set doesn't
set the comparable bit because the intersection of comparable and
int is just int; etc.
- Add many more comments to make the code clearer.
Fixes#51472.
Change-Id: I8a5661eb1693a41a17ce5f70d7e10774301f38ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/390025
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that we always use types2 to validate user source code, we can
remove the constSet logic from typecheck for detecting duplicate
expression switch cases and duplicate map literal keys. This logic is
redundant with types2, and currently causes unified IR to report
inappropriate duplicate constant errors that only appear after type
substitution.
Updates #42758.
Change-Id: I51ee2c5106eec9abf40eba2480dc52603c68ba21
Reviewed-on: https://go-review.googlesource.com/c/go/+/390474
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Previous value used in the float32 roundtrip used float32(math.NaN())-1
which caused the quiet/signal bit to flip, which seemed to break the
test on MIPS platforms. Instead switch to using float32(math.NaN())+1,
which preserves the bit and makes the test happy.
Possibly related to #37455Fixes#51258
Change-Id: Ia85c649e89a5d02027c0ec197f0ff318aa819c19
Reviewed-on: https://go-review.googlesource.com/c/go/+/390214
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL switches unified IR to using ir.DynamicType for derived
types. This has an immediate effect of fixing compilation of generic
code that when fully stenciled results in statically invalid type
assertions. This does require updating typecheck to expect
ODYNAMICTYPE in type switches, but this is straightforward to
implement.
For now, we still statically resolve the runtime type (or itab)
pointer. However, a subsequent CL will allow reading these pointers
from the runtime dictionary.
Change-Id: I1666678fcc588bc9cb8b97871bd02b9059848e6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/390336
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
A few of the tests were printing garbage to stderr,
since FlagSet's default Output is os.Stderr:
$ go test
flag provided but not defined: -x
invalid value "1" for flag -v: test error
Usage of test:
flag needs an argument: -b
Usage of test:
-b usage
PASS
ok flag 0.008s
Add the remaining SetOutput(io.Discard) method calls.
Note that TestUserDefinedFunc was a tricky one.
Even with the added SetOutput calls,
the last part of the test would still print usage text to stderr.
It took me a while to figure out the problem was copying FlagSet.
I've filed go.dev/issue/51507 to record this particular sharp edge,
and the test code now avoids making FlagSet copies to avoid the bug.
Change-Id: I323f24091b98386312aa72df3eb890af6625628d
Reviewed-on: https://go-review.googlesource.com/c/go/+/390234
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before #46477, the Go generics proposal allowed `type T = U` where `U`
was an uninstantiated generic type. However, we decided not to allow
that, and go/types and types2 have already been updated to disallow
it. This CL just removes the analogous code from unified IR.
Change-Id: I0fe6d1754c96790b498c1d5185b948333646d7de
Reviewed-on: https://go-review.googlesource.com/c/go/+/390315
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
We shouldn't need to read in function bodies for new functions found
during inlining, but something is expecting them to still be read
in. We should fix that code to not depend on them being read in, but
in the mean time reading them in anyway is at least correct, albeit
less efficient in time and space.
Fixes#49536.
Updates #50552.
Change-Id: I949ef45e7be09406e5a8149e251d78e015aca5fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/390335
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Use dup3(oldfd, newfd, O_CLOEXEC) to atomically duplicate the file
descriptor and mark is as close-on-exec instead of dup2 & fcntl.
The dup3 system call first appeared in OpenBSD 5.7.
Change-Id: Ic06c2c7089dcdbd931ee24e5e8c316879d81474e
Reviewed-on: https://go-review.googlesource.com/c/go/+/389974
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Improve the test coverage of encoding/xml package by adding
the test cases for the execution paths that were not covered before.
Since it reveals a couple of issues, fix them as well while we're at it.
As I used an `strings.EqualFold` instead of adding one more `strings.ToLower`,
our fix to `autoClose()` tends to run faster as well as a result.
name old time/op new time/op delta
HTMLAutoClose-8 5.93µs ± 2% 5.75µs ± 3% -3.16% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
HTMLAutoClose-8 2.60kB ± 0% 2.58kB ± 0% -0.46% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
HTMLAutoClose-8 72.0 ± 0% 67.0 ± 0% -6.94% (p=0.000 n=10+10)
The overall `encoding/xml` test coverage increase is `88.1% -> 89.9%`;
although it may look insignificant, this CL covers some important corner cases,
like `autoClose()` functionality (that was not tested at all).
Fixes#49635Fixes#49636
Change-Id: I50b2769896c197eb285672313b7148f4fe8bdb38
Reviewed-on: https://go-review.googlesource.com/c/go/+/364734
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
An extra "go build" was happening, for the sake of -tags=testgo,
which would insert some extra behavior into ./internal/work.
Instead, reuse the test binary as cmd/go directly,
by calling the main func when a special env var is set.
We still duplicate the test binary into testBin,
because we need a "go" executable in that directory for $PATH.
Finally, the special behavior is instead inserted via TestMain.
The numbers below represent how long it takes to run zero tests,
measured via:
benchcmd GoTestNothing go test -run=-
That is, the time it takes to run the first test is reduced by half.
Note that these numbers are on a warm build cache,
so if the -tags=testgo build were to be done from scratch,
the speed-up would be significantly more noticeable.
name old time/op new time/op delta
GoTestNothing 830ms ± 2% 380ms ± 7% -54.23% (p=0.008 n=5+5)
name old user-time/op new user-time/op delta
GoTestNothing 1.64s ± 1% 0.82s ± 3% -50.24% (p=0.008 n=5+5)
name old sys-time/op new sys-time/op delta
GoTestNothing 306ms ± 7% 159ms ±28% -48.15% (p=0.008 n=5+5)
name old peak-RSS-bytes new peak-RSS-bytes delta
GoTestNothing 173MB ± 1% 147MB ± 1% -14.96% (p=0.008 n=5+5)
Change-Id: I1f8fc71269a7b45bc5b82b7228e13f56589d44c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/378294
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
The X9.31 expander is now only used for plan9. Perhaps once upon a time
there was a use for abstraction, but the code is now covered in hacky
"fileName == urandomDevice" and "GOOS == plan9" checks, to the point
where the abstraction is much too leaky. Since plan9 is the only
platform that has a /dev/random without a /dev/urandom, we can simplify
both the generic urandom code and the plan9 X9.31 code by separating
them into different files, each focusing on doing one thing well.
Change-Id: I0ca43b748a0fbbd60f2ec7819688a540506d34df
Reviewed-on: https://go-review.googlesource.com/c/go/+/370580
Trust: Jason Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The finalizer is called using reflectcall. When register ABI is
used, the finalizer's argument is passed in register(s). But the
frame size calculation does not include the spill slot. When the
argument actually spills, it may clobber the caller's stack frame.
This CL fixes it.
Change-Id: Ibcc7507c518ba65c1c5a7759e5cab0ae3fc7efce
Reviewed-on: https://go-review.googlesource.com/c/go/+/389574
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Both endians perform syscalls similarly. Only CR0S0 and R3 hold
the resultant status of a syscall. A random value may be stored into
the second return value (r2) result in some cases. Always set it to
zero.
Fixes#51192
Change-Id: Ida6a5692578d2cdadf3099af28478b3bc364f623
Reviewed-on: https://go-review.googlesource.com/c/go/+/385796
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Paul Murphy <murp@ibm.com>
The preferred form of nop is ori 0,0,0. What was being generated was
or 0,0,0.
Fix a quirk in the assembler which effectively treats OR $0,Rx,Ry as
OR R0,Rx,Ry, and update the compiler to generate the preferred form.
Change-Id: I5ac4bf0258cff05b9eba516a767daebfc9e31bc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388974
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Paul Murphy <murp@ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Workaround the minor endian differences, and avoid needing to
stack a frame as extra VSRs can be used in a similar capacity.
The microbenchmarks show no significant differences on ppc64le/p9.
ppc64/linux performance difference on a POWER9:
name old time/op new time/op delta
Hash8Bytes 686ns ± 0% 372ns ± 0% -45.78%
Hash1K 9.17µs ± 0% 4.24µs ± 0% -53.74%
Hash8K 67.9µs ± 0% 31.7µs ± 0% -53.35%
Fixes#50785
Change-Id: I43d87670127df9767d54d10b5165b84e5b88f5d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/380776
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Paul Murphy <murp@ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The existing codegen strategy in sort.go relied on parsing the sort.go source
with go/ast and a combination of an AST rewrite + code text rewrite with regexes
to generate zfuncversion -- the same sort functionality with a different variant
of data.
In preparation for implementing #47619, we need a more robust codegen
strategy. To generate variants required for the generic sort functions
in the slices package, we'd need significanly more complicated AST
rewrites, which would make genzfunc.go much heavier.
Instead, redo the codegen strategy to use text/template instead of AST rewrites.
gen_sort_variants.go now contains the code for the underlying sort functions,
and generates multiple versions of them based on Variant configuration structs.
With this approach, adding new variants to generate generic sort functions for
the slices package becomes trivial.
See the discussion in #47619 for more details on the design decisions.
Change-Id: I8af784c41b1dc8ef92aaf6321359e8faa5fe106c
Reviewed-on: https://go-review.googlesource.com/c/go/+/353069
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Than McIntosh <thanm@google.com>
This adds an asm implementation of aes-cbc for ppc64le to
improve performance. This is ported from the
cryptogams implementation as are other functions in
crypto/aes with further description at the top of
the asm file.
Improvements on a power10:
name old time/op new time/op delta
AESCBCEncrypt1K 1.67µs ± 0% 0.87µs ±-48.15%
AESCBCDecrypt1K 1.35µs ± 0% 0.43µs ±-68.48%
name old speed new speed delta
AESCBCEncrypt1K 614MB/s ± 0% 1184MB/s ± 0%+92.84%
AESCBCDecrypt1K 757MB/s ± 0% 2403M/s ± 0 +217.21%
A fuzz test to compare the generic Go implemenation
against the asm implementation has been added.
Change-Id: I18613dfc95c640820b8f1c60d29df638efc7a75c
Reviewed-on: https://go-review.googlesource.com/c/go/+/355429
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Paul Murphy <murp@ibm.com>
Trust: Paul Murphy <murp@ibm.com>
This CL is a bit overkill, but it is pretty safe for 1.18. We'll
want to revisit for 1.19 so we can avoid the hash collisions between
types, e.g. G[int] and G[float64], that will cause some slowdowns
(but not incorrect behavior). Thanks Cherry for the simple idea.
Fixes#51250
Change-Id: I68130e09ba68e7cc35687bc623f63547bc552867
Reviewed-on: https://go-review.googlesource.com/c/go/+/389474
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This template is based on CL 342070 and previous ones like it.
Continue to eagerly include often-used sections, and clarify that
the TODO is about completing the section, or removing if it turns
out not to be needed.
Move the Go 1.18 release notes to x/website, since that's the new
home for past Go release notes as of CL 291711. They're added to
x/website in CL 388556.
For #51400
Updates #47694
Change-Id: I7b5213e039ad6e14a7ff7ad486311efcecc06824
Reviewed-on: https://go-review.googlesource.com/c/go/+/388515
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This adds big endian support for the assembly implementation of
sha512. There was a recent request to do this for sha256 for
AIX users; for completeness, the same is being done for sha512.
The majority of the code is common between big and little
endian with a few differences controlled by ifdefs: with LE
the generation of a mask is needed along with VPERM instructions
to put bytes in the correct order; some VPERMs need the V
registers in a different order.
name old time/op new time/op delta
Hash8Bytes 1.02µs ± 0% 0.38µs ± 0% -62.68%
Hash1K 7.01µs ± 0% 2.43µs ± 0% -65.42%
Hash8K 50.2µs ± 0% 14.6µs ± 0% -70.89%
Updates #50785
Change-Id: I739b5e7c07b22b5748af11ca781e82ac67adb4f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388654
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
AppendByteOrder specifies new methods for LittleEndian and BigEndian
for appending an unsigned integer to a byte slice.
The performance of AppendXXX methods are slower than PutXXX methods
since the former needs to do a few slice operations,
while the latter is essentially a single integer store.
In practice, existing usages of PutXXX performed slicing operations
around the call such that this cost was present, regardless.
name time/op
PutUint16-24 0.48ns ± 2%
AppendUint16-24 1.54ns ± 1%
PutUint32-24 0.46ns ± 2%
AppendUint32-24 0.89ns ± 1%
PutUint64-24 0.46ns ± 2%
AppendUint64-24 0.89ns ± 1%
LittleEndianPutUint16-24 0.47ns ± 2%
LittleEndianAppendUint16-24 1.54ns ± 1%
LittleEndianPutUint32-24 0.45ns ± 3%
LittleEndianAppendUint32-24 0.92ns ± 2%
LittleEndianPutUint64-24 0.46ns ± 3%
LittleEndianAppendUint64-24 0.95ns ± 4%
Fixes#50601
Change-Id: I33d2bbc93a3ce01a9269feac33a2432bc1166ead
Reviewed-on: https://go-review.googlesource.com/c/go/+/386017
Trust: Joseph Tsai <joetsai@digital-static.net>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
The latter returns a uintptr, while the former returns a unsafe.Pointer.
A uintptr is unsafe if Go ever switches to a moving GC,
while a unsafe.Pointer will be properly tracked by the GC.
We do not use unsafe.Pointer for any unsafe type conversions,
and only use it for comparability purposes, which is relatively safe.
Updates #40592
Change-Id: I813e218668704b63a3043acda4331205a3835a66
Reviewed-on: https://go-review.googlesource.com/c/go/+/360855
Trust: Joseph Tsai <joetsai@digital-static.net>
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
For cases where RFC 1952 requires a field, the code returns the error
io.ErrUnexpectedEOF except in two places: for the FNAME flag or the
FCOMMENT flag. These flags expect a null-terminated string and
readString may return an EOF if the Reader is truncated before a
null byte is found. For consistency with parsing other parts of the
header, this is converted to an unexpected EOF herein.
Follow-up to CL 14832.
Fixes#51417
Change-Id: I173283a6ae309e4a8e52fc15df404ce5db06eff1
GitHub-Last-Rev: 2e573cd961
GitHub-Pull-Request: golang/go#51418
Reviewed-on: https://go-review.googlesource.com/c/go/+/389034
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Trust: Joseph Tsai <joetsai@digital-static.net>
Trust: Ian Lance Taylor <iant@golang.org>
cmd/compile uses "noalg.struct {...}" as type name when hash and eq algorithm generation of this struct type is suppressed. This should be treated as normal struct type, that is, link shouldn't generate DW_TAG_typedef DIE for it.
Change-Id: Ifada8a818bcfa2e5615f85ead9582cead923b86c
GitHub-Last-Rev: 15de3e4a84
GitHub-Pull-Request: golang/go#50237
Reviewed-on: https://go-review.googlesource.com/c/go/+/373054
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The benchmarks added in this change revealed that ValidString
runs ~17% faster than Valid([]byte) on the ASCII prefix
of the input. Inspection of the assembly revealed that the
code generated for p[8:] required recomputing the slice capacity
to handle the cap=0 special case, which added an ADD -8 instruction.
By making len=cap, the capacity becomes a common subexpression
with the length, saving the ADD instruction.
(Thanks to khr for the tip.)
Incidentally, I tried a number of other optimizations but was
unable to make consistent gains across all benchmarks. The most
promising was to retain the bitmask of non-ASCII bytes from the
fast loop; the slow loop would shift it, and when it becomes zero,
return to the fast loop. This made the MostlyASCII benchmark 4x
faster, but made the other cases slower by up to 10%.
cpu: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
benchmark old ns/op new ns/op delta
BenchmarkValidTenASCIIChars-16 4.09 4.06 -0.85%
BenchmarkValid100KASCIIChars-16 9325 7747 -16.92%
BenchmarkValidTenJapaneseChars-16 27.0 27.2 +0.85%
BenchmarkValidLongMostlyASCII-16 57277 58361 +1.89%
BenchmarkValidLongJapanese-16 94002 93131 -0.93%
BenchmarkValidStringTenASCIIChars-16 4.15 4.07 -1.74%
BenchmarkValidString100KASCIIChars-16 7980 8019 +0.49%
BenchmarkValidStringTenJapaneseChars-16 26.0 25.9 -0.38%
BenchmarkValidStringLongMostlyASCII-16 58550 58006 -0.93%
BenchmarkValidStringLongJapanese-16 97964 100038 +2.12%
Change-Id: Ic9d585dedd9af83c27dd791ecd805150ac949f15
Reviewed-on: https://go-review.googlesource.com/c/go/+/375594
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Alex Rakoczy <alex@golang.org>
If name is empty or a keyword, we can skip the loop entirely.
Otherwise, we do the same amount of work as before.
Here is the benchmark result for go/parser:
name old time/op new time/op delta
Parse-12 2.53ms ± 2% 2.47ms ± 1% -2.38% (p=0.000 n=9+10)
ParseOnly-12 1.97ms ± 1% 1.93ms ± 2% -1.80% (p=0.000 n=10+10)
Resolve-12 560µs ± 1% 558µs ± 1% ~ (p=0.200 n=9+8)
name old speed new speed delta
Parse-12 26.1MB/s ± 2% 26.8MB/s ± 1% +2.44% (p=0.000 n=9+10)
ParseOnly-12 33.6MB/s ± 1% 34.3MB/s ± 2% +1.82% (p=0.000 n=10+10)
Resolve-12 118MB/s ± 2% 119MB/s ± 1% ~ (p=0.116 n=10+8)
Change-Id: I87ac9c2637a6c0e697382b74245ac88ef523bba7
GitHub-Last-Rev: 036bc38d83
GitHub-Pull-Request: golang/go#48534
Reviewed-on: https://go-review.googlesource.com/c/go/+/351389
Trust: David Chase <drchase@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Robert Griesemer <gri@golang.org>
When doing constraint type inference, we must consider whether the
constraint's core type is precise (no tilde) or imprecise (tilde,
or not a single specific type). In the latter case, we cannot infer
an unknown type argument from the (imprecise) core type because there
are infinitely many possible types. For instance, given
[E ~byte]
if we don't know E, we cannot infer that E must be byte (it could be
myByte, etc.). On the other hand, if we do know the type argument,
say for S in this example:
[S ~[]E, E any]
we must consider the underlying type of S when matching against ~[]E
because we have a tilde.
Because constraint type inference may infer type arguments that were
not eligible initially (because they were unknown and the core type
is imprecise), we must iterate the process until nothing changes any-
more. For instance, given
[S ~[]E, M ~map[string]S, E any]
where we initially only know the type argument for M, we must ignore
S (and E) at first. After one iteration of constraint type inference,
S is known at which point we can infer E as well.
The change is large-ish but the actual functional changes are small:
- There's a new method "unknowns" to determine the number of as of yet
unknown type arguments.
- The adjCoreType function has been adjusted to also return tilde
and single-type information. This is now conveniently returned
as (*term, bool), and the function has been renamed to coreTerm.
- The original constraint type inference loop has been adjusted to
consider tilde information.
- This adjusted original constraint type inference loop has been
nested in another loop for iteration, together with some minimal
logic to control termination.
The remaining changes are modifications to tests:
- There's a substantial new test for this issue.
- Several existing test cases were adjusted to accomodate the
fact that they inferred incorrect types: tildes have been
removed throughout. Most of these tests are for pathological
cases.
- A couple of tests were adjusted where there was a difference
between the go/types and types2 version.
Fixes#51229.
Change-Id: If0bf5fb70ec22913b5a2da89adbf8a27fbc921d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/387977
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently we only include static entries in the hint for sizing
the map when allocating a map for a map literal. Change that to
include all entries.
This will be an overallocation if the dynamic entries in the map have
equal keys, but equal keys in map literals are rare, and at worst we
waste a bit of space.
Fixes#43020
Change-Id: I232f82f15316bdf4ea6d657d25a0b094b77884ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/383634
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We use AutogeneratedPos for most compiler-generated functions. But
for method value wrappers we currently don't. Instead, we use the
Pos for their (direct) declaration if there is one, otherwise
not set it in methodValueWrapper, which will probably cause it to
inherit from the caller, i.e. the Pos of that method value
expression. If that Pos has inline information, it will cause the
method wrapper to have bogus inline information, which could lead
to infinite loop when printing a stack trace.
Change it to use AutogeneratedPos instead.
Fixes#51401.
Change-Id: I398dfe85f9f875e1fd82dc2f489dab63ada6570d
Reviewed-on: https://go-review.googlesource.com/c/go/+/388794
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This test case is failing on the noopt builder, because it disables
inlining. Evidently the explicit -gcflags flag in all of our generics
tests was overriding the noopt builder's default mode.
This CL restores a noop -gcflags to get the builder green again until
the issue can be properly fixed.
Updates #51413.
Change-Id: I61d22a007105f756104ba690b73f1d68ce4be281
Reviewed-on: https://go-review.googlesource.com/c/go/+/388894
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
ir.PkgName was only used by the old -G=0 frontend for representing
identifiers that refer to a package name. The new types2-based
frontends directly resolve the qualified identifier to the respective
object during IR construction.
Similarly, most of the ir.*Type nodes were only needed for
representing types in the IR prior to type checking. The new
types2-based frontends directly construct the corresponding types.Type
instead.
Exception: The internal typecheck.DeclFunc API used for
compiler-generated functions still depends on ir.FuncType, so that IR
node type is retained for now. (Eventually, we should update
typecheck.DeclFunc and callers to not depend on it, but it's not
urgent.)
Change-Id: I982f1bbd41eef5b42ce0f32676c7dc4a8ab6d0ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/388538
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The typechecking code for dealing with dot imports and redeclaration
errors can be removed, as these will now always be caught by types2
instead. Even when running the typecheck on internally constructed IR,
we'll never introduce new imports or redeclare identifiers.
Also, Func.Shortname (and typecheck.addmethod) was only used by the
-G=0 frontend. The new types2-based frontends directly associate
methods with their receiver type during IR construction.
Change-Id: I6578a448412141c87a0a53a6566639d9c00eeed7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388537
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
For certain values of GOMAXPROCS, the current code is less random than
it looks. For example with GOMAXPROCS=12, there are 4 coprimes: 1 5 7 11.
That's bad, as 12 and 4 are not relatively prime. So if pos == 2, then we
always pick 7 as the inc. We want to pick pos and inc independently
at random.
Change-Id: I5c7e4f01f9223cbc2db12a685dc0bced2cf39abf
Reviewed-on: https://go-review.googlesource.com/c/go/+/369976
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Unified IR quirks mode existed to help bootstrap unified IR by forcing
it to produce bit-for-bit identical output to the original gc noder
and typechecker. However, I believe it's far enough along now to stand
on its own, plus we have good test coverage of generics already for
-G=3 mode.
Change-Id: I8bf412c8bb5d720eadeac3fe31f49dc73679da70
Reviewed-on: https://go-review.googlesource.com/c/go/+/385998
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
goboringcrypto_linux_amd64.syso references pthread functions, so
we need to pass -pthread to the C linker when external linking.
Usually it is automatically added when linking with runtime/cgo
package. But in shared linkage the runtime/cgo package may be in
a separate DSO and not part of this invocation.
Fixes#49965.
Change-Id: I3a9983e715ee804594a14006f212f76769ad71db
Reviewed-on: https://go-review.googlesource.com/c/go/+/369161
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
There used to be two BoringCrypto-specific behaviors related to cipher
suites in crypto/tls:
1. in FIPS-only mode, only a restricted set of AES ciphers is allowed
2. NOT in FIPS-only mode, AES would be prioritized over ChaCha20 even if
AES hardware was not available
The motivation of (2) is unclear, and BoringSSL doesn't have equivalent
logic. This merge drops (2), and keeps (1). Note that the list of
FIPS-only ciphers does not have priority semantics anymore, but the
default logic still sorts them the same way as they used to be.
Change-Id: I50544011085cfa2b087f323aebf5338c0bd2dd33
The section doesn't survive some of the mangling of the object file we
do while building it, and ld.lld --icf=safe throws a warning on it.
Could have changed the clang invocation to add -fno-addrsig, but this
change is safer in that it doesn't affect the FIPS module build.
Change-Id: I65e097a48857f90aaa641dceb47120350ba8c073
Reviewed-on: https://go-review.googlesource.com/c/go/+/290170
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestNonUniqueHash will not work on boringcrypto because
the hash.Hash that sha256 provides is noncomparable.
Change-Id: Ie3dc2d5d775953c381674e22272cb3433daa1b31
RSA key types have a finalizer that will free the underlying C value
when the Go one is garbage collected. It's important that the finalizer
doesn't run while a cgo call is using the underlying C value, so they
require runtime.KeepAlive calls after each use.
This is error prone, so replace it with a closure that provides access
to the underlying C value and then automatically calls KeepAlive.
AES, HMAC, and ECDSA also need KeepAlives, but they have much fewer call
sites, so avoid the complexity for now.
Change-Id: I6d6f38297cd1cf384a1639974d9739a939cbdbcc
Reviewed-on: https://go-review.googlesource.com/c/go/+/221822
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Use OPENSSL_malloc for set0 functions as OPENSSL_free now catches us
using the libc malloc and aborts.
While at it, move the runtime.KeepAlive to the location of the key use.
Fixes#30158
Change-Id: I968a98d8974ca5f220e822841beb6c34290eefe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/218000
Reviewed-by: Katie Hockman <katie@golang.org>
Move the import in cipher_suites.go up where it's less likely to ever
conflict again, and remove the equivalent import from common.go, again
to reduce the likeliness of future conflicts.
Change-Id: Ib05daba7ba6ce81f665a44185b53a6e083f7c693
Updated TestBoringServerSignatureAndHash to expect RSA-PSS to work with
TLS 1.2, and hence with FIPS mode.
Change-Id: I358271b2e4804733cf61dc132fa0c5f39c2bff19
Signing-side signature algorithm selection moved to
selectSignatureScheme, so add FIPS logic there.
Change-Id: I827e7296d01ecfd36072e2139e74603ef42c6b24
This step was added in CL 188738 to work around the issue
golang.org/issue/33443. That issue has now been resolved,
so this step is no longer needed and can be removed.
Updates #33443
Change-Id: I0c9257ab61d53f3a47556882f7dfc8fc119be849
Reviewed-on: https://go-review.googlesource.com/c/go/+/189942
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The inliner seems to have gotten a bit too smart in 1.12 and it made
sha1.boringNewSHA1 disappear. Replace it with the proper
crypto/internal/boring/sig.BoringCrypto signature. Also, switch the
negative signature to sha256.(*digest), since SHA-256 is used for sure
by cmd/go. Not using crypto/internal/boring/sig.StandardCrypto just to
be safe, in case the crypto/internal/boring/sig mechanism breaks.
Also, had to fight #30833 and #30515 to get
golang.org/x/build/cmd/release to build in modules mode.
Change-Id: I46f1471582fd77daae47d00baab975109902052d
Reviewed-on: https://go-review.googlesource.com/c/go/+/169517
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Also, make the docker build script pull the latest base image so we are
not bundling an outdated system.
Change-Id: I6c8ee8ba89101232d635fc2e58f4cfc818d139ba
Reviewed-on: https://go-review.googlesource.com/c/152920
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The bootstrap stage 1 compiler was defaulting to the language version
used by the bootstrap compiler itself, typically 1.4. Normally this
doesn't matter since the bootstrap code has to build with 1.4 anyhow,
but it broke the boringcrypto branch which uses cgo during the
bootstrap, as cgo now generates code that uses type aliases.
Change-Id: I8a8312bb9ca4befaf65c00a8d71a78566075c2f7
Reviewed-on: https://go-review.googlesource.com/c/149459
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 69397422c0)
Reviewed-on: https://go-review.googlesource.com/c/149485
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Merge at CL 144340, in order to cherry-pick CL 149459 next to it, which
fixes a BoringCrypto specific breakage in the toolchain.
Change-Id: I30aeac344bbff279449e27876dc8f9c406e55e43
Also, document the fact that we cut releases only from the versioned
branches, and use the correct x/net branch.
Had to build this passing -skip_tests to release because the buildlet
was timing out (see below), but the builders on the dashboard are green.
2018/09/28 19:14:50 linux-amd64: Start.
2018/09/28 19:14:50 linux-amd64: Creating buildlet.
2018/09/28 19:15:28 linux-amd64: Pushing source to buildlet.
2018/09/28 19:15:37 linux-amd64: Writing VERSION file.
2018/09/28 19:15:38 linux-amd64: Cleaning goroot (pre-build).
2018/09/28 19:15:38 linux-amd64: Building.
2018/09/28 19:46:20 Buildlet https://farmer.golang.org:443 failed three heartbeats; final error: timeout waiting for headers
2018/09/28 19:46:20 linux-amd64: Error: Buildlet https://farmer.golang.org:443 failed heartbeat after 10.007631241s; marking dead; err=timeout waiting for headers
Change-Id: I9d982df693075f96d44aa6f163533253c8ae2914
Reviewed-on: https://go-review.googlesource.com/138555
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
In CL 48510 the gcmAble interface was changed to include the tag size.
The BoringCrypto aesCipher implementation wasn't updated, causing a
failed type assertion and consequently a performance degradation.
Change-Id: Ie5cff9ef242218d60f82795f3eb6760a57fe06f5
Reviewed-on: https://go-review.googlesource.com/127821
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Now that the standard library behavior in reading from the randomness
source is not reliable thanks to randutil.MaybeReadByte, we don't need
to emulate its behavior.
Also, since boring.RandReader is never deterministic, add an early exit
to randutil.MaybeReadByte.
Change-Id: Ie53e45ee64af635595181f71abd3c4340c600907
Reviewed-on: https://go-review.googlesource.com/117555
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Conflicts due to randutil.MaybeReadByte (kept at the top for patch
maintainability and consistency):
src/crypto/ecdsa/ecdsa.go
src/crypto/rsa/pkcs1v15.go
src/crypto/rsa/rsa.go
Change-Id: I03a2de541e68a1bbdc48590ad7c01fbffbbf4a2b
This patch used to be in crypto/internal/cipherhw.AESGCMSupport which
was removed from the tree. It was meant and documented to affect only
crypto/tls, so move the logic there.
Change-Id: I36ed4f08a5fe2abaab18907910899ae0297d1611
Reviewed-on: https://go-review.googlesource.com/114816
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Conflicts due to crypto/internal/cipherhw removal:
src/crypto/aes/cipher_amd64.go
src/crypto/internal/cipherhw/cipherhw_amd64.go
src/go/build/deps_test.go
This removes the AESGCMSupport patch, as there is no equivalent place
for it. The logic will be added back in the next change.
Change-Id: I8169069ff732b6cd0b56279c073cf5e0dd36959d
Go 1.10 expects hash.Hash implementations to have these. Make it so.
Tested by src/hash/marshal_test.go.
Change-Id: I9df366e31fe20e79385d5dbde7060b01b68c54df
Reviewed-on: https://go-review.googlesource.com/82139
Reviewed-by: Adam Langley <agl@golang.org>
This is a git merge of master into dev.boringcrypto.
The branch was previously based on release-branch.go1.9,
so there are a handful of spurious conflicts that would
also arise if trying to merge master into release-branch.go1.9
(which we never do). Those have all been resolved by taking
the original file from master, discarding any Go 1.9-specific
edits.
all.bash passes on darwin/amd64, which is to say without
actually using BoringCrypto.
Go 1.10-related fixes to BoringCrypto itself will be in a followup CL.
This CL is just the merge.
Change-Id: I4c97711fec0fb86761913dcde28d25c001246c35
CL 36932 (speed up fastrandn) made it faster but introduced
bad interference with some properties of fastrand itself, making
fastrandn not very random in certain ways. In particular, certain
selects are demonstrably unfair.
For Go 1.10 the new faster fastrandn has induced a new fastrand,
which in turn has caused other follow-on bugs that are still being
discovered and fixed.
For Go 1.9.2, just go back to the barely slower % implementation
that we used in Go 1.8 and earlier. This should restore fairness in
select and any other problems caused by the clever fastrandn.
The test in this CL is copied from CL 62530.
Fixes#22253.
Change-Id: Ibcf948a7bce981452e05c90dbdac122043f6f813
Reviewed-on: https://go-review.googlesource.com/70991
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
If we have
y = <int16> (MOVBQSX x)
z = <int32> (MOVWQSX y)
We used to use this rewrite rule:
(MOVWQSX x:(MOVBQSX _)) -> x
But that resulted in replacing z with a value whose type
is only int16. Then if z is spilled and restored, it gets
zero extended instead of sign extended.
Instead use the rule
(MOVWQSX (MOVBQSX x)) -> (MOVBQSX x)
The result is has the correct type, so it can be spilled
and restored correctly. It might mean that a few more extension
ops might not be eliminated, but that's the price for correctness.
Fixes#21963
Change-Id: I6ec82c3d2dbe43cc1fee6fb2bd6b3a72fca3af00
Reviewed-on: https://go-review.googlesource.com/65290
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/70986
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The assembler barfs on large offsets. Make sure that all the
instructions that need to have their offsets in an int32
1) check on any rule that computes offsets for such instructions
2) change their aux fields so the check builder checks it.
The assembler also silently misassembled offsets between 1<<31
and 1<<32. Add a check in the assembler to barf on those as well.
Fixes#21655
Change-Id: Iebf24bf10f9f37b3ea819ceb7d588251c0f46d7d
Reviewed-on: https://go-review.googlesource.com/59630
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-on: https://go-review.googlesource.com/70981
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
After the number of lost extra events are written to the the cpuprof log,
the number of lost extra events should be set to zero, or else, the next
time time addExtra is logged, lostExtra will be overcounted. This change
resets lostExtra after its value is written to the log.
Fixes#21836
Change-Id: I8a6ac9c61e579e7a5ca7bdb0f3463f8ae8b9f864
Reviewed-on: https://go-review.googlesource.com/63270
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/70974
Run-TryBot: Russ Cox <rsc@golang.org>
More generally I'm concerned about these tests using
$GOROOT/src/cmd/go as scratch space, especially
combined wtih tg.parallel() - it's easy to believe some other
test might inadvertently also try to write x.exe about the
same time. This CL only solves the "didn't clean up x.exe"
problem and leaves for another day the "probably shouldn't
write to cmd/go at all" problem.
Fixes#22266.
Change-Id: I651534d70e2d360138e0373fb4a316081872550b
Reviewed-on: https://go-review.googlesource.com/71410
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/71530
After we detect errors, the AST is in a precarious state and more
likely to trip useless ICE failures. Instead let the user fix any
existing errors and see if the ICE persists. This makes Fatalf more
consistent with how panics are handled by hidePanic.
While here, also fix detection for release versions: release version
strings begin with "go" ("go1.8", "go1.9.1", etc), not "release".
Fixes#22252.
Change-Id: I1c400af62fb49dd979b96e1bf0fb295a81c8b336
Reviewed-on: https://go-review.googlesource.com/70850
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/70985
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Database drivers should be called from a single goroutine to ease
driver's design. If a driver chooses to handle context
cancels internally it may do so.
The sql package violated this agreement when calling Next or
NextResultSet. It was possible for a concurrent rollback
triggered from a context cancel to call a Tx.Rollback (which
takes a driver connection lock) while a Rows.Next is in progress
(which does not tack the driver connection lock).
The current internal design of the sql package is each call takes
roughly two locks: a closemu lock which prevents an disposing of
internal resources (assigning nil or removing from lists)
and a driver connection lock that prevents calling driver code from
multiple goroutines.
Fixes#21117
Change-Id: Ie340dc752a503089c27f57ffd43e191534829360
Reviewed-on: https://go-review.googlesource.com/65731
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/71510
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Current code assumes that SetFileCompletionNotificationModes
is safe to call even if we know that it is not safe to use
FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag. It appears (see issue #22149),
SetFileCompletionNotificationModes crashes when we call it without
FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag.
Do not call SetFileCompletionNotificationModes in that situation.
We are allowed to do that, because SetFileCompletionNotificationModes
is just an optimisation.
Fixes#22149
Change-Id: I0ad3aff4eabd8c27739417a62c286b1819ae166a
Reviewed-on: https://go-review.googlesource.com/69870
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/70989
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
On an iPhone 6 running iOS 11, the TestDialerDualStackFDLeak test
started failing with dial durations just above the limit:
FAIL: TestDialerDualStackFDLeak (0.21s)
dial_test.go:90: got 101.154ms; want <= 95ms
Bump the timeout on iOS.
For the iOS builder.
Change-Id: Id42b471e7cf7d0c84f6e83ed04b395fa1a2d449d
Reviewed-on: https://go-review.googlesource.com/66491
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/70987
Run-TryBot: Russ Cox <rsc@golang.org>
Currently, the priority of checks in (gcTrigger).test() puts the
gcpercent<0 test above gcTriggerCycle, which is used for runtime.GC().
This is an unintentional change from 1.8 and before, where
runtime.GC() triggered a GC even if GOGC=off.
Fix this by rearranging the priority so the gcTriggerCycle test
executes even if gcpercent < 0.
Fixes#22023.
Change-Id: I109328d7b643b6824eb9d79061a9e775f0149575
Reviewed-on: https://go-review.googlesource.com/65994
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-on: https://go-review.googlesource.com/70979
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
When a MOVDstorezero (8 bytes) is used the offset field
in the instruction must be a multiple of 4. This situation
had been corrected in the rules for other types of stores
but not for the zero case.
This also removes some of the special MOVDstorezero cases since
they can be handled by the general LowerZero case.
Updates made to the ssa test for lowering zero moves to
include cases where the target is not aligned to at least 4.
Fixes#21947
Change-Id: I7cceceb1be4898c77cd3b5e78b58dce0a7e28edd
Reviewed-on: https://go-review.googlesource.com/64970
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/70978
Run-TryBot: Russ Cox <rsc@golang.org>
internal/poll package assumes that only net sockets use runtime
netpoller on windows. We get memory corruption if other file
handles are passed into runtime poller. Make FD.Init receive
and use useNetpoller argument, so FD.Init caller is explicit
about using runtime netpoller.
Fixes#21172
Change-Id: I60e2bfedf9dda9b341eb7a3e5221035db29f5739
Reviewed-on: https://go-review.googlesource.com/65810
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/71132
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
The previous code seems to have an off-by-1 in it somewhere, the
consequence being that we didn't properly preserve all of the old
buffer contents that we intended to.
After spending a while looking at the existing window-shifting logic,
I wasn't able to understand exactly how it was supposed to work or
where the issue was, so I rewrote it to be (at least IMO) more
obviously correct.
Fixes#21938.
Change-Id: I1ed7bbc1e1751a52ab5f7cf0411ae289586dc345
Reviewed-on: https://go-review.googlesource.com/64830
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-on: https://go-review.googlesource.com/70977
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The compiler replaces any path of the form /path/to/goroot/src/net/port.go
with GOROOT/src/net/port.go so that the same object file is
produced if the GOROOT is moved. It was skipping this transformation
for any absolute path into the GOROOT that came from //line directives,
such as those generated by cmd/cgo.
Fixes#21373Fixes#21720Fixes#21825
Change-Id: I2784c701b4391cfb92e23efbcb091a84957d61dd
Reviewed-on: https://go-review.googlesource.com/63693
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-on: https://go-review.googlesource.com/70975
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 36428 changed the way nanotime works so on Darwin and Windows it
now depends on runtime.startNano, which is computed at runtime.init
time. Unfortunately, the `runtimeInitTime = nanotime()` initialization
happened *before* runtime.init, so on these platforms runtimeInitTime
is set incorrectly. The one (and only) consequence of this is that the
start time printed in gctrace lines is bogus:
gc 1 18446653480.186s 0%: 0.092+0.47+0.038 ms clock, 0.37+0.15/0.81/1.8+0.15 ms cpu, 4->4->1 MB, 5 MB goal, 8 P
To fix this, this commit moves the runtimeInitTime initialization to
shortly after runtime.init, at which point nanotime is safe to use.
This also requires changing the condition in newproc1 that currently
uses runtimeInitTime != 0 simply to detect whether or not the main M
has started. Since runtimeInitTime could genuinely be 0 now, this
introduces a separate flag to newproc1.
Fixes#21554.
Change-Id: Id874a4b912d3fa3d22f58d01b31ffb3548266d3b
Reviewed-on: https://go-review.googlesource.com/58690
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/70848
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
golang.org/cl/36941 enabled loading of all trusted certs on darwin
for the non-cgo execSecurityRoots.
The corresponding cgo version golang.org/cl/36942 for systemRootsPool
has not been merged yet.
This tests fails reliably on some darwin systems:
--- FAIL: TestSystemRoots (1.28s)
root_darwin_test.go:31: cgo sys roots: 353.552363ms
root_darwin_test.go:32: non-cgo sys roots: 921.85297ms
root_darwin_test.go:44: got 169 roots
root_darwin_test.go:44: got 455 roots
root_darwin_test.go:73: insufficient overlap between cgo and non-cgo roots; want at least 227, have 168
FAIL
FAIL crypto/x509 2.445s
Updates #16532
Updates #21416
Change-Id: I52c2c847651fb3621fdb6ab858ebe8e28894c201
Reviewed-on: https://go-review.googlesource.com/57830
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-on: https://go-review.googlesource.com/70847
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
PlainAuth originally refused to send passwords to non-TLS servers
and was documented as such.
In 2013, issue #5184 was filed objecting to the TLS requirement,
despite the fact that it is spelled out clearly in RFC 4954.
The only possibly legitimate use case raised was using PLAIN auth
for connections to localhost, and the suggested fix was to let the
server decide: if it advertises that PLAIN auth is OK, believe it.
That approach was adopted in CL 8279043 and released in Go 1.1.
Unfortunately, this is exactly wrong. The whole point of the TLS
requirement is to make sure not to send the password to the wrong
server or to a man-in-the-middle. Instead of implementing this rule,
CL 8279043 blindly trusts the server, so that if a man-in-the-middle
says "it's OK, you can send me your password," PlainAuth does.
And the documentation was not updated to reflect any of this.
This CL restores the original TLS check, as required by RFC 4954
and as promised in the documentation for PlainAuth.
It then carves out a documented exception for connections made
to localhost (defined as "localhost", "127.0.0.1", or "::1").
Cherry-pick of CL 68170.
Change-Id: I1d3729bbd33aa2f11a03f4c000e6bb473164957b
Reviewed-on: https://go-review.googlesource.com/68210
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
All the finalizer-enabled C wrappers must be careful to use
runtime.KeepAlive to ensure the C wrapper object (a Go object)
lives through the end of every C call using state that the
wrapper's finalizer would free.
This CL makes the wrappers appropriately careful.
The test proves that this is the bug I was chasing in a
separate real program, and that the KeepAlives fix it.
I did not write a test of every possible operation.
Change-Id: I627007e480f16adf8396e7f796b54e5525d9ea80
Reviewed-on: https://go-review.googlesource.com/64870
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There's no way for a *.syso file to be compiled to work both in
normal mode and in msan mode. Assume they are compiled in
normal mode and drop them in msan mode.
Packages with syso files currently fail in -msan mode because
the syso file calls out to a routine like memcmp which then
falsely reports uninitialized memory. After this CL, they will fail
in -msan with link errors, because the syso will not be used.
But then it will at least be possible for package authors to write
fallback code in the package that avoids the syso in -msan mode,
so that the package with the syso can at least run in both modes.
Without this CL, that's not possible.
See #21884.
Change-Id: I77340614c4711325032484e65fa9c3f8332741d5
Reviewed-on: https://go-review.googlesource.com/63917
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The syso is not compiled with -fsanitize=memory, so don't try to use it.
Otherwise the first time it calls out to memcmp, memcmp complains
that it is being asked to compare uninitialized memory.
Change-Id: I85ab707cfbe64eded8e110d4d6b40d1b75f50541
Reviewed-on: https://go-review.googlesource.com/63916
Reviewed-by: Adam Langley <agl@golang.org>
I've now debugged multiple mysterious "inability to communicate"
bugs that manifest as a silent unexplained authentication failure but are
really crypto.AEAD.Open being invoked with badly aligned buffers.
In #21624 I suggested using a panic as the consequence of bad alignment,
so that this kind of failure is loud and clearly different from, say, a
corrupted or invalid message signature. Adding the panic here made
my failure very easy to track down, once I realized that was the problem.
I don't want to debug another one of these.
Also using this CL as an experiment to get data about the impact of
maybe applying this change more broadly in the master branch.
Change-Id: Id2e2d8e980439f8acacac985fc2674f7c96c5032
Reviewed-on: https://go-review.googlesource.com/63915
Reviewed-by: Adam Langley <agl@golang.org>
This matches the standard GenerateKey and more importantly Precompute,
so that if you generate a key and then store it, read it back, call Precompute
on the new copy, and then do reflect.DeepEqual on the two copies, they
will match. Before this CL, the original key had CRTValues == nil and the
reconstituted key has CRTValues != nil (but len(CRTValues) == 0).
Change-Id: I1ddc64342a50a1b65a48d827e4d564f1faab1945
Reviewed-on: https://go-review.googlesource.com/63914
Reviewed-by: Adam Langley <agl@golang.org>
When using the go command, test binaries end in .test,
but when using Bazel, test binaries conventionally end in _test.
Change-Id: Ic4cac8722fd93ae316169f87b321f68e0b71f0c3
Reviewed-on: https://go-review.googlesource.com/63913
Reviewed-by: Adam Langley <agl@golang.org>
In routines like GenerateKey, where bits from the randomness source have a
visible effect on the output, we bypass BoringCrypto if given a non-standard
randomness source (and also assert that this happens only during tests).
In the decryption paths, the randomness source is only for blinding and has
no effect on the output, so we unconditionally invoke BoringCrypto, letting it
use its own randomness source as it sees fit. This in turn lets us verify that
the non-BoringCrypto decryption function is never called, not even in tests.
Unfortunately, while the randomness source has no visible effect on the
decrypt operation, the decrypt operation does have a visible effect on
the randomness source. If decryption doesn't use the randomness source,
and it's a synthetic stream, then a future operation will read a different
position in the stream and may produce different output. This happens
in tests more often than you'd hope.
To keep behavior of those future operations unchanged while still
ensuring that the original decrypt is never called, this CL adds a
simulation of the blinding preparation, to discard the right amount
from the random source before invoking BoringCrypto.
Change-Id: If2f87b856c811b59b536187c93efa99a97721419
Reviewed-on: https://go-review.googlesource.com/63912
Reviewed-by: Adam Langley <agl@golang.org>
This is documented to work (in hash.Hash's definition)
and existing code assumes it works. Add a test.
Change-Id: I63546f3b2d66222683a4f268a4eaff835fd836fe
Reviewed-on: https://go-review.googlesource.com/63911
Reviewed-by: Adam Langley <agl@golang.org>
hmac.New returns a hash.Hash, which defines Sum as:
// Sum appends the current hash to b and returns the resulting slice.
// It does not change the underlying hash state.
Sum(b []byte) []byte
I've now seen two different pieces of code that make
use of the assumption that Sum has no effect on the
internal state, so make it so.
Test in next CL in stack, so that it can be cherry-picked
to master.
Change-Id: Iad84ab3e2cc12dbecef25c3fc8f2662d157b0d0b
Reviewed-on: https://go-review.googlesource.com/63910
Reviewed-by: Adam Langley <agl@golang.org>
The standard Go crypto/rsa allows signatures to be shorter
than the RSA modulus and assumes leading zeros.
BoringCrypto does not, so supply the leading zeros explicitly.
This fixes the golang.org/x/crypto/openpgp tests.
Change-Id: Ic8b18d6beb0e02992a0474f5fdb2b73ccf7098cf
Reviewed-on: https://go-review.googlesource.com/62170
Reviewed-by: Adam Langley <agl@golang.org>
Did not consider these fields being embedded or adopted
into structs defined in other packages, but that's possible too.
Refine the import path check to account for that.
Fixes 'go test -short golang.org/x/crypto/ssh' but also
adds a new test in internal/boring for the same problem.
Change-Id: Ied2d04fe2b0ac3b0a34f07bc8dfc50fc203abb9f
Reviewed-on: https://go-review.googlesource.com/62152
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
This is terrible but much simpler, cleaner, and more effective
than all the alternatives I have come up with.
Lots of code assumes that reflect.DeepEqual is meaningful
on rsa.PublicKey etc, because previously they consisted only of
exported meaningful fields.
Worse, there exists code that assumes asn1.Marshal can be
passed an rsa.PublicKey, because that struct has historically
matched exactly the form that would be needed to produce
the official ASN.1 DER encoding of an RSA public key.
Instead of tracking down and fixing all of that code
(and probably more), we can limit the BoringCrypto-induced
damage by ensliting the compiler to hide the new field
from reflection. Then nothing can get at it and nothing can
be disrupted by it.
Kill two birds with one cannon ball.
I'm very sorry.
Change-Id: I0ca4d6047c7e98f880cbb81904048c1952e278cc
Reviewed-on: https://go-review.googlesource.com/60271
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Test is in a separate CL for easier cherry-picking to master branch.
Change-Id: Ia4a9032892d2896332010fe18a3216f8c4a58d1c
Reviewed-on: https://go-review.googlesource.com/59770
Reviewed-by: Adam Langley <agl@golang.org>
The DWARF code is mishandling the case when the host object files
define multiple (distinct) symbols with the same name. They are mapped
to the same DWARF debug symbol, which then appears on the dwarfp
list multiple times, which then breaks the code that processes the list.
Detect duplicates and skip them, because that's trivial, instead of fixing
the underlying problem.
See #21566.
Change-Id: Ib5a34c891d7c15f4c7bb6239d8f31a1ec767b8bc
Reviewed-on: https://go-review.googlesource.com/57943
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
[This is a cherry-pick of CL 54090 to the 1.9 release branch.]
gc.Sysfunc must not be called concurrently.
We set up runtime routines used by the backend
prior to doing any backend compilation.
I missed the 387 ones; fix that.
Sysfunc should have been unexported during 1.9.
I will rectify that in a subsequent CL.
Fixes#21352
Change-Id: I485bb1867b46d8e5cf64bc820b8963576dc16174
Reviewed-on: https://go-review.googlesource.com/55970
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Using atomic.Value causes vet errors in code copying
PublicKey or PrivateKey structures. I don't think the errors
are accurate, but it's easier to work around them than
to change vet or change atomic.Value.
See #21504.
Change-Id: I3a3435c1fc664cc5166c81674f6f7c58dab35f21
Reviewed-on: https://go-review.googlesource.com/56671
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Because profile labels are copied from the goroutine into the tag
buffer by the signal handler, there's a carefully-crafted set of race
detector annotations to create the necessary happens-before edges
between setting a goroutine's profile label and retrieving it from the
profile tag buffer.
Given the constraints of the signal handler, we have to approximate
the true synchronization behavior. Currently, that approximation is
too weak.
Ideally, runtime_setProfLabel would perform a store-release on
&getg().labels and copying each label into the profile would perform a
load-acquire on &getg().labels. This would create the necessary
happens-before edges through each individual g.labels object.
Since we can't do this in the signal handler, we instead synchronize
on a "labelSync" global. The problem occurs with the following
sequence:
1. Goroutine 1 calls setProfLabel, which does a store-release on
labelSync.
2. Goroutine 2 calls setProfLabel, which does a store-release on
labelSync.
3. Goroutine 3 reads the profile, which does a load-acquire on
labelSync.
The problem is that the load-acquire only synchronizes with the *most
recent* store-release to labelSync, and the two store-releases don't
synchronize with each other. So, once goroutine 3 touches the label
set by goroutine 1, we report a race.
The solution is to use racereleasemerge. This is like a
read-modify-write, rather than just a store-release. Each RMW of
labelSync in runtime_setProfLabel synchronizes with the previous RMW
of labelSync, and this ultimately carries forward to the load-acquire,
so it synchronizes with *all* setProfLabel operations, not just the
most recent.
Change-Id: Iab58329b156122002fff12cfe64fbeacb31c9613
Reviewed-on: https://go-review.googlesource.com/57190
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The code was adding race.Errors to t.raceErrors before checking
Failed, but Failed was using t.raceErrors+race.Errors. We don't want
to change Failed, since that would affect tests themselves, so modify
the harness to not unnecessarily change t.raceErrors.
Updates #19851Fixes#21338
Change-Id: I483f27c68c340928f1cbdef160abc0a5716efb5d
Reviewed-on: https://go-review.googlesource.com/57151
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Cherry-pick CL 56890.
Normally 64-bit div/mod is turned into runtime calls on 32-bit
arch, but the front end leaves power-of-two constant division
and hopes the SSA backend turns into a shift or AND. The SSA rule is
(Mod64u <t> n (Const64 [c])) && isPowerOfTwo(c) -> (And64 n (Const64 <t> [c-1]))
But isPowerOfTwo returns true only for positive int64, which leaves
out 1<<63 unhandled. Add a special case for 1<<63.
Fixes#21517.
Change-Id: Ic91f86fd5e035a8bb64b937c15cb1c38fec917d6
Reviewed-on: https://go-review.googlesource.com/57070
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If we substitute a SHA1 implementation where the entirety of the
reading of the buffer is done in assembly (or C called from cgo),
then the race detector cannot observe the race.
Change to crc32 with a fake polynomial, in the hope that it will
always be handled by Go code, not optimized assembly or cgo calls.
Change-Id: I34e90b14ede6bc220ef686f6aef16b8e464b5cde
Reviewed-on: https://go-review.googlesource.com/56510
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Right now the package doesn't do anything useful, but it will.
This CL is about the machinery for building goboringcrypto_linux_amd64.syso
and then running the self-test and checking FIPS_mode from Go init.
Change-Id: I4ec0f5efaa88ccfb506b9818d24a7f1cbcc5a7d6
Reviewed-on: https://go-review.googlesource.com/55472
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
579120323f runtime: mapassign_* should use typedmemmove to update keys
380525598c all: remove some manual hyphenation
f096b5b340 runtime: mark activeModules nosplit/nowritebarrier
3e3da54633 math/bits: fix example for OnesCount64
9b1e7cf2ac math/bits: add examples for OnesCount functions
b01db023b1 misc/cgo/testsanitizers: also skip tsan11/tsan12 when using GCC
a279b53a18 reflect: document how DeepEqual handles cycles
909f409a8d doc: mention handling of moved GOROOT in 1.9 release notes
58ad0176ca doc: use better wording to explain type-aware completion
92dac21d29 doc: replace paid with commercial
9bb98e02de doc/1.9: add CL 43712, ReverseProxy of HTTP/2 trailers to the release notes.
78d74fc2cd doc: clarify that Gogland is for paid IntelliJ platform IDEs
5495047223 doc/1.9: fix broken html link in CL 53030/53210
890e0e862f doc: fix bad link in go1.9 release notes
be596f049a doc/1.9: fix stray html in CL 53030
0173631d53 encoding/binary: add examples for varint functions
ac0ccf3cd2 doc/1.9: add CL 36696 for crypto/x509 to the release notes
cc402c2c4d doc: hide blog content for golang.google.cn
f396fa4285 internal/poll: don't add non-sockets to runtime poller
664cd26c89 cmd/vet: don't exit with failure on type checking error
a8730cd93a doc: hide video and share if being served from CN
b63db76c4a testsanitizers: check that tsan program runs, skip tsan10 on gcc
193eda7291 time: skip ZoneAbbr test in timezones with no abbreviation
6f08c935a9 cmd/go: show examples with empty output in go test -list
f20944de78 cmd/compile: set/unset base register for better assembly print
623e2c4603 runtime: map bitmap and spans during heap initialization
780249eed4 runtime: fall back to small mmaps if we fail to grow reservation
31b2c4cc25 .github: add .md extension to SUPPORT file
ac29f30dbb plugin: mention that there are known bugs with plugins
45a4609c0a cmd/dist: skip moved GOROOT on Go's Windows builders when not sharding tests
e157fac02d test: add README
835dfef939 runtime/pprof: prevent a deadlock that SIGPROF might create on mips{,le}
df91b8044d doc: list editor options by name, not plugin name
3d9475c04b doc: cleanup editor page
b9661a14ea doc: add Atom to editor guide
ee392ac10c cmd/compile: consider exported flag in namedata
Change-Id: I3a48493e8c05d97cb3b61635503ef0ccd646e5cb
We lazily map the bitmap and spans areas as the heap grows. However,
right now we're very slightly too lazy. Specifically, the following
can happen on 32-bit:
1. mallocinit fails to allocate any heap arena, so
arena_used == arena_alloc == arena_end == bitmap.
2. There's less than 256MB between the end of the bitmap mapping and
the next mapping.
3. On the first allocation, mheap.sysAlloc sees that there's not
enough room in [arena_alloc, arena_end) because there's no room at
all. It gets a 256MB mapping from somewhere *lower* in the address
space than arena_used and sets arena_alloc and arena_end to this
hole.
4. Since the new arena_alloc is lower than arena_used, mheap.sysAlloc
doesn't bother to call mheap.setArenaUsed, so we still don't have a
bitmap mapping or a spans array mapping.
5. mheap.grow, which called mheap.sysAlloc, attempts to fill in the
spans array and crashes.
Fix this by mapping the metadata regions for the initial arena_used
when the heap is initialized, rather than trying to wait for an
allocation. This maintains the intended invariant that the structures
are always mapped for [arena_start, arena_used).
Fixes#21044.
Cherry-pick of CL 51714. Fixes#21234.
Change-Id: I4422375a6e234b9f979d22135fc63ae3395946b0
Reviewed-on: https://go-review.googlesource.com/52191
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Right now, if it's possible to grow the arena reservation but
mheap.sysAlloc fails to get 256MB more of memory, it simply fails.
However, on 32-bit we have a fallback path that uses much smaller
mmaps that could take in this situation, but fail to.
This commit fixes mheap.sysAlloc to use a common failure path in case
it can't grow the reservation. On 32-bit, this path includes the
fallback.
Ideally, mheap.sysAlloc would attempt smaller reservation growths
first, but taking the fallback path is a simple change for Go 1.9.
Updates #21044 (fixes one of two issues).
Cherry-pick of CL 51713. Updates #21234.
Change-Id: I1e0035ffba986c3551479d5742809e43da5e7c73
Reviewed-on: https://go-review.googlesource.com/52190
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It is possible to have an unexported name with a nil package,
for an embedded field whose type is a pointer to an unexported type.
We must encode that fact in the type..namedata symbol name,
to avoid incorrectly merging an unexported name with an exported name.
Fixes#21120
Change-Id: I2e3879d77fa15c05ad92e0bf8e55f74082db5111
Reviewed-on: https://go-review.googlesource.com/50710
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-on: https://go-review.googlesource.com/50970
Reviewed-by: Chris Broadfoot <cbro@golang.org>
2017-07-24 18:12:06 +00:00
2795 changed files with 61823 additions and 42640 deletions
checkFile=flag.String("c","","optional comma-separated filename(s) to check API against")
allowNew=flag.Bool("allow_new",true,"allow API additions")
exceptFile=flag.String("except","","optional filename of packages that are allowed to change without triggering a failure in the tool")
nextFile=flag.String("next","","optional filename of tentative upcoming API features for the next release. This file can be lazily maintained. It only affects the delta warnings from the -c file printed on success.")
verbose=flag.Bool("v",false,"verbose debugging")
forceCtx=flag.String("contexts","","optional comma-separated list of <goos>-<goarch>[-cgo] to override default contexts.")
checkFiles=flag.String("c","","optional comma-separated filename(s) to check API against")
requireApproval=flag.String("approval","","require approvals in comma-separated list of `files`")
allowNew=flag.Bool("allow_new",true,"allow API additions")
exceptFile=flag.String("except","","optional filename of packages that are allowed to change without triggering a failure in the tool")
nextFiles=flag.String("next","","comma-separated list of `files` for upcoming API features for the next release. These files can be lazily maintained. They only affects the delta warnings from the -c file printed on success.")
verbose=flag.Bool("v",false,"verbose debugging")
forceCtx=flag.String("contexts","","optional comma-separated list of <goos>-<goarch>[-cgo] to override default contexts.")
)
// contexts are the default contexts which are scanned, unless
@@ -125,10 +129,14 @@ var internalPkg = regexp.MustCompile(`(^|/)internal($|/)`)
funcmain(){
flag.Parse()
ifbuild.Default.GOROOT==""{
log.Fatalf("GOROOT not found. (If binary was built with -trimpath, $GOROOT must be set.)")
The //go:uintptrescapes directive must be followed by a function declaration.
It specifies that the function's uintptr arguments may be pointer values
that have been converted to uintptr and must be treated as such by the
garbage collector. The conversion from pointer to uintptr must appear in
the argument list of any call to this function. This directive is necessary
for some low-level system call implementations and should be avoided otherwise.
It specifies that the function's uintptr arguments may be pointer values that
have been converted to uintptr and must be on the heap and kept alive for the
duration of the call, even though from the types alone it would appear that the
object is no longer needed during the call. The conversion from pointer to
uintptr must appear in the argument list of any call to this function. This
directive is necessary for some low-level system call implementations and
should be avoided otherwise.
//go:noinline
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
