So next CL can use it for generating equal func during walk compare.
Passes toolstash-check.
Change-Id: I76545c1d471eb496be352908db1b05feae83fc33
Reviewed-on: https://go-review.googlesource.com/c/go/+/436435
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
NixOS has no /usr/share, but does have tzdata at /etc/zoneinfo.
Change-Id: Ic7d7f42a215e06c2e4f5c54ee11db82240f27167
GitHub-Last-Rev: 9969dd3e2c
GitHub-Pull-Request: golang/go#58267
Reviewed-on: https://go-review.googlesource.com/c/go/+/464995
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Logger.Log methods are called in a highly concurrent manner in many servers.
Acquiring a lock in each method call results in high lock contention,
especially since each lock covers a non-trivial amount of work
(e.g., formatting the header and outputting to the writer).
Changes made:
* Modify the Logger to use atomics so that the header formatting
can be moved out of the critical lock section.
Acquiring the flags does not occur in the same critical section
as outputting to the underlying writer, so this introduces
a very slight consistency instability where concurrently calling
multiple Logger.Output along with Logger.SetFlags may cause
the older flags to be used by some ongoing Logger.Output calls
even after Logger.SetFlags has returned.
* Use a sync.Pool to buffer the intermediate buffer.
This approach is identical to how fmt does it,
with the same max cap mitigation for #23199.
* Only protect outputting to the underlying writer with a lock
to ensure serialized ordering of output.
Performance:
name old time/op new time/op delta
Concurrent-24 19.9µs ± 2% 8.3µs ± 1% -58.37% (p=0.000 n=10+10)
Updates #19438
Change-Id: I091beb7431d8661976a6c01cdb0d145e37fe3d22
Reviewed-on: https://go-review.googlesource.com/c/go/+/464344
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This change intrinsifies ReverseBytes{16|32|64} by generating the
corresponding new instructions in Power10: brh, brd and brw and
adds a verification test for the same.
On Power 9 and 8, the .go code performs optimally as it is.
Performance improvement seen on Power10:
ReverseBytes32 1.38ns ± 0% 1.18ns ± 0% -14.2
ReverseBytes64 1.52ns ± 0% 1.11ns ± 0% -26.87
ReverseBytes16 1.41ns ± 1% 1.18ns ± 0% -16.47
Change-Id: I88f127f3ab9ba24a772becc21ad90acfba324b37
Reviewed-on: https://go-review.googlesource.com/c/go/+/446675
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This copies x/exp/maps into the standard library (except for the Clear
function which is now available as the clear builtin.)
Fixes#57436
Change-Id: I30dd470c2f7ae34c7c82b4c1025a7582d61fabaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/464343
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Since CL 454836, cmd/dist has built the packages in 'cmd' with
different settings than those in 'std': namely, for' cmd' we disable
the use of cgo, and (since CL 463740) if GO_BUILDER_NAME is non-empty
or the VERSION file indicates a release version we also set
GOFLAGS=-trimpath.
However, since at least CL 73212 the staleness checks performed by
cmd/dist for the “toolchain” targets (a subset of 'cmd') have included
the package "runtime/internal/sys" (which is in 'std', not 'cmd').
At that time, cmd/go did not have a separate build cache, so it would
not have been possible to check staleness for a 'cmd' build differently
from 'std'. However, now that is possible, and most of the time
"runtime/internal/sys" lives *only* in the build cache (and so is
essentially never stale after building anything that imports it).
But there is one more wrinkle: if GODEBUG=installgoroot=all is set,
the packages in 'std' are still installed to GOROOT/pkg, and can once
again become stale. Since the install with the 'std' configuration does
not match the configuration used to build 'cmd', the staleness check
fails for "runtime/internal/sys" under the 'cmd' configuration.
Since we intentionally build the toolchain with a different
"runtime/internal/sys" stored only in the build cache, there is no
longer a point in checking that package for staleness: if it is stale,
then the toolchain itself will be reported as stale anyway.
So we can simply remove the package from that staleness check,
and unbreak bootstrapping with GODEBUG=installgoroot=all.
I tested this manually using the sequence:
export GODEBUG=installgoroot=all
export GO_BUILDER_NAME=linux-amd64-bcmills
./make.bash
It fails the staleness check before this change, and successfully
builds after.
For #24904.
Change-Id: I376e93e35129694a093c6675e20905a097a8b64b
Reviewed-on: https://go-review.googlesource.com/c/go/+/465155
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Using generics here makes the code easier to understand,
as the contract is clearly specified. It also makes the
code a little more concise, as it's easy to write a wrapper
for the cache that adds an error value, meaning that
a bunch of auxilliary types no longer need to be defined
for this common case.
The load.cachingRepo code has been changed to use a separate
cache for each key-value type combination, which seems a bit less
sleazy, but might have some knock-on effect on memory usage,
and could easily be changed back if desired.
Because there's no longer an unambiguous way to find out
whether there's an entry in the cache, the Cache.Get method
now returns a bool as well as the value itself.
Change-Id: I28443125bab0b3720cc95d750e72d28e9b96257d
Reviewed-on: https://go-review.googlesource.com/c/go/+/463843
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: roger peppe <rogpeppe@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Enable new type inference and compare result with old inference
implementation - the result must be identical in a correct program.
Change-Id: Ic802d29fcee744f6f826d5e433a3d0c0e73b68e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/464341
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This change implements infer2 which is a drop-in replacement for
infer; it can be enabled by setting the useNewTypeInference flag
in infer2.go. It is currently disabled (but tested manually).
infer2 uses the same machinery like infer but in a simpler approach
that is more amenable to precise description and future extensions.
The goal of type inference is to determine a set of (missing) type
arguments from a set of other given facts. Currently, these other
facts are function arguments and type constraints.
In the following, when we refer to "type parameters", we mean the
type parameters defined by the generic function to which we apply
type inference. More precisely, in the algorithm, these are the
type parameters recorded with the unifier.
The approach is as follows:
- A single unifier is set up which tracks all type parameters and
corresponding inferred types.
- The unifier is then fed all the facts we have. The order is not
relevant (*) except that we use default types of untyped constant
arguments only as a last resort, at the end.
- We start with all function arguments: for each generic function
parameter with a typed function argument, we unify the parameter
and function type.
- We then unify each type parameter with its type constraint.
This step is iterated until nothing changes anymore, because
each unification may enable further unification.
- If there are any type parameters left without inferred types,
and which are used as function parameters with untyped constant
arguments, unify them with the default types of those arguments.
Because of unification with constraints which themselves may contain
type parameters, inferred types may contain type parameters. Thus,
in a final step we substitute type parameters for their inferred types
until there are no type parameters left in the inferred types.
All these individual steps are the same as in infer, but there is no
need to do constraint type inference twice (all the facts have already
been used for inference). Also, we only need a single unifier which
serves as the holder for the inferred type parameter types.
Type inference fails if any unification step fails or if not all
type arguments could be inferred. By always using all available
facts (**) we ensure that order doesn't matter.
By using more facts, type inference can now be extended to become
more powerful.
The code can be split up into smaller components that are more
easily digestable. Because we forsee more simplifications, we
defer such cleanups to later CLs.
(*) We currently have a sorting phase in the beginning such that
function argument types that are named types are used before
any other type. We believe this step can be eliminated by
modifying the unifier slightly.
(**) When unifying constraints, in some cases we don't report
an error if unification fails. We believe we can modify the
unifier and then consistently report an inference failure
in this case as well.
Change-Id: If1640a5461bc102fa7fd31dc6e741be667c97e7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463746
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Because unification is symmetric, in cases where we have symmetric
code for x and y depending on some property we can swap x and y as
needed and simplify the code.
Also, change u.depth increment/decrement position for slightly
nicer tracing ooutput.
Change-Id: I2e84570d463d1c32f6556108f3cb54062b57c718
Reviewed-on: https://go-review.googlesource.com/c/go/+/464896
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This makes it easier to configure the behavior of identical: we can
simply add fields to the comparer instead of adding more parameters
to identical.
Change-Id: I9a6f5451b3ee5c37e71486060653c5a6e8f24304
Reviewed-on: https://go-review.googlesource.com/c/go/+/464937
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Prior to CL 456116 we had an arbitrary 5-second delay after a test
times out before we kill the test. In CL 456116, I reused that
arbitrary 5-second delay as the WaitDelay as well, but on slower
builders it does not seem to be generous enough.
Instead of hard-coding the delay, for tests with a finite timout we
now use a hard-coded fraction of the overall timeout. That will
probably give delays that are longer than strictly necessary for very
long timeouts, but if the user is willing to wait for a very long
timeout they can probably wait a little longer for I/O too.
Fixes#58230.
Updates #24050.
Change-Id: Ifbf3e576c034c721aa00cd17bf88563474b09955
Reviewed-on: https://go-review.googlesource.com/c/go/+/464555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This test previously failed if running a new pthread took longer than
a hard-coded 100ms. On some slow or heavily-loaded builders, that
scheduling latency is too short.
Since the point of this test is to verify that the background thread
is not reused after it terminates (see #20395), the arbitrary time
limit does not seem helpful: if the background thread fails to
terminate the test will time out on its own, and if the main goroutine
is scheduled on the background thread the test will fail regardless of
how long it takes.
Fixes#58247.
Change-Id: I626af52aac55af7a4c0e7829798573c479750c20
Reviewed-on: https://go-review.googlesource.com/c/go/+/464735
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This operation converts a big.Int to float64,
reporting the accuracy of the result, with
a fast path in hardware.
Fixes#56984
Change-Id: I86d0fb0e105a06a4009986f2f5fd87a4d446f6f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/453115
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Alan Donovan <adonovan@google.com>
Instead, have the caller pass in an explicit list of the packages
(if any) they need.
After #47257, a builder running a test does not necessarily have the
entire standard library already cached, especially when running tests
in sharded mode. testenv.WriteImportcfg used to write an importcfg for
the entire standard library — which required rebuilding the entire
standard library — even though most tests need only a tiny subset.
This reduces the time to test internal/abi with a cold build cache on
my workstation from ~16s to ~0.05s.
It somewhat increases the time for 'go test go/internal/gcimporter'
with a cold cache, from ~43s to ~54s, presumably due to decreased
parallelism in rebuilding the standard library and increased overhead
in re-resolving the import map. However, 'go test -short' running time
remains stable (~5.5s before and after).
Fixes#58248.
Change-Id: I9be6b61ae6e28b75b53af85207c281bb93b9346f
Reviewed-on: https://go-review.googlesource.com/c/go/+/464736
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
This method returns the array updated by SetLines, for
use in exporter packages.
Fixes#57708
Change-Id: I12ed5e7e1bae7517f40cb25e76e51997c25d84f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/464515
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Alan Donovan <adonovan@google.com>
For a given Addr, ensure there is exactly one invalid representation.
This allows invalid representations to be safely comparable.
To ensure that the zero value of Prefix is invalid,
we modify the encoding of bits to simply be the bit count plus one.
Since Addr is immutable, we check in the PrefixFrom constructor that
the provided Addr is valid and only store a non-zero bits length if so.
IsValid is simplified to just checking whether bitsPlusOne is non-zero.
Fixes#54525
Change-Id: I9244cae2fd160cc9c81d007866992df2e422d3b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/425035
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
The default NodeJS V8 stack size is 984K, which is not enough to run
the regexp or go/parser tests. This commit increases the stack size
to 8192K, which removes the stack size limit error.
Fixes#56498Fixes#57614
Change-Id: I357885d420daf259187403deab25ff587defa0fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/463994
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Julien Fabre <ju.pryz@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Invert the meaning of the var to make use of the zero value.
Change-Id: If18db09896a67cb37cb3fe7dc0fb3493c6050a87
Reviewed-on: https://go-review.googlesource.com/c/go/+/463847
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
.go.buildinfo has no relocations anymore, as of Go 1.18.
Change-Id: I98369c6a0ef07ada770eaa12f6f56c210e812abc
Reviewed-on: https://go-review.googlesource.com/c/go/+/464436
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If you use an external linker with --gc-sections, nothing refers
to .go.buildinfo, so the section is deleted, which in turns makes
'go version' fail on the binary. It is important for vulnerability
scanning and the like to be able to run 'go version' on any binary.
Fix this by inserting a reference to .go.buildinfo from the rodata
section, which will not be GC'ed.
Fixes#58222.
Change-Id: I1e13e9464acaf2f5cc5e0b70476fa52b43651123
Reviewed-on: https://go-review.googlesource.com/c/go/+/464435
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
There's no need to invoke unifier.nify recursively when we decide to
unify underlying types. Just update the respective type variable and
continue.
Change-Id: I3abe335464786dc509d18651dff14b20022c7d63
Reviewed-on: https://go-review.googlesource.com/c/go/+/464347
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Neither infer nor infer2 will correctly work if we require
exact unification. Remove the flag and simplify the respective
code.
Change-Id: I329f207f72b6d97fa076f27275481b754e55fecf
Reviewed-on: https://go-review.googlesource.com/c/go/+/464346
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The runtime's knowledge of these constants was removed in CL 261364.
Change-Id: I65e5a5ab084c6301eee1c9791bc76df9b824e466
Reviewed-on: https://go-review.googlesource.com/c/go/+/463754
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Follow-up on CL 462856 which missed a few places.
Fixed manually.
Change-Id: I924560ecae8923d9228027016805a3cc892f8ac2
Reviewed-on: https://go-review.googlesource.com/c/go/+/463749
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
When coming from C, the bitwise integer complement (bitwise negation)
operator is ~, but in Go it is ^. Report an error mentioning ^ when
~ is used with an integer operand.
Background: Some articles on the web claim that Go doesn't have a
bitwise complement operator.
Change-Id: I41185cae4a70d528754e44f42c13c013ed91bf27
Reviewed-on: https://go-review.googlesource.com/c/go/+/463747
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Allocate all handles up-front: in a correct program, all type parameters
must be resolved and thus eventually will get a handle.
Also, sharing of handles caused by unified type parameters is rare and
so it's ok to not optimize for that case (and delay handle allocation).
This removes a (premature) optimization whis further simplifies
unification.
Change-Id: Ie1259b86ea5e966538667ab9557676e9be9f6364
Reviewed-on: https://go-review.googlesource.com/c/go/+/463989
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Further simplify the unifier by using a mapping from type parameter
to type (argument) handle, where a handle is just an indirection to
the actual type associated with the type parameter.
If multiple type parameters are "joined", i.e., share the same type
(argument), then they use the same handle. Thus, if one of the type
parameters gets a type, all type parameters sharing the same handle
get the same type.
The handles mapping replaces the indices list (mapping from type
parameter index to types index). Because each handle holds any
associated type directly, we also don't need a types list anymore.
We still keep the incoming type parameter list to maintain the same
order for printing and reporting inferred types. We may be able to
eliminate this list as well in future CLs.
Change-Id: I389527dbb325b828c91050e59902ae546c3d0347
Reviewed-on: https://go-review.googlesource.com/c/go/+/463228
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When scheduling a block, deprioritize values whose results aren't used
until subsequent blocks.
For #58166, this has the effect of pushing the induction variable increment
to the end of the block, past all the other uses of the pre-incremented value.
Do this only with optimizations on. Debuggers have a preference for values
in source code order, which this CL can degrade.
Fixes#58166Fixes#57976
Change-Id: I40d5885c661b142443c6d4702294c8abe8026c4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463751
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 463975 replaced the use of the NodeJS crypto.randomFillSync API
with a direct call to crypto.getRandomValues. This function rejects
any requests to fill a buffer larger than 65536 bytes, so we need to
batch reads larger than this size. This reuses the batching
functions used on other platforms to perform this batching.
Fixes#58145
Change-Id: Ic0acf3be7c9e994bc345d6614867c9b0c47bd26d
Reviewed-on: https://go-review.googlesource.com/c/go/+/463993
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Before CL 463992 there were some cases that cmd/dist did not test
but that platform.BuildModeSupport permitted. In CL 463992 those
conflicts were resolved in favor of platform.BuildModeSupport.
However, further testing has uncovered some cases that do not in
fact work. Adjust those in both cmd/dist and internal/platform.
In particular, mark android-arm and android-arm64 as not supporting
plugin mode. Sample failure:
https://build.golang.org/log/ebba858ea9f94f076966d8cfd42348a0e9345095
Mark ios as not supporting c-archive mode. Sample failure:
https://build.golang.org/log/e78a58189d94b90dc6d4b2e01a1b4a0b35d63792Fixes#58170Fixes#58172
Change-Id: Ic1bd18e36382cac0779aad48cb6e7b1de8eeb10d
Reviewed-on: https://go-review.googlesource.com/c/go/+/464339
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#58098
Change-Id: I6ef963ba2c110215b8eda763cbfb258a25c8199a
GitHub-Last-Rev: 3d22f076b7
GitHub-Pull-Request: golang/go#58143
Reviewed-on: https://go-review.googlesource.com/c/go/+/463987
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Ian Lance Taylor <iant@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>
This CL removes a fallback that used LoadLibraryA when the runtime
was loading system DLLs on Windows 7, Windows Server 2008 R2,
or earlier.
We can safely remove that fallback now, as go1.21 will require at least
Windows 8 or Server 2012.
This CL also saves some syscall initialization time and bytes:
new:
init syscall @2.3 ms, 0 ms clock, 1000 bytes, 18 allocs
old:
init syscall @3.6 ms, 0.52 ms clock, 1744 bytes, 24 allocs
Updates #57003
Change-Id: I7dcc1173537785b6b580e9f78632c0c74da658d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/463842
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
This reverts CL 463231.
Reason for revert: introduced a data race on darwin.
Fixes#58169.
Change-Id: I35f02273db38c257369c166547bb4945f92fdc3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/464375
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
fsys.Walk, like filepath.Walk, avoids traversing symlinks. Also like
filepath.Walk, it follows a symlink at the root if the root path ends
in a file separator (consistent with POSIX pathname resolution¹).
If the user's working directory is within a repository stored in
(and symlinked to) a different filesystem path, we want to follow the
symlink instead of treating the module as completely empty.
¹https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/basedefs/V1_chap04.html#tag_04_12Fixes#50807.
Updates #57754.
Change-Id: Idaf6168dfffafe879e05b4ded5fda287fcd3eeec
Reviewed-on: https://go-review.googlesource.com/c/go/+/463179
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Adding a file path separator is incorrect for a file path that may be
the root directory on a Unix platform (such as in a container or
chroot).
Adding a path separator is incorrect for a package path prefix that
may be the empty string (as in the "std" module in GOROOT/src).
And in both cases, a Join function is arguably clearer and simpler
anyway.
Fixes#51506 (maybe).
Change-Id: Id816930811ad5e4d1fbd206cddf219ecd4ad39a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/463178
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
