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>
(cherry picked from commit 7419bb3ebb)
Reviewed-on: https://go-review.googlesource.com/c/go/+/390816
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
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>
(cherry picked from commit d3070a767b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/390959
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
(cherry picked from commit 7dc6c5ec34)
Reviewed-on: https://go-review.googlesource.com/c/go/+/390419
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@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>
(cherry picked from commit 0807986fe6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/390015
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Robert Griesemer <gri@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>
(cherry picked from commit b0db2f00a0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/388918
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Merge List:
+ 2022-02-28 acc5f55bac cmd/go: make work and work_edit script tests version-independent
+ 2022-02-28 f04d5c118c cmd/internal/obj/riscv/testdata/testbranch: add //go:build lines
+ 2022-02-28 9fe3676bc7 all: fix typos
+ 2022-02-28 f9285818b6 go/types, types2: fix string to type parameter conversions
+ 2022-02-28 eb8198d2f6 cmd/compile: deal with constructed types that have shapes in them
+ 2022-02-28 b33592dcfd spec: the -'s possessive suffix is English, not code
+ 2022-02-28 57e3809884 runtime: avoid cgo_unsafe_args for syscall.syscall functions on darwin/arm64
+ 2022-02-28 06a43e4ab6 cmd/compile: fix case for structural types where we should be looking at typeparams
+ 2022-02-28 0907d57abf cmd/compile: emit types of constants which are instantiated generic types
+ 2022-02-28 9c4a8620c8 CONTRIBUTORS: update for the Go 1.18 release
+ 2022-02-28 57dda9795d test: add new test case for 51219 that triggers the types2 issue
+ 2022-02-26 a064a4f29a cmd/compile: ensure dictionary assignment statements are defining statements
+ 2022-02-26 286e3e61aa go/types, types2: report an error for x.sel where x is a built-in
+ 2022-02-25 01e522a973 go/types,types2: revert documentation for Type.Underlying
+ 2022-02-25 26999cfd84 runtime/internal/atomic: set SP delta correctly for 64-bit atomic functions on ARM
+ 2022-02-25 7c694fbad1 go/types, types2: delay receiver type validation
+ 2022-02-25 55e5b03cb3 doc/go1.18: note changes to automatic go.mod and go.sum updates
+ 2022-02-25 6d810241eb doc/go1.18: document minimum Linux kernel version
+ 2022-02-25 b8b3196375 doc/go1.18: document method set limitation for method selectors
+ 2022-02-24 c0840a7c72 go/types, types2: method recv type parameter count must match base type parameter count
+ 2022-02-24 c15527f0b0 go/types, types2: implement adjCoreType using TypeParam.is
+ 2022-02-24 5a9fc946b4 cmd/go: avoid +incompatible major versions if a go.mod file exists in a subdirectory for that version
+ 2022-02-24 4edefe9568 cmd/compile: delay all call transforms if in a generic function
+ 2022-02-24 8c5904f149 doc/go1.18: mention runtime/pprof improvements
+ 2022-02-24 b2dfec100a doc/go1.18: fix typo in AMD64 port section
+ 2022-02-24 78e99761fc go/types, types2: don't crash if comp. literal element type has no core type
+ 2022-02-23 e94f7df957 go/types, types2: generalize cleanup phase after type checking
+ 2022-02-23 163da6feb5 go/types, types2: add "dynamic" flag to comparable predicate
+ 2022-02-23 e534907f65 go/types: delete unnecessary slice construction
+ 2022-02-23 d0c3b01162 doc/go1.18: drop misplaced period
+ 2022-02-22 35170365c8 net: document methods of Buffers
+ 2022-02-22 3140625606 doc/go1.18: correct "go build -asan" HTML tag
+ 2022-02-22 d17b65ff54 crypto/x509, runtime: fix occasional spurious “certificate is expired”
+ 2022-02-21 c9fe126c8b doc/go1.18: fix a few small typos, add a few commas
+ 2022-02-20 851ecea4cc encoding/xml: embedded reference to substruct causes XML marshaller to panic on encoding
+ 2022-02-19 0261fa616a testdata: fix typo in comment
+ 2022-02-19 903e7cc699 doc/go1.18: fix grammar error
+ 2022-02-19 e002cf4df7 strings: fix typo in comment
+ 2022-02-18 61b5c866a9 doc/go1.18: document Go 1.17 bootstrap and //go:build fix
+ 2022-02-18 d27248c52f runtime: save some stack space for racecall on ARM64
+ 2022-02-18 d93cc8cb96 runtime: define racefuncenter and racefuncexit as ABIInternal
+ 2022-02-18 20b177268f reflect: call ABIInternal moveMakeFuncArgPtrs on ARM64
+ 2022-02-18 d35ed09486 cmd/compile: fix importers to deal with recursion through type constraints
+ 2022-02-16 eaf040502b os: eliminate arbitrary sleep in Kill tests
Change-Id: I74352b70d97c6fd4a45aee4e222160ea2a7854ae
The work and work_edit script tests ran go work init, which put the
current Go version into the go.work files. Before this change, the tests
used cmp to compare the outputs with a file that contained a literal
"go 1.18" line. Instead, use cmpenv so we can compare with
"go $goversion". (Some of the test cases still compare against files
that contain "go 1.18" lines, but these tests explicitly set the version
to go 1.18 either in the original go.work files or using go work edit.)
Change-Id: Iea2caa7697b5fe5939070558b1664f70130095ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/388514
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Converting an untyped constant to a type parameter results
in a non-constant value; but the constant must still be
representable by all specific types of the type parameter.
Adjust the special handling for constant-to-type parameter
conversions to also include string-to-[]byte and []rune
conversions, which are handled separately for conversions
to types that are not type parameters because those are not
constant conversions in non-generic code.
Fixes#51386.
Change-Id: I15e5a0fd281efd15af387280cd3dee320a1ac5e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/388254
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We convert type args to shape types inside instantiations. If an
instantiation constructs a compound type based on that shape type and
uses that as a type arg to another generic function being called, then
we have a type arg with a shape type embedded inside of it. In that
case, we need to substitute out those embedded shape types with their
underlying type.
If we don't do this, we may create extra unneeded shape types that
have these other shape types embedded in them. This may lead to
generating extra shape instantiations, and a mismatch between the
instantiations that we used in generating dictionaries and the
instantations that are actually called.
Updates #51303
Change-Id: Ieef894a5fac176cfd1415f95926086277ad09759
Reviewed-on: https://go-review.googlesource.com/c/go/+/387674
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, syscall.syscall-like functions are defined as
cgo_unsafe_args, which makes them ABI0, as it takes the address of
the argument area based on ABI0 layout. Those functions are
linkname'd to the syscall package. When compiling the syscall
package, the compiler doesn't know they are ABI0 therefore
generate an ABIInternal call, which will use the wrapper. As some
of the functions (e.g. syscall6) has many arguments, the wrapper
would take a good amount of stack space. And those functions must
be nosplit. This causes nosplit overflow when building with -N -l
and -race.
Avoid that by rewriting the functions to not use cgo_unsafe_args.
Instead, make a struct locally and pass the address of that
struct. This way the functions are ABIInternal and the call will
not use the wrapper.
Fixes#51247.
Change-Id: I76c1ab86b9d28664fa7d5b9c7928fbb2fd8d1417
Reviewed-on: https://go-review.googlesource.com/c/go/+/386719
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>
In getInstantiation, we were not computing tparams correctly for the
case where the receiver of a method was a fully-instantiated type. This
wasn't affecting later parts of the function, since method
instantiations of fully-instantiated types were already being calculated
in an earlier path. But it did give us a non-typeparam when trying to
see if a shape was associated with a type param with a structural type.
The fix is just to get the typeparams associated with the base generic
type. Then we can eliminate a conditional check later in the code.
The tparam parameter of Shapify should always be non-nil
Fixes#51367
Change-Id: I6f95fe603886148b2dad0c581416c51373c85009
Reviewed-on: https://go-review.googlesource.com/c/go/+/388116
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Normally types of constants are emitted when the type is defined (an
ODCLTYPE). However, the types of constants where the type is an
instantiated generic type made inside the constant declaration, do not
normally get emitted. But the DWARF processor in the linker wants
to see those types. So we emit them during stenciling.
Fixes#51245
Change-Id: I59f20f1d7b91501c9ac760cf839a354356331fc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/388117
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This update was created using the updatecontrib command:
go install golang.org/x/build/cmd/updatecontrib@latest
cd gotip
updatecontrib
With manual changes based on publicly available information
to canonicalize letter case and formatting for a few names.
For #12042.
Change-Id: If08b7e798cff6ec4248011bdadcc524b510aaff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388394
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
The existing test for 51219 didn't actually trigger the types2 issue - I
hadn't been able to minimize the test case yet properly. This new test
case issue51219b.go now does trigger the types2 issue (it's only
slightly different).
Updates #51219
Change-Id: Iaba8144b4702ff4fefec86c899b8acef127b10dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/387814
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
The problem in 51355 is that escape analysis decided that the
dictionary variable was captured by reference instead of by value. We
want dictionaries to always be captured by value.
Escape analysis was confused because it saw what it thought was a
reassignment of the dictionary variable. In fact, it was the only
assignment, it just wasn't marked as the defining assignment. Fix
that.
Add an assert to make sure this stays true.
Fixes#51355
Change-Id: Ifd9342455fa107b113f5ff521a94cdbf1b8a7733
Reviewed-on: https://go-review.googlesource.com/c/go/+/388115
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In case of a selector expression x.sel where x is a built-in
we didn't report an error because the type of built-ins is
invalid and we surpress errors on operands of invalid types,
assuming that an error has been reported before.
Add a corresponding check for this case.
Review all places where we call Checker.exprOrType to ensure
(invalid) built-ins are reported.
Adjusted position for index error in types2.
Fixes#51360.
Change-Id: I24693819c729994ab79d31de8fa7bd370b3e8469
Reviewed-on: https://go-review.googlesource.com/c/go/+/388054
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In the dev.typeparams branch, the documentation for Type.Underlying was
updated with commentary about forwarding chains. This aspect of
Underlying should not be exposed to the user. Revert to the
documentation of Go 1.16.
Fixes#51036
Change-Id: I4b73d3908a88606314aab56540cca91c014dc426
Reviewed-on: https://go-review.googlesource.com/c/go/+/388036
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>
64-bit atomic functions on ARM have the following structure:
- check if the address is 64-bit aligned, if not, prepare a frame
and call panicUnaligned
- tail call armXXX or goXXX depending on GOARM
The alignment check calls panicUnaligned after preparing a frame,
so the stack can be unwound. The call never returns, so the SP is
not set back. However, the assembler assigns SP delta following
the instruction stream order, not the control flow. So it leaves
a nonzero SP delta after the check, to the tail call instructions,
which is wrong because when they are executed the SP is not
decremented. This CL fixes this by adding the SP back (the
instruction never executes, just tells the assembler to set the
SP delta back).
Should fix#51353.
Change-Id: I976cb1cfb0e9008b13538765cbc7eea0c19c7130
Reviewed-on: https://go-review.googlesource.com/c/go/+/388014
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Delay validation of receiver type as it may cause premature expansion
of types the receiver type is dependent on. This was actually a TODO.
While the diff looks large-ish, the actual change is small: all the
receiver validation code has been moved inside the delayed function
body, and a couple of comments have been adjusted.
Fixes#51232.
Fixes#51233.
Change-Id: I44edf0ba615996266791724b832d81b9ccb8b435
Reviewed-on: https://go-review.googlesource.com/c/go/+/387918
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Check receiver type parameter count when type checking the method
signature and report a suitable error (don't rely on delayed
instantiation and possibly constraint type inference).
While at it, simplify blank name recoding and type bound rewriting.
Stop-gap measure to avoid crashes in the compiler.
Fixes#51339.
For #51343.
Change-Id: Idbe2d32d69b66573ca973339f8924b349d2bc9cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/387836
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TypeParam.is also provides ~ (tilde) information which is needed
to fix#51229. Delete all code related to singleType as it's not
used anymore.
Also, remove TypeParam.hasTerms as it was not used.
For #51229.
Change-Id: Ie49b19d157230beecb17a444d1f17cf24aa4f6ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/387774
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Previous versions of the 'go' command would reject a pseudo-version
passed to 'go get' if that pseudo-version had a mismatched major
version and lacked a "+incompatible" suffix. However, they would
erroneously accept a version *with* a "+incompatible" suffix even if
the repo contained a vN/go.mod file for the same major version, and
would generate a "+incompatible" pseudo-version or version if the user
requested a tag, branch, or commit hash.
This change uniformly rejects "vN.…" without "+incompatible", and also
avoids resolving to "vN.…+incompatible", when vN/go.mod exists.
To maintain compatibility with existing go.mod files, it still accepts
"vN.…+incompatible" if the version is requested explicitly as such
and the repo root lacks a go.mod file.
Fixes#51324
Updates #36438
Change-Id: I2b16150c73fc2abe4d0a1cd34cb1600635db7139
Reviewed-on: https://go-review.googlesource.com/c/go/+/387675
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
We changed to delaying all transforms of generic functions, since there
are so many complicated situations where type params can be used. We
missed changing so that all Call expressions(not just some) are delayed
if in a generic function. This changes to delaying all transforms on
calls in generic functions. Had to convert Call() to g.callExpr() (so we
can access g.delayTransform()). By always delaying transforms on calls
in generic functions, we actually simplify the code a bit both in
g.CallExpr() and stencil.go.
Fixes#51236
Change-Id: I0342c7995254082c4baf709b0b92a06ec14425e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/386220
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Use a cleanup method and simple registration mechanism
for types that need some final processing before the end
of type checking.
Use cleanup mechanism instead of expandDefTypes mechanism
for *Named types. There is no change in functionality here.
Use cleanup mechanism also for TypeParam and Interface types
to ensure that their check fields are nilled out at the end.
Introduce a simple constructor method for Interface types
to ensure that the cleanup method is always registered.
In go/types, add tracing code to Checker.checkFiles to match
types2.
Minor comment adjustments.
Fixes#51316.
Fixes#51326.
Change-Id: I7b2bd79cc419717982f3c918645af623c0e80d5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/387417
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>
A type implements a comparable interface only if the type
is statically known to be comparable. Specifically, a type
cannot contain (component) interfaces that are not statically
known to be comparable.
This CL adds a flag "dynamic" to the comparable predicate to
control whether interfaces are always (dynamically) comparable.
Set the flag to true when testing for (traditional) Go comparability;
set the flag to false when testing whether a type implements the
comparable interface.
Fixes#51257.
Change-Id: If22bc047ee59337deb2e7844b8f488d67e5c5530
Reviewed-on: https://go-review.googlesource.com/c/go/+/387055
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
As documented in #51209, we have been seeing a low-rate failure
on macOS builders caused by spurious x509 “certificate is expired” errors.
The root cause is that CFDateCreate takes a float64, but it is being
passed a uintptr instead. That is, we're not even putting CFDateCreate's
argument in the right register during the call. Luckily, having just
computed the argument by calling time.Duration.Seconds, which
returns a float64, most of the time the argument we want is still
in the right floating point register, somewhat accidentally.
The only time the lucky accident doesn't happen is when the goroutine
is rescheduled between calling time.Duration.Seconds and calling
into CFDateCreate *and* the rescheduling smashes the floating point
register, which can happen during various block memory moves,
since the floating point registers are also the SIMD registers.
Passing the float64 through explicitly eliminates the problem.
It is difficult to write a test for this that is suitable for inclusion
in the standard library. We will have to rely on the builders to
start flaking again if somehow this problem is reintroduced.
For future reference, there is a standalone test that used to fail
every few seconds at https://go.dev/play/p/OWfDpxgnW9g.
Fixes#51209.
Change-Id: I8b334a51e41f406b13f37270e9175c64fe6f55ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/387255
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When encoding a xml attribute is zero value (IsValid == false), we need
a `continue` to jump over the attribute. If not, followed marshalAttr
function will panic.
Fixes: #50164
Change-Id: I42e064558e7becfbf47728b14cbf5c7afa1e8798
Reviewed-on: https://go-review.googlesource.com/c/go/+/385514
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>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The code for issue #51219 reveals bugs in the types1 and types2
importers that can occur for recursive types that are recursive through
the type constraint.
The crash in the issue is caused by the types1 bug, which leads to the
production of a type1 type which is incomplete and improperly has the
HasTParam flag set. The bug in the types1 importer is that we were not
deferring type instantiations when reading the type parameters, but we
need to do that exactly to correctly handle recursion through the type
constraint. So, the fix is to move the start of the deferrals (in the
'U' section of doDecl in typecheck/iimport.go) above the code that reads
the type params.
Once that bug is fixed, the test still crashes due to a related types2
importer issues. The problem is that t.SetConstraint(c) requires c to be
fully constructed (have its underlying type set). Since that may not be
done yet in the 'U' case in (*importReader).obj() in
importer/iimport.go, we need to defer the call to SetConstraint() in
that case, until we are done importing all the types.
I added a test case with recursion through a type constraint that causes
a problem that is fixed by the types1 importer change, though the error
is not the same as in the issue. I added more types in the test case
(which try to imitate the issue types more closely) the types2 bug, but
wasn't able to cause it yet with the smaller test case.
Fixes#51219
Change-Id: I85d860c98c09dddc37f76ce87a78a6015ec6fd20
Reviewed-on: https://go-review.googlesource.com/c/go/+/386335
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The test spawned a subprocess that arbitrarily slept for one second.
However, on some platforms, longer than one second may elapse between
starting the subprocess and sending the termination signal.
Instead, the subprocess now closes stdout and reads stdin until EOF,
eliminating the need for an arbitrary duration. (If the parent test
times out, the stdin pipe will break, so the subprocess still won't
leak forever.)
This also makes the test much faster in the typical case: since it
uses synchronization instead of sleeping, it can run as quickly as the
host OS can start and kill the process.
Updates #44131.
Change-Id: I9753571438380dc14fc3531efdaea84578a47fae
Reviewed-on: https://go-review.googlesource.com/c/go/+/386174
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>
(cherry picked from commit eaf040502b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/386196
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The test spawned a subprocess that arbitrarily slept for one second.
However, on some platforms, longer than one second may elapse between
starting the subprocess and sending the termination signal.
Instead, the subprocess now closes stdout and reads stdin until EOF,
eliminating the need for an arbitrary duration. (If the parent test
times out, the stdin pipe will break, so the subprocess still won't
leak forever.)
This also makes the test much faster in the typical case: since it
uses synchronization instead of sleeping, it can run as quickly as the
host OS can start and kill the process.
Fixes#44131
Change-Id: I9753571438380dc14fc3531efdaea84578a47fae
Reviewed-on: https://go-review.googlesource.com/c/go/+/386174
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>
Prior to CL 339170, relative errors in module mode resulted in a
base.Fatalf from the module loader, which caused unrecoverable errors
from 'go list -e' but successfully rejected relative imports (which
were never intended to work in module mode in the first place).
After that CL, the base.Fatalf is no longer present, but some errors
that had triggered that base.Fatalf were no longer diagnosed at all:
the module loader left them for the package loader to report, and the
package loader assumed that the module loader would report them.
Since the module loader already knows that the paths are invalid,
it now reports those errors itself.
Fixes#51125
Change-Id: I70e5818cfcfeea0ac70e17274427b08a74fd7c13
Reviewed-on: https://go-review.googlesource.com/c/go/+/386176
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Otherwise, the behavior of a fuzz target that returns an error could
be confusing.
Fuzz is already documented to require a function “with no return
value”, so this fixes the implementation to match the existing
documentation.
Fixes#51222
Change-Id: I44ca7ee10960214c92f5ac066ac8484c8bb9cd6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/386175
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Nooras Saba <saba@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change removes the -workfile flag and allows the go.work file path
to be set using GOWORK (which was previously read-only). This removes
the potential discrepancy and confusion between the flag and environment
variable.
GOWORK will still return the actual path of the go.work file found if it
is set to '' or 'auto'. GOWORK will return 'off' if it is set to 'off'.
For #45713Fixes#51171
Change-Id: I72eed65d47c63c81433f2b54158d514daeaa1ab3
Reviewed-on: https://go-review.googlesource.com/c/go/+/385995
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
The existing value of 512 bytes as is specified by RFC 1035.
However, the WSL resolver reportedly sends larger packets without
setting the truncation bit, which breaks using the Go resolver.
For 1.18 and backports, just increase the accepted packet size.
This is what GNU glibc does (they use 65536 bytes).
For 1.19 we plan to use EDNS to set the accepted packet size.
That will give us more time to test whether that causes any problems.
No test because I'm not sure how to write one and it wouldn't really
be useful anyhow.
Fixes#6464Fixes#21160Fixes#44135Fixes#51127
For #51153
Change-Id: I0243f274a06e010ebb714e138a65386086aecf17
Reviewed-on: https://go-review.googlesource.com/c/go/+/386015
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts https://go.dev/cl/385035. For 1.18 we will use a simple
change to increase the accepted DNS packet size, to handle what appear
to be broken resolvers that don't honor the 512 byte limit. For 1.19
we will restore CL 385035 to make a proper EDNS request, so that it
has more testing time before it goes out in a release.
For #6464
For #21160
For #44135
For #51127
For #51153
Change-Id: Ie4a0eb85ca0a6a73bee5cd4cfc6b7d2a15ef259f
Reviewed-on: https://go-review.googlesource.com/c/go/+/386014
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
The go modules download command has a method called hashZip which checks the
hash of a zipped directory versus an expected value, and then writes it out
to a file. In the event that the write operation is not successful, we do
not close the file, leading to it being leaked. This could happen if the
user runs out of disk space, causing the underlying OS write command to
return an error. Ultimately, this led to a panic in lockfile.OpenFile which
was invoked from a finalizer garbage collecting the leaked file. The result
was a stack trace that didn't show the call stack from where the write
operation actually failed.
Fixes#50858
Change-Id: I4a24d2ab13dc903d623bbf8252b37bb9d724b8de
GitHub-Last-Rev: 354ef1d29e
GitHub-Pull-Request: golang/go#51058
Reviewed-on: https://go-review.googlesource.com/c/go/+/383915
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In issue 50113, we see that a thread blocked in a system call can result
in a hang of AllThreadsSyscall. To resolve this, we must send a signal
to these threads to knock them out of the system call long enough to run
the per-thread syscall.
Stepping back, if we need to send signals anyway, it should be possible
to implement this entire mechanism on top of signals. This CL does so,
vastly simplifying the mechanism, both as a direct result of
newly-unnecessary code as well as some ancillary simplifications to make
things simpler to follow.
Major changes:
* The rest of the mechanism is moved to os_linux.go, with fields in mOS
instead of m itself.
* 'Fixup' fields and functions are renamed to 'perThreadSyscall' so they
are more precise about their purpose.
* Rather than getting passed a closure, doAllThreadsSyscall takes the
syscall number and arguments. This avoids a lot of hairy behavior:
* The closure may potentially only be live in fields in the M,
hidden from the GC. Not necessary with no closure.
* The need to loan out the race context. A direct RawSyscall6 call
does not require any race context.
* The closure previously conditionally panicked in strange
locations, like a signal handler. Now we simply throw.
* All manual fixup synchronization with mPark, sysmon, templateThread,
sigqueue, etc is gone. The core approach is much simpler:
doAllThreadsSyscall sends a signal to every thread in allm, which
executes the system call from the signal handler. We use (SIGRTMIN +
1), aka SIGSETXID, the same signal used by glibc for this purpose. As
such, we are careful to only handle this signal on non-cgo binaries.
Synchronization with thread creation is a key part of this CL. The
comment near the top of doAllThreadsSyscall describes the required
synchronization semantics and how they are achieved.
Note that current use of allocmLock protects the state mutations of allm
that are also protected by sched.lock. allocmLock is used instead of
sched.lock simply to avoid holding sched.lock for so long.
Fixes#50113
Change-Id: Ic7ea856dc66cf711731540a54996e08fc986ce84
Reviewed-on: https://go-review.googlesource.com/c/go/+/383434
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>
Add a generic syscall package for use by the runtime. Eventually we'd
like to clean up system calls in the runtime to use more code generation
and be moved out of the main runtime package.
The implementations of the assembly functions are based on copies of
syscall.RawSyscall6, modified slightly for more consistency between
arches. e.g., renamed trap to num, always set syscall num register
first.
For now, this package is just the bare minimum needed for
doAllThreadsSyscall to make an arbitrary syscall.
For #51087.
For #50113.
Change-Id: Ibecb5e6303279ce15286759e1cd6a2ddc52f7c72
Reviewed-on: https://go-review.googlesource.com/c/go/+/383999
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
syscall_runtime_doAllThreadsSyscall is only used on Linux. In
preparation of a follow-up CL that will modify the function to use other
Linux-only functions, move it to os_linux.go with no changes.
For #50113.
Change-Id: I348b6130038603aa0a917be1f1debbca5a5a073f
Reviewed-on: https://go-review.googlesource.com/c/go/+/383996
Trust: Michael Pratt <mpratt@google.com>
Reviewed-by: Andrew G. Morgan <agm@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When line number saturates, we can end up getting non-monotonic
position info, because the start of the next line after line=lineMax,col=2
is line=lineMax,col=1.
Instead, if line==lineMax, make the column always 0 (no column info).
If the line number is wrong, having column info probably isn't that helpful.
Fixes#51193
Change-Id: If3d90472691b1f6163654f3505e2cb98467f2383
Reviewed-on: https://go-review.googlesource.com/c/go/+/385795
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Pointer comparison is lowered to the following on RISCV64
(EqPtr x y) => (SEQZ (SUB <x.Type> x y))
The difference of two pointers (the SUB) should not be pointer
type. Otherwise it can cause the GC to find a bad pointer.
Should fix#51101.
Change-Id: I7e73c2155c36ff403c032981a9aa9cccbfdf0f64
Reviewed-on: https://go-review.googlesource.com/c/go/+/385655
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously, TestNotTemporaryRead issued the Read on the Accept side of
the connection, and Closed the Dial side. It appears that on some
platforms, Dial may return before the connection has been Accepted,
and if that connection is immediately closed with no bytes written and
SO_LINGER set to 0, the connection may no longer even exist by the
time Accept returns, causing Accept to block indefinitely until the
Listener is closed.
If we were to just swap the directions, we would have an analogous
problem: Accept could accept the connection and close it before the
client even finishes dialing, causing Dial (instead of Read) to return
the ECONNRESET error.
Here, we take a middle path: we Accept and Dial the connection
concurrently, but wait until both the Accept and the Dial have
returned (indicating that the connection is completely established and
won't vanish from the accept queue) before resetting the connection.
Fixes#29685
Updates #25289
Change-Id: Ida06f70f7205fffcdafa3df78bd56184e6cec760
Reviewed-on: https://go-review.googlesource.com/c/go/+/385314
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Compiler errors now (as of 1.18) might start with a tab character,
for errors which take multiple lines to report. e.g.:
/Users/khr/gowork/tmp1.go:3:15: x redeclared in this block
/Users/khr/gowork/tmp1.go:3:8: other declaration of x
This CL makes error lines starting with a tab character
eligible for replacing absolute paths with relative ones.
Fixes#51177
Change-Id: Ic9e9c610a1aa1e21e9f19e6a9bd05c73b5a14e4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/385755
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
When we receive an error writing the first byte of a request to a
reused connection, we retry the request on a new connection. Remove
a flaky path which could cause the request to not be retried if
persistConn.roundTrip reads the error caused by closing the connection
before it reads the write error that caused the connection to be
closed.
Fixes#30938.
Change-Id: Iafd99e3239cd9dba4a4c9ddd950a877ca9815e59
Reviewed-on: https://go-review.googlesource.com/c/go/+/379554
Trust: Bryan Mills <bcmills@google.com>
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a follow up to CL 385494. In early patch sets of that CL,
renamed type parameters were substituted in arguments, which meant that
they could leak into the inference results. However, we subsequently
realized that we could instead substitute in the signature parameters.
In this case it is not possible for the substituted type parameters to
appear in the resulting type arguments, so there is no need to
un-substitute.
Change-Id: I4da45b0b8d7ad809d0ddfa7061ae5f6f07895540
Reviewed-on: https://go-review.googlesource.com/c/go/+/385574
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>
The (temporary) highlights will make it easier to review the spec
in formatted form as opposed to html text.
Added a missing rule about the use of adjusted core types for
constraint type inference.
Adjusted rule for invalid embedding of interface types.
Change-Id: Ie573068d2307b66c937e803c486724175415b9c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/385535
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Type inference uses type parameter pointer identity to keep track of the
correspondence between type parameters and type arguments. However, this
technique can misidentify type parameters that are used in explicit type
arguments or function arguments, as in the recursive instantiation
below:
func f[P *Q, Q any](p P, q Q) {
f[P]
}
In this example, the fact that the P used in the instantation f[P] has
the same pointer identity as the P we are trying to solve for via
unification is coincidental: there is nothing special about recursive
calls that should cause them to conflate the identity of type arguments
with type parameters. To put it another way: any such self-recursive
call is equivalent to a mutually recursive call, which does not run into
any problems of type parameter identity. For example, the following code
is equivalent to the code above.
func f[P interface{*Q}, Q any](p P, q Q) {
f2[P]
}
func f2[P interface{*Q}, Q any](p P, q Q) {
f[P]
}
We can turn the first example into the second example by renaming type
parameters in the original signature to give them a new identity. This
CL does this for self-recursive instantiations.
Fixes#51158Fixes#48656
Updates #48619
Change-Id: I54fe37f2a79c9d98950cf6a3602335db2896dc24
Reviewed-on: https://go-review.googlesource.com/c/go/+/385494
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>
This change adds tests that use a type parameter's core type during
function argument type inference, not just during constraint type
inference.
Also, fix a typo in a comment.
For #50755.
Change-Id: I0c3196bdce5338341e0b6dfd7c63efb2e43ace25
Reviewed-on: https://go-review.googlesource.com/c/go/+/385376
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
NOTE: Should this change cause problems, the new functionality
can be disabled by setting the flag enableCoreTypeUnification
in unify.go to false.
In the code
func f1[M1 map[K1]int, K1 comparable](m1 M1) {}
func f2[M2 map[K2]int, K2 comparable](m2 M2) {
f1(m2)
}
type inference attempts to unify the types of m1 and m2. This leads
to the unification attempt of M1 and M2. The result is that the type
argument for M1 is inferred to be M2. Since there is no furter function
argument to use, constraint type inference attempts to infer the type
for K1 which is still missing. Constraint type inference (inferB in
the trace below) compares the inferred type for M1 (i.e., M2) against
map[K1]int. M2 is bound to f2, not f1; with the existing algorithm
that means M2 is simply a named type without further information.
Unification fails and with that type inference, and the type checker
reports an error.
-- inferA [M1₁, K1₂] ➞ []
M1₁ ≡ M2₃
. M1₁ ➞ M2₃
-- inferB [M1₁, K1₂] ➞ [M2₃, <nil>]
M1₁ ➞ M2₃
M1₁ ≡ map[K1₂]int
. M2₃ ≡ map[K1₂]int
. M2₃ ≢ map[K1₂]int
M1₁ ≢ map[K1₂]int
=> inferB [M1₁, K1₂] ➞ []
=> inferA [M1₁, K1₂] ➞ []
With this change, when attempting to unify M2 with map[K1]int,
rather than failing, the unifier now considers the core type of
M2 which is map[K2]int. This leads to the unification of K1 and
K2; so type inference successfully infers M2 for M1 and K2 for K1.
-- inferA [M1₁, K1₂] ➞ []
M1₁ ≡ M2₃
. M1₁ ➞ M2₃
-- inferB [M1₁, K1₂] ➞ [M2₃, <nil>]
M1₁ ➞ M2₃
M1₁ ≡ map[K1₂]int
. M2₃ ≡ map[K1₂]int
. . core M2₃ ≡ map[K1₂]int
. . map[K2₄]int ≡ map[K1₂]int
. . . K2₄ ≡ K1₂
. . . . K1₂ ➞ K2₄
. . . int ≡ int
=> inferB [M1₁, K1₂] ➞ [M2₃, K2₄]
=> inferA [M1₁, K1₂] ➞ [M2₃, K2₄]
The fix for this issue was provided by Rob Findley in CL 380375;
this change is a copy of that fix with some additional changes:
- Constraint type inference doesn't simply use a type parameter's
core type. Instead, if the type parameter type set consists of
a single, possibly named type, it uses that type. Factor out the
existing code into a new function adjCoreType. This change is not
strictly needed but makes it easier to think about the code.
- Tracing code is added for debugging type inference. All tracing
code is guarded with the flag traceEnabled which is set to false
by default.
- The change to the unification algorithm is guarded with the flag
enableCoreTypeUnification.
- The sprintf function has a new type switch case for lists of
type parameters. This is used for tracing output (and was also
missing for a panic that was printing type parameter lists).
Fixes#50755.
Change-Id: Ie50c8f4540fcd446a71b07e2b451a95339b530ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/385354
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>
If an invalid array length is just an identifier, mention
"array length" so that it's clear this is an invalid array
declaration and not a (invalid) generic type declaration.
Fixes#51145.
Change-Id: I8878cbb6c7b1277fc0a9a014712ec8d55499c5c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/385255
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>
With the switch to the register ABI, we now generate wrapper
functions for go statements in many cases. A new goroutine's start
PC now points to the wrapper function. This does not affect
execution, but the runtime tracer uses the start PC and the
function name as the name/label of that goroutine. If the start
function is a named function, using the name of the wrapper loses
that information. Furthur, the tracer's goroutine view groups
goroutines by start PC. For multiple go statements with the same
callee, they are grouped together. With the wrappers, which is
context-dependent as it is a closure, they are no longer grouped.
This CL fixes the problem by providing the underlying unwrapped
PC for tracing. The compiler emits metadata to link the unwrapped
PC to the wrapper function. And the runtime reads that metadata
and record that unwrapped PC for tracing.
(This doesn't work for shared buildmode. Unfortunate.)
TODO: is there a way to test?
Fixes#50622.
Change-Id: Iaa20e1b544111c0255eb0fc04427aab7a5e3b877
Reviewed-on: https://go-review.googlesource.com/c/go/+/384158
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 test has failed on four different builders in the past month.
Moreover, because every Go program depends on "runtime", it is likely
to be run any time a user runs 'go test all' in their own program.
Since the test is known to be flaky, let's skip it to avoid
introducing testing noise until someone has time to investigate. It
seems like we have enough samples in the builder logs to at least
start with.
For #50979
Change-Id: I9748a82fbb97d4ed95d6f474427e5aa6ecdb023d
Reviewed-on: https://go-review.googlesource.com/c/go/+/385154
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change moves the relevant prose of the section on type parameters
into the section on type parameter lists and eliminates the former.
With this change, the section on types now exclusively describes all
Go composite types.
User-defined named types (defined types and type parameters) are
described with their declarations.
Change-Id: I3e421cd236e8801d31a4a81ff1e5ec9933e3ed20
Reviewed-on: https://go-review.googlesource.com/c/go/+/385037
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also, fixed several closing header tags and removed a duplicate "the".
(Thanks to @hopehook and Hossein Zolfi for pointing these out.)
Change-Id: I85a40ba44b8570a578bce8d211dcc5ea3901fb1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/385036
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The outcome of type inference depends critically on when function
argument type inference stops processing arguments. Describe this
and explain an example with some detail.
Also: In the section on the built-in function delete, refer to the
value rather than the type of the second argument, as it may be an
untyped constant.
Change-Id: Ice7fbb33f985afe082380b8d37eaf763238a3818
Reviewed-on: https://go-review.googlesource.com/c/go/+/385034
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A basic interface is a classical Go interface containing only
methods or embedding basic interfaces.
Use this to simplify rule about what interfaces may be used
where. The term "basic interface" will also be useful when
talking about various interfaces in general.
Fix rule restricting union terms: as it was written it also
excluded interface terms with non-empty method sets due to
embedded non-interface types with methods.
Split the large section on interfaces into three smaller
pieces by introducing section titles.
Change-Id: I142a4d5609eb48aaa0f7800b5b85c1d6c0703fcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/384994
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>
This change only shuffles sections for better organization; there
are no other changes except title and link adjustments.
Until now, the sections on underlying types and method sets were
immediately following the introduction of types. As it becomes
necessary to introduce the notion of a core type more centrally,
the natural place is immediately following the section on underlying
types. All together, these sections, immediately after the introduction
of types, would distract from purpose of the section on types, which
is to introduce the various types that Go offers.
The more natural place for the definition of underlying, core, and
specific types is the section on properties of types and values.
To accomplish this, the section on the structure of interfaces is
split into a section on core types and one on specific types, and
the various sections are reorganized appropriately.
The new organization of the section on types now simply introduces
all Go types as follows:
- boolean types
- numeric types
- string types
- array types
- slice types
- struct types
- pointer types
- function types
- interface types
- map types
- channel types
- type parameters
The new organization of the section on properties of types and values
is as follows:
- underlying types
- core types
- specific types
- type identity
- assignability
- representability
- method sets
Change-Id: I59e4d47571da9d4c89d47d777f5353fb1c5843e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/384623
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In workspace mode, if a user lists a package or patternthat's inside a
module that's not listed in go.work, mention that the package or pattern
is outside the modules listed in go.work so the user has a better idea
of how to fix the issue.
(Question: it's valid in those flows to add a pattern that points into
the module cache. Should we expand the error to say "package outside
modules listed in go.work file or contained in module cache"? That seems
clunky (and is the uncommon case) which is why I didn't do so in this
case, but it's possible)
Fixes#49632
Change-Id: I3f0ea1b2f566d52a8079b58593fcc5cc095e7a41
Reviewed-on: https://go-review.googlesource.com/c/go/+/384236
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If something goes horribly wrong with the assumptions surrounding a
piController, its internal error state might accumulate in an unbounded
manner. In practice this means unexpected Inf and NaN values.
Avoid this by identifying cases where the error overflows and resetting
controller state.
In the scavenger, this case is much more likely. All that has to happen
is the proportional relationship between sleep time and estimated CPU
usage has to break down. Unfortunately because we're just measuring
monotonic time for all this, there are lots of ways it could happen,
especially in an oversubscribed system. In these cases, just fall back
on a conservative pace for scavenging and try to wait out the issue.
In the pacer I'm pretty sure this is impossible. Because we wire the
output of the controller to the input, the response is very directly
correlated, so it's impossible for the controller's core assumption to
break down.
While we're in the pacer, add more detail about why that controller is
even there, as well as its purpose.
Finally, let's be proactive about other sources of overflow, namely
overflow from a very large input value. This change adds a check after
the first few operations to detect overflow issues from the input,
specifically the multiplication.
No tests for the pacer because I was unable to actually break the
pacer's controller under a fuzzer, and no tests for the scavenger because
it is not really in a testable state.
However:
* This change includes a fuzz test for the piController.
* I broke out the scavenger code locally and fuzz tested it, confirming
that the patch eliminates the original failure mode.
* I tested that on a local heap-spike test, the scavenger continues
operating as expected under normal conditions.
Fixes#51061.
Change-Id: I02a01d2dbf0eb9d2a8a8e7274d4165c2b6a3415a
Reviewed-on: https://go-review.googlesource.com/c/go/+/383954
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The "block" helpers in TestBlockProfile previously slept for an
arbitrary duration and assumed that that duration was long enough for
the parent goroutine to have registered as blocking. However —
especially on slow or overloaded builders — the current arbitrary
duration is sometimes not quite long enough.
Rather than increasing the duration to a different arbitrary value
(which would make the test slower but not actually eliminate the
possibility of flakes!), we can use the runtime's own accounting to
detect when the goroutine is actually blocked: we obtain a goroutine
dump from the runtime, and assume that blocking has been registered in
the profile only if the runtime shows the test goroutine in the
appropriate blocked state.
That not only makes the test more reliable, but also makes it
significantly lower-latency when run on a fast machine.
Fixes#6999Fixes#37844
Change-Id: I465ed2afd406fd2b621419e1f06925f283525f25
Reviewed-on: https://go-review.googlesource.com/c/go/+/384534
Trust: Bryan Mills <bcmills@google.com>
Trust: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The regexp code assumes it can recurse over the structure of
a regexp safely. Go's growable stacks make that reasonable
for all plausible regexps, but implausible ones can reach the
“infinite recursion?” stack limit.
This CL limits the depth of any parsed regexp to 1000.
That is, the depth of the parse tree is required to be ≤ 1000.
Regexps that require deeper parse trees will return ErrInternalError.
A future CL will change the error to ErrInvalidDepth,
but using ErrInternalError for now avoids introducing new API
in point releases when this is backported.
Fixes#51112.
Change-Id: I97d2cd82195946eb43a4ea8561f5b95f91fb14c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/384616
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There was an off-by-one error in the time histogram buckets calculation
that caused the linear sub-buckets distances to be off by 2x.
The fix was trivial, but in writing tests I realized there was a much
simpler way to express the calculation for the histogram buckets, and
took the opportunity to do that here. The new bucket calculation also
fixes the bug.
Fixes#50732.
Change-Id: Idae89986de1c415ee4e148f778e0e101ca003ade
Reviewed-on: https://go-review.googlesource.com/c/go/+/380094
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
This is a pure rename of the respective Go functions/methods
with corresponding adjustments to error messages and tests.
A couple of comments were manually rephrased.
With this change, the implementation and error messages match
the latest spec.
No functionality change.
Change-Id: Iaa92a08b64756356fb2c5abdaca5c943c9105c96
Reviewed-on: https://go-review.googlesource.com/c/go/+/384618
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The latter is subject to kern.maxfilelimit restrictions on darwin which
are not reflected in the return value. This makes it difficult to
reliably restore the default after the test is complete. RLIMIT_CPU
should hopefully sidestep this problem.
Updates #40564.
Change-Id: Ifb33c7d46f2708130cef366dc245c643a2d5e465
Reviewed-on: https://go-review.googlesource.com/c/go/+/383234
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: Bryan Mills <bcmills@google.com>
Trust: Bryan Mills <bcmills@google.com>
This change in terminology prevents potential confusion
that migth be caused by associating "structural type"
with "structural typing"; the two are not connected.
Also, adjusted introductory paragraph of section on
constraint type inference: type inference goes in both
directions, from type parameter to core type and vice
versa. The previous description was not quite accurate.
Change-Id: If4ca300f525eea660f68486302619aa6ad5dbc2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/384238
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If the actual DNS lookup in LookupIPAddr completes quickly enough,
it may succeed even if the passed-in Context is already canceled.
That would (rarely) cause TestLookupContextCancel to fail due to an
unexpectedly-nil error.
This change uses the existing testHookLookupIP hook to delay the
cancellation until the lookup has started (to try to provoke the code
path for which the test was added), and then block the lookup result
until LookupIPAddr has noticed it.
Fixes#51084
Updates #22724
Change-Id: I331ac61a652ac88f6d4c85bf62466237b76d53ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/384237
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>
Since a String method cannot return an error, escape fields that may
contain unsanitized values, and unescape them during parsing.
Add a fuzz test to verify that calling the String method on any
BuildInfo returned by Parse produces a string that parses to the same
BuildInfo. (Note that this doesn't ensure that String always produces
a parseable input: we assume that a user constructing a BuildInfo
provides valid paths and versions, so we don't bother to escape those.
It also doesn't ensure that ParseBuildInfo accepts all inputs that
ought to be valid.)
Fixes#51026
Change-Id: Ida18010ce47622cfedb1494060f32bd7705df014
Reviewed-on: https://go-review.googlesource.com/c/go/+/384154
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
CL 383554 disables testing cgo internal linking on all ARM64 but
Windows, because it doesn't work with newer GCC. But
- darwin-arm64 works, and it does not use GCC
- we don't support cgo internal linking on windows-arm64 anyway.
This CL fixes the condition.
Change-Id: I9eb7b81ef75e482f5e95d2edae4863ba21396432
Reviewed-on: https://go-review.googlesource.com/c/go/+/384269
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Document that AssertableTo is undefined (at least for 1.18) if
the first argument is a generalized interface; i.e., an interface
that may only be used as a constraint in Go code.
Still, implement it as we might expect it to be defined in the
future, to prevent problems down the road due to Hyrum's Law.
While at it, also removed the internal flag forceStrict and its
one use in Checker.assertableTo; forceStrict was never enabled
and if it would have been enabled, the behavior would not have
been correct.
Change-Id: Ie4dc9345c88d04c9640f881132154a002db22643
Reviewed-on: https://go-review.googlesource.com/c/go/+/383917
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
CL 337350 changed mp.fastrand from a [2]uint32 to a uint64 and changed
the initialization to a single call of int64Hash. However, int64Hash
returns uintptr, so 32-bit systems this always left the most
significant 32 bits of mp.fastrand initialized to 0. The new code also
did not protect against initializing mp.fastrand to 0, which on a
system that does not implement math.Mul64 (most 32-bit systems) would
lead fastrand to always return 0.
This CL restores the mp.fastrand initialization to what it was before
CL 337350, adjusted for the change from [2]uint32 to uint64.
Change-Id: I663b415d9424d967e8e665ce2d017604dcd5b204
Reviewed-on: https://go-review.googlesource.com/c/go/+/383916
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The terms "integer type", "floating-point type", and "complex type"
are used frequently in the spec but are not explicitly (only indirectly)
defined.
Slightly rephrased the section on numeric types and introduce these
terms explicitly. Add links to this section.
Change-Id: I3fb888933bece047da8b356b684c855618e9aee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/384157
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
go:embed disallows using symlinked files by design.
crypto/elliptic is the first std package to use it as of CL 380475,
and unfortunately that broke the TestRepeatBootstrap long test.
The reason it uses symlinks is for speed; it wants to copy GOROOT/src,
but regular files aren't going to be modified in any way,
so a symlink, if supported, means not needing to copy the contents.
Replace the symlink attempt with hard links,
which will mean regular files remain as such, fixing go:embed.
It's worth noting that on many systems hard links won't work,
as the temporary filesystem tends to be separate,
but it doesn't hurt to try.
In my system, where /tmp is tmpfs, the test now copies more bytes.
With the added Logf, I can see overlayDir goes from ~30ms to ~100ms.
This makes sense, as GOROOT/src currently weighs around 100MiB.
To alleviate that slow-down, stop copying testdata directories,
as they currently weigh around 20MiB and aren't needed for the test.
This gets overlayDir on my system down to an acceptable ~70ms.
I briefly considered teaching overlayDir what files can be symlinks,
but that seemed fairly complex long-term, as any file could be embedded.
While here, start using testing.T.TempDir and fs.WalkDir.
For #50995.
Change-Id: I17947e6bdee96237e1ca0606ad0b95e7c5987bc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/383995
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
go.dev/cl/339591 changed the code generation to use a constant string,
so that the ~88KiB table can be marked read-only.
The compiled code became a lot better, but unfortunately,
the generated Go source became significantly more inefficient.
The numbers below compare "gofmt -l" and "go tool compile" of said file,
where "old" is the file as of Go 1.17, and "new" as of master in 2022/01/19:
name old time/op new time/op delta
Gofmt 22.8ms ± 6% 898.5ms ± 3% +3837.32% (p=0.000 n=8+8)
GoToolCompile 26.9ms ± 2% 371.1ms ± 2% +1278.36% (p=0.000 n=7+8)
name old user-time/op new user-time/op delta
Gofmt 25.7ms ±65% 897.1ms ± 3% +3383.86% (p=0.000 n=8+8)
GoToolCompile 35.1ms ±26% 367.2ms ± 3% +945.80% (p=0.000 n=8+8)
name old sys-time/op new sys-time/op delta
Gofmt 6.42ms ±276% 7.23ms ±38% ~ (p=0.412 n=8+6)
GoToolCompile 9.20ms ±100% 13.90ms ±53% ~ (p=0.105 n=8+8)
name old peak-RSS-bytes new peak-RSS-bytes delta
Gofmt 9.11MB ± 7% 22.79MB ± 1% +150.23% (p=0.000 n=8+8)
GoToolCompile 25.1MB ± 2% 68.6MB ± 2% +173.57% (p=0.000 n=8+8)
"+" operators are binary expressions at the syntax tree level,
which are represented by packages like go/ast as roughly:
struct {
X Expr
Op Token
Y Expr
}
Since each node is a pointer, chains of "+" operators act like linked lists.
The generated code has about 14k lines, and 8 "+" operators per line,
meaning that we end up with a linked list with over 11k elements.
This explains the slow-down in gofmt; the printer must walk said list,
and it does so more than once to work out how to format it.
It seems like the compiler is similarly affected by the huge length.
To remedy the effect of the linked list, use go:embed instead.
This results in the same string variable with the binary table,
but it greatly reduces the amount of syntax and its cost above.
We still keep the generator around, but modified so it produces the
binary file to be embedded rather than a large Go file.
Finally, we update go/build/deps_test.go to allow crypto/elliptic to
depend on embed; it's a tiny package and crypto/elliptic was already
manually embedding assets via code generation.
The change to deps_test.go was briefly discussed in the issue below.
Fixes#50995.
Change-Id: I0c8b432710e971a296a2e9c99147cc2cad9662aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/380475
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Declare receiver type parameters in the function scope, but don't
resolve them (for now), as ast.Object.Decl is not documented to hold
*ast.Idents. This avoids incorrect resolution of identifiers to names
outside the function scope.
Also make tracing and error reporting more consistent.
For golang/go#50956
Change-Id: I8cd61dd25f4c0f6b974221599b00e23d8da206a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/382247
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>
Due to delayed computation of constraint type sets it is possible that
a type argument is checked against a constraint before that constraint
has been wrapped into an implicit interface (if needed).
When the type checker is about to check whether a type argument
implements a constraint, it's always safe to force wrapping of
a constraint in an implicit interface (if necessary) before doing
the implements check.
Also, use a better position for tracing output related to constraint
type set computation.
Fixes#51048.
Change-Id: I52fecbf57814f09b62762452d7e17c2a230fdd59
Reviewed-on: https://go-review.googlesource.com/c/go/+/383834
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
These tests use a slice to represent the base C compiler command (with
flags). Appending to that slice can cause subtle aliasing bugs, such
as commands that silently corrupt the arguments of other concurrent
commands in parallel tests.
In this change, we explicitly reduce the capacity of the command slice
to force appends to it to always allocate unique new slices.
Fixes#49693
Change-Id: Ide466bf65f12cb6cead3dcba69f513cccb60a160
Reviewed-on: https://go-review.googlesource.com/c/go/+/383754
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>
Change run.go to apply the GO_TEST_TIMEOUT_SCALE scaling factor to
test timeouts (mentioned in "-t" clause in test header).
Also with this patch, bump up the timeout for fixedbugs/issue46234.go
from 30 to 45 seconds, to avoid flakes on very slow builders.
Updates #50973.
Change-Id: Icbafa482860e24cc1e72fee53511bcc764d06bf1
Reviewed-on: https://go-review.googlesource.com/c/go/+/382774
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>
The previous workaround for issue #39466 only disabled this test for
Linux. However, the issue manifests for all arm64 systems with gcc 9.4
and above. The new netbsd-arm64 builder uses NetBSD-current with gcc
10.3, so it fails in the same way.
Updates #39466
Change-Id: I276a99a5e60914e5c22f74a680e461bea17cfe92
Reviewed-on: https://go-review.googlesource.com/c/go/+/383554
Trust: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Further simplify and regularize Checker.missingMethod and use the
same code in both type checkers.
This enables case-folding lookup for go/types.
Adjusted test case that looks for alternative methods.
Change-Id: I5b8cc598c295c329ff93b1c65787cc6140f0900e
Reviewed-on: https://go-review.googlesource.com/c/go/+/382858
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Remove special case where we don't have a *Checker and always use
Checker.missingMethodReason in Checker.implements.
Look for zero methods rather than empty interface to exit early
from Checker.missingMethod, and remove the extra test in
Checker.implements.
With this change we get consistent and more detailed error messages
from all places where we do a form of the "implements" test.
To make this possible, allow for the receiver to be nil in
- Checker.sprintf
- Checker.missingMethodReason
- Checker.interfacePtrError
- Checker.funcString
Allowing Checker.sprintf with nil Checker permits further simplifying
in a couple of places.
Change-Id: I0ea7178c9efbcd4a25ded2a66e2b058db52dc4d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/383054
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
- Remove the xtyp argument from the Checker.typeAssertion parameter
list; it was confusing and not needed. Adjusted call sites.
- Simplify logic in Checker.typeAssertion.
- Use the same code in both types2 and go/types, specifically
use the same error positions.
- Adjust error messages as needed.
This removes another subtle discrepancy between types2 and go/types.
The go/types error messages don't have the have/want appendix for
the affected error messages yet because we don't use case folding
in lookups yet.
Change-Id: Id39f5c473da36c9baad60082f85cf1f34dc26c50
Reviewed-on: https://go-review.googlesource.com/c/go/+/383014
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Added a funcString helper so we don't need to rewrite strings
with strings.Replace.
Use compiler format for error message about wrong method type;
this removes another unnecessary variation.
Simplify conditions for pointer-to-interface related error:
if one of the involved types is an interface pointer, it can't
have any methods.
Rewrite logic so we don't need all the else-if branches.
Adjusted a test case for types2 accordingly. The go/types version
of this test case has a different error because the implementation
of Checker.typeAssertion is different in the two type checkers
(the types2 version gives errors closer to the 1.17 compiler).
Change-Id: I19e604d7063c3e31e8290bd78384a9f38bb0d740
Reviewed-on: https://go-review.googlesource.com/c/go/+/382694
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Because Checker.missingMethod also looks up methods matching
matching case-folded names, when Checker.missingMethod returns
an alternative method, that method does not automatically have
the wrong type. It may be a method with a different name.
Adjust types2.MissingMethod to check the alternative method
name before reporting a wrong type.
Add API test that verifies (now correct) behavior for this
case.
Ported the code also to go/types, though it was not a bug
there yet because looking up with case-folding is not yet
enabled.
Change-Id: Iaa48808535c9265a9879338ea666c6c021e93a2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/382634
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
There is no need to check for length equality of type parameter
lists in Checker.missingMethod: the Identical predicate does
this check. Furthermore, we don't have methods with their own
type parameters. Remove the unnecessary (duplicate) code.
Also, update doc string on missingMethod and rename the 2nd
result parameter for clarity, and clarify internal comments.
For go/types, include the same case-folding code as for types2
but leave it disabled or now. Adjust any other differences in
the missingMethod implementation.
With this change, the types2 and go/types code of missingMethod
is identical again except for the disabled case-folding lookup.
No functionality changes.
Preparation for fixing some of the outstanding error reporting issues.
Change-Id: I4778d006c17f4e084ecc2cac7386c68e86aa49eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/382614
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
types2 has some code to handle case-folding when doing method lookups
which was missing in go/types. This change is a first step to match
the implementations. Specifically:
In types2:
- remove the lookupMethodFold names in favor of just lookupMethod,
but with the foldCase flag (e.g., instead if lookupMethodFold,
we just use lookupMethod)
- rename checkFold to foldCase everywhere
- add foldCase parameter where it was missing
- moved foldCase paremeter to the end in lookupFieldOrMethod
- no functionality changes
In go/types:
- match function signatures with types2 use
- always provide false as argument for foldCase for now
- no functionality changes
Preparation for fixing some of the outstanding error reporting issues.
Change-Id: If129a5feb89ddf96a3596e8d73b23afa591875a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/382461
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Refactor Checker.comparison such that its logic is easier to reason
about and so that special cases can be handled more directly.
Use the appropriate operand (of 1st or 2nd operand) for error
reporting (position and type), rather than always using the
first operand.
Use an extra parameter to indicate a switch case
comparison; in this case the error is always reported at
the position of the first operand. (The error messages are
not yet adjusted for switches; see next CL.)
Introduce a new kindString function which is used to print simplified
types in error messages (related to comparisons only): instead of
printing the details of a struct type, we just print "struct" where
the details are not relevant. This matches the 1.17 compiler behavior.
Added a "reportf" parameter to the internal comparable function so we
can report an error cause in addition to the boolean result. Rather
than passing a *string for cause, we pass a function to record the
cause so that we can use the *Checker context for printing (needed
for proper type qualification). This mechanism reports the same
details now as the 1.17 compiler.
Adjusted various tests as needed added new test files.
Fixes#50918.
Change-Id: I1f0e7af22f09db4d31679c667c71a9038a8dc9d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/381964
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In bespoke build environments default libraries may be specificied with
LIBRARY_PATH, C_INCLUDE_PATH enviroment variables to overide the system
(i.e glibc). Allow them though to allow cgo testing of these enviroments.
Fixes#50985
Change-Id: I7497a7715d9b635a6ae97efaab94a7ff01cdf8e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/383334
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The go/parser package is updated to report an error on method type
parameters, and to not store them in the AST. Tests are updated
accordingly, and error messages are normalized accross go/parser and the
compiler syntax package.
Before this CL, go/parser would parse type parameters on method
declarations and interface methods, leaving it to go/types to complain.
There are several problems with this:
- Interface Methods and Method declarations do not have type parameters
in the spec. We try to align the parser with the productions in the
spec.
- Parsing method type parameters means that downstream libraries
(go/doc, go/format, etc.) theoretically need to handle them, even
though they are not part of the language.
- Relatedly, go/types has inconsistent handling of method type
parameters due to support being removed, leading to the crasher in
#50427.
It is more consistent and safer to disallow type parameters on methods
in the parser.
Fixes#50427
Change-Id: I555766da0c76c4cf1cfe0baa9416863088088b4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/382538
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>
Add a regression test for issue 50936 which coerces the runtime into
frequent execution of the cgocall dropg/execute curg assignment race by
making many concurrent cgo calls eligible for P retake by sysmon. This
results in no P during exitsyscall, at which point they will update curg
and will crash if SIGPROF arrives in between updating mp.curg and
mp.curg.m.
This test is conceptually similar to the basic cgo callback test in
aprof.go but with additional concurrency and a sleep in C.
On my machine this test fails ~5% of the time prior to CL 382079.
For #50936.
Change-Id: I21b6c7f2594f9a615a64580ef70a88b692505678
Reviewed-on: https://go-review.googlesource.com/c/go/+/382244
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This failure mode has been present since at least 2020-06-08. We have
enough information to diagnose it, and further failures don't seem to
be adding any new information at this point: they can only add noise,
both on the Go project's builders and in users' own modules (for
example, when run as part of 'go test all').
For #39457
Change-Id: I2379631da0c8af69598fa61c0cc5ac0ea6ba8267
Reviewed-on: https://go-review.googlesource.com/c/go/+/382395
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>
Since at least CL 121857, the conversion logic in
(*modfetch).codeRepo.Stat has had a short-circuit to use the version
requested by the caller if it successfully resolves and is already
canonical.
However, we should not use that version if it refers to a branch
instead of a tag, because branches (unlike tags) usually do not refer
to a single, stable release: a branch named "v1.0.0" may be for the
development of the v1.0.0 release, or for the development of patches
based on v1.0.0, but only one commit (perhaps at the end of that
branch — but possibly not even written yet!) can be that specific
version.
We already have some logic to prefer tags that are semver-equivalent
to the version requested by the caller. That more general case
suffices for exact equality too — so we can eliminate the
special-case, fixing the bug and (happily!) also somewhat simplifying
the code.
Fixes#35671
Updates #41512
Change-Id: I2fd290190b8a99a580deec7e26d15659b58a50b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/378400
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 2nd phase of function argument type inference we only
consider parameters with types that are single type parameters.
Thus there is no need to collect anything else in the first
phase.
This matches the algorithm description in the forthcoming spec
more closely.
Change-Id: Ie5c29f30ff43b1e37d719ecbe1688b50ed2177f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/381554
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Looking at the condition actually exercised by the test it seems
unnecessary: assuming that the Write succeeds (checked earlier in the
test), the Read must have a nonzero number of bytes available to read
immediately. (That is not the case in TestUDPZeroByteBuffer, from
which this test appears to have been derived.)
Fixes#50870
Change-Id: Ia6040a2d5dc320f0b86ec9d6f6b91dc72e8f3b84
Reviewed-on: https://go-review.googlesource.com/c/go/+/382537
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>
Add a panicAtUnificationDepthLimit const to replace the use of the debug
const to control whether to panic when the unification recursion depth
is reached. Our tests should pass when debug==true.
Change-Id: I58847f49d66010bd4ca01c0408ec10acac95cba6
Reviewed-on: https://go-review.googlesource.com/c/go/+/382534
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>
We had been statting 'dir' instead of 'absDir', which statted the
wrong directory if 'dir' was made relative to the location of the
go.work file and that location was different from the current working
directory.
While we're here, I also noticed some other dir-vs.-absDir
discrepancies. The haveDirs map had assumed relative, slash-separated
filesystem paths, but absolute paths on Windows are not
slash-separated and we do retain those. Moreover, if users hand-edit
the go.work file they may introduce non-canonical paths.
I have changed the haveDirs logic to retain absolute paths in their
platform-specific forms, and to call DropUse with the original path
from the go.work file instead of the newly-resolved path.
Fixes#50931
Updates #48257
Change-Id: Ib0a46179aa20c99f045aac5c7c02dbb55da455c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/382240
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This makes the error case pointed out in the issue like the current
message in Go 1.17 or -G=0 mode. The priority is to point out the
similar but wrong method name, rather than a difference in type.
Made changes to both cmd/compile/internal/types2 and go/types.
Added in a missing tab in an error message in go/types.
At the same time, removed the extra "at info" on the have lines (and
pointer receiver lines) of error messages, as requested in #50907.
Fixes#50816Fixes#50907
Change-Id: I04f8151955bdb6192246cbcb59adc1c4b8a2c4e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/381774
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When loading the corpus, if the cache contained an entry which was a
duplicate of an entry added using f.Add, coordinator.addCorpusEntries
would return early, ignoring everything after this entry in the cache.
Instead, skip duplicates as intended, and continue to load the rest of
the cache.
Fixes#50913
Change-Id: I3a64b93cbb217c5c364a9f8d0005752e9e9d10ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/381960
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts commit CL 358900.
Adding _TraceJumpStack to cgo traceback exposed a crashing condition.
This CL was primarily a cleanup, so we revert it entirely for now
and follow-up with the VDSO and libcall parts later.
Fixes#50936.
Change-Id: Ie45c9caaa8e2ef5bc9498ba65c36c887ca821bf7
Reviewed-on: https://go-review.googlesource.com/c/go/+/382079
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
- Use the correct predicate in Checker.implements: for interfaces
we cannot use the API Comparable because it always returns true
for all non-type parameter interface types: Comparable simply
answers if == and != is permitted, and it's always been permitted
for interfaces. Instead we must use Interface.IsComparable which
looks at the type set of an interface.
- When comparing interfaces for identity, we must also consider the
whether the type sets have the comparable bit set.
With this change, `any` doesn't implement `comparable` anymore. This
only matters for generic functions and types, and the API functions.
It does mean that for now (until we allow type-constrained interfaces
for general non-constraint use, at some point in the future) a type
parameter that needs to be comparable cannot be instantiated with an
interface anymore.
For #50646.
Change-Id: I7e7f711bdcf94461f330c90509211ec0c2cf3633
Reviewed-on: https://go-review.googlesource.com/c/go/+/381254
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The configuration set by x/build/cmd/releasebot causes runtime/cgo to
be stale in the darwin/amd64 release (see #36025, #35459).
That staleness is mostly benign because we can reasonably assume that
users on macOS will either disable CGO entirely or have a C compiler
installed to rebuild (and cache) the stale packages if needed.
Fixes#50892Fixes#50893
Updates #46347
Change-Id: Ib9ce6b5014de436264238f680f7ca4ae02c9a220
Reviewed-on: https://go-review.googlesource.com/c/go/+/381854
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This method is unused and was not discussed in the API
proposals. Note that all error output goes through the
local sprintf which handles arguments specially.
Fixes#50760.
Change-Id: Iae66b0253cc0ece037d3d280951dc2d223c119fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/381634
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Where we provide it we take it from the Checker (which is already
passed in). Thus there's no need to pass it separately. Cleanup.
Change-Id: I63ae445ccac5643235d85e1867462ef5c01ad5fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/381297
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Now that we have the detailed error reporting in Checker.implements
we don't need it anymore in operand.assignableTo and can simply call
Checker.implements. This also more directly matches the spec.
For #50646.
Change-Id: Ic44ced999c75be6cc9edaab01177ee0495147ea1
Reviewed-on: https://go-review.googlesource.com/c/go/+/381435
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL copies (and adjusts as needed) the logic for error reporting
from operand.assignableTo to Checker.implements in the case of a missing
method failure and assignment to an interface pointer.
Preparation for using Checker.implements in operand.assignableTo
rather than implementing the same logic twice.
This also leads to better errors from Checker.implements as it's
using the same logic we already use elsewhere.
For #50646.
Change-Id: I199a1e02cf328b222ae52c10131db871539863bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/381434
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This patch reworks the handling of the DWARF DW_AT_bit_offset and
DW_AT_data_bit_offset attributes to resolve problems arising from
a previous related change (CL 328709).
In CL 328709 the DWARF type reader was updated to look for and use
the DW_AT_data_bit_offset attribute for structure fields, handling
the value of the attribute in the same way as for DW_AT_bit_offset.
This caused problems for clients, since the two attributes have very
different semantics.
This CL effectively reverts CL 328709 and moves to a scheme in which
we detect and report the two attributes separately/independently.
This patch also corrects a problem in the DWARF type reader in the
code that detects and fixes up the type of struct fields corresponding
to zero-length arrays; the code in question was testing the
DW_AT_bit_offset attribute value but assuming DW_AT_data_bit_offset
semantics, meaning that it would fail to fix up cases such as
typedef struct another_struct {
unsigned short quix;
int xyz[0];
unsigned x:1;
long long array[40];
} t;
The code in question has been changed to avoid using BitOffset and
instead consider only ByteOffset and BitSize.
Fixes#50685.
Updates #46784.
Change-Id: Ic15ce01c851af38ebd81af827973ec49badcab6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/380714
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Interface method receivers are synthetic: they record either the
interface type or the the defined type for which they are the RHS of the
type declaration. When instantiating, we need to update these receivers
accordingly.
Fixes#50839
Change-Id: Icd8e1a2817b0135059d25d034b01b0ff5207641f
Reviewed-on: https://go-review.googlesource.com/c/go/+/381174
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>
For a composite literal expression like []T{{f: 1}}, we allow T to be
a pointer to struct type, so it's consistent to allow T to also be a
type parameter whose structural type is a pointer to struct type.
Fixes#50833.
Change-Id: Ib0781ec4a4f327c875ea25b97740ff2c0c86b916
Reviewed-on: https://go-review.googlesource.com/c/go/+/381075
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Adds an addCorpusEntry method to coordinator which manages checking for
duplicate entries, writing entries to the cache directory, and adding
entries to the corpus. Also moves readCache to be a method on the
coordinator.
Fixes#50606
Change-Id: Id6721384a2ad1cfb4c5471cf0cd0a7510d250a6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/360394
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add a missing shape check in (*Tsubster).tinter when substituting on a
generic type which is an empty interface, analogous to same check in
(*Tsubster).tstruct. Empty structs/interfaces that have rparams (i.e.
are a generic type or a shape type) need to get a new type of their
rparams - they will be different even though they don't have any
fields/methods. Without this shape check, we were not correctly
completing the Token[int] type during substitution in the example in the
issue. This issue only happens for a generic type which is an empty
interface (i.e. doesn't actually use the type param, hence quite unusual).
Added the test case already created by Keith.
Fixes#50841
Change-Id: Ia985b9f52c0e87ed0647b46373e44c51cb748ba4
Reviewed-on: https://go-review.googlesource.com/c/go/+/381175
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This CL updates unified IR to look at the structural type of a
composite literal type, rather than merely the underlying type, to
determine if it's a structure. This fixes a number of currently
failing regress test cases.
Updates #50833.
Change-Id: I11c040c77ec86c23e8ffefcf1ce1aed548687dc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/381074
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This method isn't available in go/types, and its use by unified IR is
non-essential. This CL refactors reader2.go to avoid using it and then
removes the method.
Change-Id: I813c93a062c43292bb6760686ef91df5219534a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/380834
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
'go list' has its own internal parallelism, so invoking in in parallel
can produce up to quadratic peak memory usage.
Running 'go list' is also very I/O-intensive, so the higher
parallelism does substantially improve latency; unfortunately, we lack
a good way to balance latency against memory footprint, so we need to
sacrifice some latency for reliability.
Fixes#49957.
Change-Id: Ib53990b46acf4cc67a9141644d97282964d6442d
Reviewed-on: https://go-review.googlesource.com/c/go/+/380994
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
C archives for packages in GOROOT are shipped along with binary
releases of the Go toolchain. Although we build the toolchain with
GOROOT_FINAL set, we don't know actually know where the release will
be installed: the user's real GOROOT can differ arbitrarily from our
GOROOT_FINAL.
(In the specific case of toolchains installed through golang.org/dl
wrappers, the release's GOROOT_FINAL is /usr/local/go but the actual
GOROOT to which the release is installed is
$HOME/sdk/$(go env GOVERSION).)
Fixes#50183
Updates #48319
Change-Id: If10a42f90c725300bbcb89c3b5b01a2d93ab6ef7
Reviewed-on: https://go-review.googlesource.com/c/go/+/380915
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>
The test previously checked that the DWARF DW_AT_comp_dir attribute
matched GOROOT_FINAL. However, on further consideration, we believe
that DW_AT_comp_dir should not actually match GOROOT_FINAL: the DWARF
spec says that DW_AT_comp_dir records “the current working directory
of the compilation command that produced this compilation unit”, but
the actual working directory of the compilation command proper is a
throwaway directory in the build cache — it is neither stable nor
meaningful.
However, the test was getting at a real issue that we do care about:
namely, that the binary produced by a 'go build' command with cgo
enabled should not reuse a dependency that embeds a stale
GOROOT_FINAL.
This change refactors the test to verify the latter property instead
of checking DW_AT_comp_dir specifically.
For #50183
Updates #48319
Change-Id: I0b1151d9ba3d0ff903f72e27850306406e5cb518
Reviewed-on: https://go-review.googlesource.com/c/go/+/380914
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>
Update the vendored x/tools to pick up CL 380014, which updates the
ifaceassert vet analyzer to remove spurious errors for assertions
involving interfaces with type parameters.
This also picks up some superficial changes related to refactoring of
the x/tools/internal/typeparams API.
The following commands were used:
go get -d golang.org/x/tools@master
go mod tidy
go mod vendor
Fixes#50658
Change-Id: I2f612fd186a1a260cab21860b192c9f6dc3f560f
Reviewed-on: https://go-review.googlesource.com/c/go/+/380777
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tim King <taking@google.com>
Method signatures can introduce a significant number of edges into the
type graph. One can imagine a generic type with many methods, each of
which may use other instantiated types, etc. For performance, when type
checking generic code, we should avoid unnecessary instantiation of
methods wherever possible.
This CL achieves this by making method instantiation lazy at the
individual method level. It abstracts method access into a methodList
type, which may be either eager or lazy. In the lazy case, methods are
only instantiated when they are accessed via the Named.Method,
MethodSet, or LookupFieldOrMethod APIs. Factoring out a methodList type
makes it easier to verify that we're not leaking the methods slice
anywhere, and as a side benefit reduces the size of *Named types in the
case where there are no methods. The effective memory footprint of Named
types with methods increases by a pointer (to hold the slice of guards),
and the footprint of instantiated named types increases additionally by
a sync.Once per method. We estimate that this memory increase is more
than offset by the reduction in the number of instantiated methods.
This also simplifies the code. Previously we had to work around the fact
that named type expansion could occur before all signatures were set-up,
by stashing the instantiated receiver into a partially filled-out *Func.
With fully lazy methods, we can rely on the invariant that any use of
methods in valid code can only occur after all signatures can be type
checked. This means that we can fully instantiate the *Func, and don't
need to deal with partially instantiated stubs.
Finally, this CL fixes a bug (issue #50619), where traversing
Method->Receiver Type->Method did not get us back where we started. This
is fixed by not instantiating a new method if t is already the receiver
base of the original method.
A test is added to explicitly verify the invariant above, and more test
cases are added for the behavior of Info with respect to generic code.
Fixes#50619
Change-Id: I5b6d2bdc4404c9f5dcb583a29cb64e8af9794c54
Reviewed-on: https://go-review.googlesource.com/c/go/+/380499
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>
We have disallowed having a typeparam on the right-hand-side of a type
declaration. So, we disabled much of the test absdiff.go. I recently
wrote a new test absdiff2.go to use a structure containing the type
param type, so I could attach a method properly and run the full test.
As a contrast, I thought I would create absdiff3.go, where the Abs
functionality is passed in as a function callback (but derived from a
generic function). This is simpler, and more inline with some of the
guidelines that Ian has been proposing (use passed-in functions rather
than requiring methods, when possible, for greater ease-of-use).
Only adds a new test absdiff3.go. (And fixes a comment in absdiff2.go.)
Change-Id: I6dd185b50a3baeec31f689a892319963468a7201
Reviewed-on: https://go-review.googlesource.com/c/go/+/380774
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Added a new absdiff2.go test case, which works fully without using a
typeparam on the right-hand-side of a type declaration (which is
disallowed). Fixed an issue that the test revealed, which is that we
need to set g.curDecl properly for the "later" functions which are
deferred until after all declarations are initially processed. Also,
g.curDecl may be non-nil in typeDecl for local type declaration. So, we
adjust the associate assertion, and save/restore g.curDecl
appropriately.
Fixes#50790
Change-Id: Ieed76a7ad0a83bccb99cbad4bf98a7bfafbcbbd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/380594
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
While checking comparability of type parameters, we recurse through
_TypeSet.IsComparable, but do not pass the cycle-tracking seen map,
resulting in infinite recursion in some cases.
Refactor to pass the seen map through this recursion.
Fixes#50782
Change-Id: I2c2bcfed3398c11eb9aa0c871da59e348bfba5f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/380504
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>
By processing non-alias type declarations before alias type declaration,
and those before everything else we can avoid some of the remaining
errors which are due to alias types not being available.
For #25838.
For #50259.
For #50276.
For #50729.
Change-Id: I233da2899a6d4954c239638624dfa8c08662e6b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/380056
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>
The type checker doesn't have a general mechanism to "use" the type
of a type alias whose type depends on a recursive type declaration
which is not yet completely type-checked. In some cases, the type of
a type alias is needed before it is determined; the type is incorrect
(invalid) in that case but no error is reported. The type-checker is
happy with this (incorrect type), but the compiler may crash under
some circumstances.
A correct fix will likely require some form of forwarding type which
is a fairly pervasive change and may also affect the type checker API.
This CL introduces a simple side table, a map of broken type aliases,
which is consulted before the type associated with a type alias is
used. If the type alias is broken, an error is reported.
This is a stop-gap solution that prevents the compiler from crashing.
The reported error refers to the corresponding issue which suggests
a work-around that may be applicable in some cases.
Also fix a minor error related to type cycles: If we have a cycle
that doesn't start with a type, don't use a compiler error message
that explicitly mentions "type".
Fixes#50259.
Fixes#50276.
Fixes#50779.
For #50729.
Change-Id: Ie8e38f49ef724e742e8e78625e6d4f3d4014a52c
Reviewed-on: https://go-review.googlesource.com/c/go/+/379916
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>
In validType, when we see an instantiated type, proceed as with
non-generic types but provide an environment in which to look up
the values (the corresponding type arguments) of type parameters
of the instantiated type. For each type parameter for which there
is a type argument, proceed with validating that type argument.
This corresponds to applying validType to the instantiated type
without actually instantiating the type (and running into infinite
instantiations in case of invalid recursive types).
Also, when creating a type instance, use the correct source position
for the instance (the start of the qualified identifier if we have an
imported type).
Fixes#48962.
Change-Id: I196c78bf066e4a56284d53368b2eb71bd8d8a780
Reviewed-on: https://go-review.googlesource.com/c/go/+/379414
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Because validType doesn't modify global state anymore, there's
no need to ignore imported types. When we start tracking type
parameters, we need to include imported types because they may
contribute to cycles that invalidate a type.
This CL effectively reverts CL 202483 (issue #35049, which
doesn't apply anymore because we don't change the state of
imported objects).
Preparation for fixing issue #48962.
For #35049.
For #48962.
Change-Id: I06f15575ad197375c74ffd09c222250610186b15
Reviewed-on: https://go-review.googlesource.com/c/go/+/378675
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 have a separate top-level entry point for validType
we can use the more narrow type *Named (instead of Type) for its
argument.
Preparation for fixing issue #48962.
Change-Id: I93aee4abc87036c6a68323dc970efe8e617a9103
Reviewed-on: https://go-review.googlesource.com/c/go/+/379434
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>
The validType check is independent of the work of declaring objects.
Move it into a separate file for better separation of concerns and
code organization.
No other changes - this is purely a code move.
Preparation for fixing issue #48962.
Change-Id: Ib08db2d009c4890882d0978b278e965ca3078851
Reviewed-on: https://go-review.googlesource.com/c/go/+/378674
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>
TestFutexsleep was originally created in CL 7876043 as a
regression test for buggy division logic in futexsleep. Several months
later CL 11575044 moved this logic to timediv (called by futexsleep).
This test calls runtime.Futexsleep, which temporarily disables
asynchronous preemption. Unfortunately, TestFutexSleep calls this from
multiple goroutines, creating a race condition that may result in
asynchronous preemption remaining disabled for the remainder of the
process lifetime.
We could fix this by moving the async preemption disable to the main
test function, however this test has had a history of flakiness. As an
alternative, this CL replaces the test wholesale with a new test for
timediv, covering the overflow logic without the difficulty of dealing
with futex.
Fixes#50749.
Change-Id: If9e1dac63ef1535adb49f9a9ffcaff99b9135895
Reviewed-on: https://go-review.googlesource.com/c/go/+/380058
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Given we have support for field access to type params with a single
structural type, we need to distinguish between methods calls and field
access when we have an OXDOT node on an expression which is a typeparam
(or correspondingly a shape). We were missing checks in getInstInfo,
which figures out the dictionary format, which then caused problems when
we generate the dictionaries. We don't need/want dictionary entries for
field access, only for bound method calls. Added a new function
isBoundMethod() to distinguish OXDOT nodes which are bound calls vs.
field accesses on a shape.
Removed isShapeDeref() - we can't have field access or method call on a
pointer to variable of type param type.
Fixes#50690
Change-Id: Id692f65e6f427f28cd2cfe474dd30e53c71877a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/379674
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Very, very rarely TestVectoredHandlerDontCrashOnLibrary fails because
the C subprocess exits with a 0 status code and no output. This
appears to happen because C does not actually guarantee that stdout
will be flushed on exit and somehow, very rarely, it is not flushed.
Add explicit fflushes to fix this. This reduces the failure rate of
TestVectoredHandlerDontCrashOnLibrary from 0.0013% to 0% in 250,000
iterations.
Fixes#49959.
Change-Id: I892cf49a165ac91134c5da37588a2ab11e1f3f8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/380494
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This fixes checks for crossing module boundaries when the root of
the module is a symlink. We're comparing paths by string, so we need
to follow the symlink to get the proper path to compare.
Change-Id: Idf5f0dd5c49bcae5fffb5372e99a7fab89169a9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/380057
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The closure in parallelLabelHog should be labeled in a addition to
parallelLabelHog itself. Generally samples on that goroutine land on
labelHog, but there is a small portion of the closure outside of
labelHog.
Fixes#50740.
Change-Id: I363b6d8eec2e6920c215686e2039fce6d5b29a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/380055
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
In a method declaration "func (f *Foo[_, _]) String() string { ... }",
the two blank typeparams have the same name, but our current design with
types1 needs unique names for type params. Similarly, for export/import,
we need unique names to keep the type params straight in generic types
and connect the proper type param with the proper constraint. We make
blank type params unique by changing them to $1, $2, etc in noder.typ0()
via typecheck.TparamExportName(). We then revert $<num> back to _ during
type2 import via typecheck.TparamName(). We similarly revert
during gcimporter import. We don't need/want to revert in the types1
importer, since we want unique names for type params.
Rob Findley has made a similar change to x/tools (and we tried to make
the source code changes similar for the gcimporter and types2 importer
changes).
Fixes#50419
Change-Id: I855cc3d90d06bcf59541ed0c879e9a0e4ede45bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/379194
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Use an enviroment variable rather than a build tag to control starting
a busy loop thread when testprogcgo starts. This lets us skip another
build that invokes the C compiler and linker, which should avoid
timeouts running the runtime tests.
Fixes#44422
Change-Id: I516668d71a373da311d844990236566ff63e6d72
Reviewed-on: https://go-review.googlesource.com/c/go/+/379294
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Now that we instantiate methods on instantiated types, there is no need
to use unification to match signatures inside of missingMethod.
Generally, we should never encounter uninstantiated signatures within
statements. If we do encounter signatures that contain type parameters,
it is because the signatures are themselves defined or instantiated
using type parameters declared in the function scope (see example
below). The current unification logic would not handle this.
type S[T any] struct{}
func (S[T]) m(T)
func _[P any]() bool {
var v interface{m(int)}
_, ok = v.(S[P])
return ok
}
Change-Id: I754fb5535bba2fc7a209dc7419fd4015c413c9a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/379540
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>
Most CONVIFACEs are created in the transform phase (or old typechecker,
in -G=0 mode). But if the main result of a multi-value assignment (map,
channel, or dot-type) must be converted to an interface during the
assignment, that CONVIFACE is not created until (*orderState).as2ok in
the order phase (because the AS2* ops and their sub-ops are so tightly
intertwined). But we need to create the CONVIFACE during the
stenciling/transform phase to enable dictionary lookups. So, in
transformAssign(), if we are doing a special multi-value assignment
involving a type-param-derived type, assign the results first to temps,
so that we can manifest the CONVIFACE during the transform in assigning
the first temp to lhs[0].
Added a test for both AS2RECV (channel receives) and AS2MAPR (maps). I
don't think we can have a type assertion on a type-param-derived type.
Fixes#50642
Change-Id: I4d079fc46c93d8494d7db4ea8234d91522edb02a
Reviewed-on: https://go-review.googlesource.com/c/go/+/379054
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
TestCPUProfileMultithreadMagnitude compares pprof results vs OS rusage
to verify that pprof is capturing all CPU usage. Presently it compares
the sum of cpuHog1 samples vs rusage. However, background usage from the
scheduler, GC, etc can cause additional CPU usage causing test failures
if rusage is too far off from the cpuHog1 samples.
That said, this test doesn't actually need to care about cpuHog1
samples. It simply cares that pprof samples match rusage, not what the
breakdown of usage was. As a result, we can compare the sum of _all_
pprof samples vs rusage, which should implicitly include any background
CPU usage.
Fixes#50097.
Change-Id: I649a18de5b3dcf58b62be5962fa508d14cd4dc79
Reviewed-on: https://go-review.googlesource.com/c/go/+/379535
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This makes TestLabelSystemstack much more strict, enabling it to detect
any misplacement of labels.
Unfortunately, there are several edge cases where we may not have an
obviously correct stack trace, so we generally except the runtime
package, with the exception of background goroutines that we know should
not be labeled.
For #50007
For #50032
Change-Id: I8dce7e7da04f278ce297422227901efe52782ca0
Reviewed-on: https://go-review.googlesource.com/c/go/+/369984
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
GC background mark worker goroutines are created when the first GC is
triggered (or next GC after GOMAXPROCS increases). Since the GC can be
triggered from a user goroutine, those workers will inherit any pprof
labels from the user goroutine.
That isn't meaningful, so avoid it by excluding system goroutines from
inheriting labels.
Fixes#50032
Change-Id: Ib425ae561a3466007ff5deec86b9c51829ab5507
Reviewed-on: https://go-review.googlesource.com/c/go/+/369983
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>
Instead, allow the test to run up until nearly the test's deadline,
whatever that may be, and then crash with a panic (instead of calling
t.Errorf) to get a useful goroutine dump.
With the arbitrary timeout removed, we can now also run this test in
short mode, reducing its impact on test latency.
Fixes#19381
Change-Id: Ie1fae321a2973fcb9b69a012103363f16214f529
Reviewed-on: https://go-review.googlesource.com/c/go/+/378034
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For an extension operation like MOWWreg, if the operand is already
extended, we optimize the second extension out. Usually a LoadReg
of a proper type would come already extended, as a MOVW/MOVWU etc.
instruction does. But for a LoadReg to a floating point register,
the instruction does not do the extension. So we cannot elide the
extension.
Fixes#50671.
Change-Id: Id8991df78d5acdecd3fd6138c558428cbd5f6ba3
Reviewed-on: https://go-review.googlesource.com/c/go/+/379236
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>
This test occasionally takes very slightly longer than the 3 second
timeout on slow builders (especially windows-386-2008), so increase
the timeout to 5 seconds. It fails with much longer timeouts on Plan
9, so skip it as flaky there.
Updates #41015.
Change-Id: I426a7adfae92c18a0f8a223dd92762b0b91565e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/379214
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently the code handles the case of returning values from
a function with no result parameters as a special case.
Consider this input:
package p
func f0_2() { return 1, 2 }
func f0_1() { return 1 }
func f1_0() int { return }
func f1_2() int { return 1, 2 }
func f2_0() (int, int) { return }
func f2_1() (int, int) { return 1 }
The errors are:
x.go:3:33: no result values expected <<<
x.go:4:33: no result values expected <<<
x.go:5:26: not enough return values
have ()
want (int)
x.go:6:36: too many return values
have (number, number)
want (int)
x.go:7:26: not enough return values
have ()
want (int, int)
x.go:8:33: not enough return values
have (number)
want (int, int)
There are two problems with the current special case emitting the
errors on the marked line:
1. It calls them 'result values' instead of 'return values'.
2. It doesn't show the type being returned, which can be useful to programmers.
Using the general case solves both these problems,
so this CL removes the special case and calls the general case instead.
Now those two errors read:
x.go:3:33: too many return values
have (number, number)
want ()
x.go:4:33: too many return values
have (number)
want ()
Fixes#50653.
Change-Id: If6b47dcece14ed4febb3a2d3d78270d5be1cb24d
Reviewed-on: https://go-review.googlesource.com/c/go/+/379116
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Consider the following program:
package p
func f() {
x := 1
v := 2
switch v.(type) {
case int:
println(x)
println(x / 0)
case 1:
}
}
Before this CL, the compiler prints:
x.go:4:2: x declared but not used
x.go:6:9: v (variable of type int) is not an interface
x is in fact used, and other errors in the switch go undiagnosed.
This commit fixes that problem by processing the switch statement
even when the 'not an interface' error is reported.
Now the compiler drops the spurious 'declared but not used'
and adds two previously undiagnosed problems:
x.go:6:9: v (variable of type int) is not an interface
x.go:9:15: invalid operation: division by zero
x.go:10:7: 1 is not a type
go/types was printing roughly the same thing the compiler did before,
and now still prints roughly the same thing the compiler does after.
(The only differences are in the exact reported columns.)
Fixes#50493.
Change-Id: I317883f29077b1b4bbd0e8793617fd3bb31aa0f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/379117
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the compiler, we need to distinguish field and method access on a
type param. For field access, we avoid the dictionary access (to create
an interface bound) and just do the normal transformDot() (which will
create the field access on the shape type).
This field access works fine for non-pointer types, since the shape type
preserves the underlying type of all types in the shape. But we
generally merge all pointer types into a single shape, which means the
field will not be accessible via the shape type. So, we need to change
Shapify() so that a type which is a pointer type is mapped to its
underlying type, rather than being merged with other pointers.
Because we don't want to change the export format at this point in the
release, we need to compute StructuralType() directly in types1, rather
than relying on types2. That implementation is in types/type.go, along
with the helper specificTypes().
I enabled the compiler-related tests in issue50417.go, added an extra
test for unnamed pointer types, and added a bunch more tests for
interesting cases involving StructuralType(). I added a test
issue50417b.go similar to the original example, but also tests access to
an embedded field.
I also added a unit test in
cmd/compile/internal/types/structuraltype_test.go that tests a bunch of
unusual cases directly (some of which have no structural type).
Updates #50417
Change-Id: I77c55cbad98a2b95efbd4a02a026c07dfbb46caa
Reviewed-on: https://go-review.googlesource.com/c/go/+/376194
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We use uname -m to decide the GOHOSTARCH default,
and on my ARM64 Mac laptop, uname -m prints x86_64.
uname -a prints:
Darwin p1.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000 x86_64
(Note the x86_64 at the end, consistent with uname -m.)
The effect of this is that make.bash builds an x86 toolchain
even when I start with an ARM64 bootstrap toolchain!
Avoid being tricked by looking for RELEASE_ARM64 instead.
Fixes#50643.
Change-Id: I76eded84bde8009d29419d5982bf964a0bf1c8fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/378894
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The VMOVQ instruction stores a 128-bit number into a V register, for
example:
VMOVQ $0x1122334455667788, $0x99aabbccddeeff00, V2
From a documentation (https://pkg.go.dev/cmd/internal/obj/arm64) point
of view, the value in V2 should be 0x112233445566778899aabbccddeeff00,
however the value is actually 0x99aabbccddeeff001122334455667788. The
reason is that we misplaced the high 64-bit and the low 64-bit in the
literal pool. To maintain backward compatibility, this CL adjusts the
rule of VMOVQ instruction to make the documentation consistent with the
code.
Fixes#50528
Change-Id: Ib51f59e97c55252ab2a50bbc6ba4d430732a7a04
Reviewed-on: https://go-review.googlesource.com/c/go/+/377055
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Trust: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, there are two regexps in the race detector output tests
that assume subtests will complete in < 1 second. This isn't necessary
and very occasionally fails (on builders that are probably very
loaded). Make these tests less picky about timing.
Fixes#50612.
Change-Id: Ib3f94d6c5dc37541dbeb06de71cf462a74af844b
Reviewed-on: https://go-review.googlesource.com/c/go/+/378581
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
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 unconditionally in
cmd/dist. Instead use a build-tagged file, as the final version of
cmd/dist will use the final toolchain.
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.
For #46272.
For #49209.
For #50146.
Change-Id: I515d2ec58e4c0034b76bf624ecaab38f16146074
Reviewed-on: https://go-review.googlesource.com/c/go/+/371474
Trust: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
SHT_NOBITS sections do not occupy space in the file and their offset is
"conceptual", reading their data should return all zeroes instead of
reading bytes from the section that follows them.
Change-Id: Iaa9634792c1909c3e87dab841dd646cd6dcf9027
Reviewed-on: https://go-review.googlesource.com/c/go/+/375216
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The netpoll code was written long ago, when the
only multiprocessors that Go ran on were x86.
It assumed that an atomic store would trigger a
full memory barrier and then used that barrier
to order otherwise racy access to a handful of fields,
including pollDesc.closing.
On ARM64, this code has finally failed, because
the atomic store is on a value completely unrelated
to any of the racily-accessed fields, and the ARMv8
hardware, unlike x86, is clever enough not to do a
full memory barrier for a simple atomic store.
We are seeing a constant background rate of trybot
failures where the net/http tests deadlock - a netpollblock
has clearly happened after the pollDesc has begun to close.
The code that does the racy reads is netpollcheckerr,
which needs to be able to run without acquiring a lock.
This CL fixes the race, without introducing unnecessary
inefficiency or deadlock, by arranging for every updater
of the relevant fields to publish a summary as a single
atomic uint32, and then having netpollcheckerr use a
single atomic load to fetch the relevant bits and then
proceed as before.
Fixes#45211 (until proven otherwise!).
Change-Id: Ib6788c8da4d00b7bda84d55ca3fdffb5a64c1a0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/378234
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we export a shape instantiation, because a particular
fully-instantiated type is needed by an inlineable function, we possibly
export the body of the instantiation, if it is inlineable. In this case,
we should have been calling ImportedBody() to make sure that the
function body had already been read in (if it is actually imported from
another package).
Fixes#50598
Change-Id: I512d2bcc745faa6ff3a97e25bc8f46e2c2643d23
Reviewed-on: https://go-review.googlesource.com/c/go/+/378494
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Let T be a type parameter, and say we instantiate it with S, a type
that isn't pointer-like (e.g. a pair of ints, or as in 50182, a
slice). Then to call a method m on a variable of type T, the compiler
does essentially:
var v T = ...
i := (interface{m()})(v)
i.m()
The conversion at that second line allocates, as we need to make the
data word for an interface. And in the general case, that interface
may live an arbitrarily long time. But in this case, we know it
doesn't.
The data word of i has type *S. When we call i.m, we can't call S.m
directly. It is expecting an S, not a *S. We call through a wrapper
defined on *S, which looks like:
func (p *S) m() {
var s S = *p
s.m()
}
The value passed in for p is exactly the data word mentioned above. It
never escapes anywhere - the wrapper copies a type S variable out of
*p and p is dead after that. That means that in the situation where we
build an interface for the explicit purpose of calling a method on it,
and use that built interface nowhere else, the allocation of the data
word for that interface is known to die before the call returns and
thus can be stack allocated.
One tricky case is that although the allocation of the backing store
of the interface conversion doesn't escape, pointers we store *inside*
that allocation might escape (in fact they definitely will, unless we
can devirtualize the receiver).
Fixes#50182
Change-Id: I40e893955c2e6871c54ccecf1b9f0cae17871b0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/378178
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In order to make sure we export the dictionaries/shape methods for all
fully-instantiated types in inlineable functions, we need to descend
fully into types. For example, we may have a map type (e.g.
map[transactionID]Promise[*ByteBuffer]), where the key or value is a new
fully-instantiated type. So, I add a new checkFullyInst() traversal
function, which traverses all encountered types, but maintains a map, so
it only traverse it type once. We need to descend fully into interfaces,
structs, and methods, since a fully-instantiated type make occur in any
fields or arguments/results of methods, etc.
Fixes#50561
Change-Id: I88681a30384168539ed7229eed709f4e73ff0666
Reviewed-on: https://go-review.googlesource.com/c/go/+/378154
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Using type aliases, it's possible to create structs with embedded
fields that have no corresponding type literal notation. However, we
still need to generate a unique name for these types to use for linker
symbols. This CL introduces a new "struct{ Name = Type }" syntax for
use in LinkString formatting to represent these types.
Reattempt at CL 372914, which was rolled back due to race-y
LocalPkg.Lookup call that isn't safe for concurrency.
Fixes#50190.
Change-Id: I0b7fd81e1b0b3199a6afcffde96ade42495ad8d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/378434
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>
go work sync resets the state in the modload package before each
iteration where it updates the workspace modules' go.mod files. But
before this change it wasn't resetting the global state in the modfetch
package. This is necessary because the modfetch package keeps track of
the sums that will be written to go.sum. Further, the fetch caches
will update information about which modules are used when fetching
packages, and so those caches need to be cleared between each workspace
module.
Thanks bcmills for helping me debug!
Fixes#50038
Change-Id: I5679c18a80feb7c5194c4a5f7e7129c7d198ef7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/376655
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Adds simple fuzz targets to archive/tar, archive/zip, compress/gzip,
encoding/json, image/jpeg, image/gif, and image/png.
Second attempt, this time we don't use the archives in testdata when
fuzzing archive/tar, since those are rather memory intensive, and
were crashing a number of builders.
Change-Id: I4828d64fa4763c0d8c980392a6578e4dfd956e13
Reviewed-on: https://go-review.googlesource.com/c/go/+/378174
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
- support printing of expression and type lists in sprintf
- simplified some code in go/types/exprstring.go
- fixed a typo in syntax package
Change-Id: Ic4bc154200aad95958d5bc2904a9ea17cf518388
Reviewed-on: https://go-review.googlesource.com/c/go/+/377974
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a stop gap solution to avoid panics due to stack overflow
during type unification. While this doesn't address the underlying
issues (for which we are still investigating the correct approach),
it prevents a panic during compilation and reports a (possibly not
quite correct) error message.
If the programs are correct in the first place, manually providing
the desired type arguments is a viable work-around, resulting in
code that will continue to work even when the issues here are fixed
satisfactorily.
For #48619.
For #48656.
Change-Id: I13bb14552b38b4170b5a1b820e3172d88ff656ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/377954
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
If we have more than 2 arguments, we may have arguments with named and
unnamed types. If that is the case, permutate params and args such that
the arguments with named types are first in the list. This doesn't affect
type inference if all types are taken as is. But when we have inexact
unification enabled (as is the case for function type inference), when
a named type is unified with an unnamed type, unification proceeds with
the underlying type of the named type because otherwise unification would
fail right away. This leads to an asymmetry in type inference: in cases
where arguments of named and unnamed types are passed to parameters with
identical type, different types (named vs underlying) may be inferred
depending on the order of the arguments.
By ensuring that named types are seen first, order dependence is avoided
and unification succeeds where it can.
This CL implements the respectice code but keeps it disabled for now,
pending decision whether we want to address this issue in the first
place.
For #43056.
Change-Id: Ibe3b08ec2afe90a24a8c30cd1875d504bcc2ef39
Reviewed-on: https://go-review.googlesource.com/c/go/+/377894
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Until now, CTI (constraint type inference) was run before
FTI (function type inference). This lead to situations
where CTI infered a type that is missing necessary methods
even though a function argument of correct type was given.
This can happen when constraint type inference produces a
inferred type that is the structural type of multiple types,
which then is an underlying type, possibly without methods.
This CL removes the initial CTI step; it is only applied
after FTI with type arguments is run, and again after FTI
with untyped arguments is run.
Various comments are adjusted to reflect the new reality.
Fixes#50426.
Change-Id: I700ae6e762d7aa00d742943a2880f1a1db33c2b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/377594
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Introduce a (local) notion of a set of representative types,
which serves as a representation/approximation of an
interface's actual type set. If the set of representative
types is is non-empty and finite, it corresponds to the set
of specific types of the interface.
In the implementation, the set of representative types serves
as a finite representation of an interface's type set, together
with the set of methods.
Change-Id: Ib4c6cd5e17b81197672e4247be9737dd2cb6b56f
Reviewed-on: https://go-review.googlesource.com/c/go/+/376834
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
With this change, we shall now see:
*myS does not implement S (wrong type for DoSomething method)
have DoSomething() (string, error) at ./main.go:9:14
want DoSomething() (int, error)
instead of previously:
*myS does not implement S (wrong type for DoSomething method)
have DoSomething() (string, error)
want DoSomething() (int, error)
Fixes#42841Fixes#45813
Change-Id: I66990929e39b0d36f2e91da0d92f60586a9b84e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/373634
Trust: Robert Findley <rfindley@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Issue #50552 is due to a problem with my recent improvement in the
interaction between generics and inlining. In markInlBody(), we now mark
dictionaries and shape methods for export, so they will be available for
any package that inlines the current inlineable function. But we need to
make sure that the dictionary and method symbols have actually been
resolved into Nodes (looked up in the import data), if they are not
already defined, so we can then mark them for export.
Improved header comment on Resolve().
Fixes#50552
Change-Id: I89e52d39d3b9894591d2ad6eb3a8ed3bb5f1e0a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/377714
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Change hidePanic (now renamed handlePanic) to print out the "internal
compiler error" message for all panics and runtime exceptions, similar
to what we already do for the SSA backend in ssa.Compile().
Previously, hidePanic would not catch panics/exceptions unless it wanted
to completely hide the panic because there had already been some
compiler errors.
Tested by manually inserting a seg fault in the compiler, and verifying
that the seg fault is cause and "internal compiler error" message (with
stack trace) is displayed proeprly.
Updates #50423
Change-Id: Ibe846012e147fcdcc63ac147aae4bdfc47bf5a58
Reviewed-on: https://go-review.googlesource.com/c/go/+/376057
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
For some reason, aix sometimes executes the bogus function body. This
should never happen as it lives in a no-execute section. It might be
a transient permission blip as the heap grows.
Add a small function to cleanup and synchronize the icache before
jumping to the bogus function to ensure it causes a panic, not SIGILL.
Fixes#44583
Change-Id: Iadca62d82bfb70fc62088705dac42a880a1208fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/377314
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
I made the default be that, where there are differences between types2
and -G=0 error messages, we want errorcheck tests to pass types2.
Typically, we can get errorcheck to pass on types2 and -G=0 if they give
the same number of error messages on the same lines, just different
wording. If they give a different number of error messages, then I made
types2 pass. I added an exception list for -G=0 to cover those cases
where -G=0 and types give different numbers of error messages.
Because types2 does not run if there are syntax errors, for several
tests, I had to split the tests into two parts in order to get all the
indicated errors to be reported in types2 (bug228.go, bug388.go,
issue11610.go, issue14520.go)
I tried to preserve the GCCGO labeling correctly (but may have gotten
some wrong). When types2 now matches where a GCCGO error previously
occurred, I transformed GCCGO_ERROR -> ERROR. When types2 no longer
reports an error in a certain place, I transformed ERROR -> GCCGO_ERROR.
When types2 reports an error in a new place, I used GC_ERROR.
The remaining entries in types2Failures are things that I think we
probably still need to fix - either actually missing errors in types2,
or cases where types2 gives worse errors than -G=0.
Change-Id: I7f01e82b322b16094096b67d7ed2bb39b410c34f
Reviewed-on: https://go-review.googlesource.com/c/go/+/372854
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Follow-up on comment in CL 376914.
Also:
- add missing check != nil test in assignableTo
- use check.sprintf rather than fmt.Sprintf in missingMethodReason
For #48312.
Change-Id: Ie209b4101a7f2c279e42a59987d0068079c8b69f
Reviewed-on: https://go-review.googlesource.com/c/go/+/377375
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
- detect *interface case and report specific error
- replaced switch with sequence of if's for more clarity
- fixed isInterfacePtr: it applies to all interfaces, incl.
type parameters
- reviewed/fixed all uses of isInterfacePtr
- adjusted error messages to be consistently of the format
"type %s is pointer to interface, not interface"
Fixes#48312.
Change-Id: Ic3c8cfcf93ad57ecdb60f6a727cce9e1aa4afb5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/376914
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Added a test to make sure that the private methods of a local generic
type are properly exported, if there is a global variable with that
type.
Added comments in crawler.go, to give more detail and to give more about
the overall purpose.
Fixed one place where t.isFullyInstantiated() should be replaced by
isPtrFullyInstantiated(t), so that we catch pointers to generic types
that may be used as a method receiver.
Change-Id: I9c42d14eb6ebe14d249df7c8fa39e889f7cd3f22
Reviewed-on: https://go-review.googlesource.com/c/go/+/374754
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Using type aliases, it's possible to create structs with embedded
fields that have no corresponding type literal notation. However, we
still need to generate a unique name for these types to use for linker
symbols. This CL introduces a new "struct{ Name = Type }" syntax for
use in LinkString formatting to represent these types.
Fixes#50190.
Change-Id: I025ceb09a86e00b7583d3b9885d612f5d6cb44fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/372914
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The failure mode in #37794 does not match the failure mode described
in #18784. However, since the test is currently skipped on all other
MIPS variants, it may be that they suffer from the same underlying GDB
bug. Ideally one of the Go MIPS maintainers should file an upstream
bug and remove the skip once it is fixed; in the meantime, there is no
point in continuing to let the test fail on just one of the four MIPS
variants.
For #37794
Change-Id: I570f51cc04cbb7ef1ed7efd526e26886af53bfb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/376654
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Finally figured out how to deal with the interaction between generics
and inlining. The problem has been: what to do if you inline a function
that uses a new instantiated type that hasn't been seen in the current
package? This might mean that you need to do another round of
function/method instantiatiations after inlining, which might lead to
more inlining, etc. (which is what we currently do, but it's not clear
when you can stop the inlining/instantiation loop).
We had thought that one solution was to export instantiated types (even
if not marked as exportable) if they are referenced in exported
inlineable functions. But that was quite complex and required changing
the export format. But I realized that we really only need to make sure
the relevant dictionaries and shape instantiations for the instantiated
types are exported, not the instantiated type itself and its wrappers.
The instantiated type is naturally created as needed, and the wrappers
are generated automatically while writing out run-time type (making use
of the exported dictionaries and shape instantiations).
So, we just have to make sure that those dictionaries and shape
instantiations are exported, and then they will be available without any
extra round of instantiations after inlining. We now do this in
crawler.go. This is especially needed when the instantiated type is only
put in an interface, so relevant dictionaries/shape instantiations are
not directly referenced and therefore exported, but are still needed for
the itab.
This fix avoids the phase ordering problem where we might have to keep
creating new type instantiations and instantiated methods after each
round of inlining we do.
Removed the extra round of instantiation/inlining that were added in the
previous fix. The existing tests
test/typeparam{geninline.go,structinit.go} already test this situation
of inlining a function referencing a new instantiated type.
Added the original example from issue 50121 as test (has 5 packages),
since it found a problem with this code that the current simpler test
for 50121 did not find.
Change-Id: Iac5d0dddf4be19376f6de36ee20a83f0d8f213b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/375494
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Currently TestCPUProfileMultithreadMagnitude runs two CPU consumption
functions in a single profile and then analyzes the results as separate
subtests.
This works fine, but when debugging failures it makes manual analysis of
the profile dump a bit annoying.
Refactor the test to collect separate profiles for each subtest for
easier future analysis.
For #50097.
For #50232.
Change-Id: Ia1c8bb86aaaf652e64c5e660dcc2da47d2194c2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/372800
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rhys Hiltner <rhys@justin.tv>
Reviewed-by: Bryan Mills <bcmills@google.com>
When an http.FileServer is given a path like file1/file2 where file1
exists but file2 does not, the proper HTTP status should be
NotFound. Some OSes return a "not a directory" error instead, so this
must be mapped to NotFound.
That mapping was already being done for the Dir FileSystem
implementation, as discussed in #18984. But it wasn't for the
FS implementation.
This CL does the same mapping for FS, by generalizing the function
that did it for Dir.
Fixes#49552
Change-Id: I61d6aa8ef101158e9674707d44e653f5dedbd040
Reviewed-on: https://go-review.googlesource.com/c/go/+/376874
Trust: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Upgrade the test certificate from RSA 1024 (not FIPS-approved)
to RSA 2048 (FIPS-approved), allowing tests to pass when
the dev.boringcrypto branch FIPS-only mode is enabled.
Fixes#48674.
Change-Id: I613d2f8d0207bf3683fd0df256bf0167604996c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353869
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Similarly to what we do for the built-in function `copy`,
where we allow a string as 2nd argument to append, also
permit a type parameter constrained by string|[]byte.
While at it, change date in the manual.go2 test files so
that we don't need to constantly correct it when copying
a test case from that file into a proper test file.
Fixes#50281.
Change-Id: I23fed66736aa07bb3c481fe97313e828425ac448
Reviewed-on: https://go-review.googlesource.com/c/go/+/376214
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
ReadDirent returns only as many directory entries as will fit in the
buffer, and each entry is variable-length — so we have no guarantee in
general that a buffer of a given arbitrary size can hold even one
entry, let alone all ten entries expected by the test.
Instead, iterate calls to ReadDirent until one of the calls returns
zero entries and no error, indicating that the directory has been read
to completion.
Fixes#37323
Change-Id: I7f1cedde7666107256604e4ea1ac13c71f22151a
Reviewed-on: https://go-review.googlesource.com/c/go/+/376334
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
types2 allows the conversion of a slice of a user-defined byte type B
(not builtin uint8 or byte) to string. But runtime.slicebytetostring
requires a []byte argument, so add in a CONVNOP from []B to []byte if
needed. Same for the conversion of a slice of user-defined rune types to
string.
I made the same change in the transformations of the old typechecker, so
as to keep tcConv() and transformConv() in sync. That fixes the bug for
-G=0 mode as well.
Fixes#23536
Change-Id: Ic79364427f27489187f3f8015bdfbf0769a70d69
Reviewed-on: https://go-review.googlesource.com/c/go/+/376056
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 352870 added extra phase for instantiation after inlining, to take
care of the new fully-instantiated types. However, when fetching inlined
body of these types's methods, we need to allow OADDR operations on
untyped expressions, the same as what main inlining phase does.
The problem does not show up, until CL 371554, which made the compiler
do not re-typecheck while importing, thus leaving a OXDOT node to be
marked as address taken when it's not safe to do that.
Fixes#50437
Change-Id: I20076b872182c520075a4f8b84230f5bcb05b341
Reviewed-on: https://go-review.googlesource.com/c/go/+/375574
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: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Since a SECURITY.md file is present in the main Go repository,
GitHub already shows a "Report a security vulnerability" link
in the issue template list. Remove the duplicate custom link.
Fixes#49962.
Change-Id: Ifdf7e93b76ebd9258d907aa9cb4915c0dbc4f93e
Reviewed-on: https://go-review.googlesource.com/c/go/+/376357
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Julie Qiu <julie@golang.org>
The release notes explicitly refer to sections updated
for generics in the spec but then point to the old spec
which is very confusing for beta users.
For #47694
Change-Id: I5b555db3543cc32f088a8b267ec3f1195a52a812
Reviewed-on: https://go-review.googlesource.com/c/go/+/373174
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Rat maintains the invariant that x.b.neg is always false,
but Rat.Denom was writing x.b.neg = false itself too.
That makes Rat.Denom a writing operation, when it should
be a read-only operation. That in turn makes it unsafe to
use from multiple goroutines, which is highly unexpected.
Make it read-only and therefore race-free again.
Fixes#50473.
Change-Id: I97b87913954511e5200c0665d16b9ed63422e505
Reviewed-on: https://go-review.googlesource.com/c/go/+/375935
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Move switch to enable method type parameters entirely
to the parser, by adding the mode AllowMethodTypeParams.
Ensure that the error messages are consistent.
Remove unnecessary code in the type checker.
Fixes#50317.
Change-Id: I4f3958722400bdb919efa4c494b85cf62f4002bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/376054
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>
The c.startParallel channel on the testContext is stuck
in t.Parallel() because c.running starts at 1 for the main
fuzz parent test, and is causing a deadlock because it is
never released. It would normally be released by tRunner,
but needs to instead be released by fRunner instead for fuzz
tests.
Fixes#50217
Change-Id: I2d010e9adddfd8e8321ff2f9dd2e43daf46c128f
Reviewed-on: https://go-review.googlesource.com/c/go/+/374054
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change implements field the access p.f where the type of p
is a type parameter with a structural constraint that is a struct
with a field f. This is only the fix for the type checker. The
compiler will need a separate CL.
This makes the behavior consistent with the fact that we can
write struct composite literals for type parameters with a
struct structural type.
For #50417.
For #50233.
Change-Id: I87d07e016f97cbf19c45cde19165eae3ec0bad2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/375795
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The underlying type of a type parameter is an interface,
so we don't need a special case for type parameters anymore.
Simply share the (identical) code for interfaces.
Adjust code in types.NewMethodSet accordingly.
No functional difference.
Preparation for fix of issues below.
For #50233.
For #50417.
Change-Id: Ib2deadd12f89e6918dec224b4ce35583001c3101
Reviewed-on: https://go-review.googlesource.com/c/go/+/375514
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Do this by running verification for instantiated signatures
later, after the delayed type parameter set-up had a chance
to wrap type bounds in implicit interfaces where needed.
Fixes#50450
Change-Id: If3ff7dc0be6af14af854830bfddb81112ac575cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/375737
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
As a result of the change to the underlying of a type parameter to be
its constraint interface, we had couple inaccuracies that combined to
cause an infinite recursion when type checking the invalid type
parameter list [A A].
- We deferred tpar.iface() using check.later twice: once in
newTypeParam, and then again at the end of collectTypeParams.
- We deferred the check that type parameter constraints are not type
parameters, even though this is unnecessary: the constraint type is
known.
With these inaccuracies, tpar.iface() was executing before our guard
against using type parameters as constraints, causing an infinite
recursion through under().
Fix this by eagerly checking whether the constraint is a type
parameter, and marking it invalid if so. Also remove the unnecessary
calls to tpar.iface() at the end of collectTypeParams, as this will
already have been scheduled by newTypeParam.
Fixes#50321
Change-Id: I4eecbecf21656615867cb94be65b520e9e795bd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/374294
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>
The arbitrary sleep in this test is empirically not always long enough
on slower builders. However, we know the exact number of connections
that should be dialed: we can wait on that number in the dial hook
instead.
Fixes#34495
Change-Id: I538244ceb75a80271a724304b993309482bd5b41
Reviewed-on: https://go-review.googlesource.com/c/go/+/375694
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>
These tests are empirically flaky on the windows/arm and windows/arm64
builders, with a consistent (but rare) failure mode.
This change skips the test if that particular failure mode is
encountered on those platforms; the skip can be removed if and when
someone has the time to pin down the root cause.
For #43120
Change-Id: Ie3a9a06bf47e3a907c7b07441acc1494a4631135
Reviewed-on: https://go-review.googlesource.com/c/go/+/375635
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The function asmsyscall6 must follow AIX stack layout. It means
that its first local variable must be stored after its arguments
area, ie after offset 112.
Fixes#50185
Change-Id: I897731ddd2a9faad8218443a4c2f4b204ad7e173
Reviewed-on: https://go-review.googlesource.com/c/go/+/373074
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
In the dict info, we need to save the SelectorExpr of a generic method
call when making its sub-dictionary entry. The generic method call will
eventually be transformed into a function call on the method shape
instantiation, so we may not always have the selector info available
when we need it to create a dictionary. We use this SelectorExpr as
needed if the relevant call node has already been transformed.
Similarly, we save the InstExpr of generic function calls, since the
InstExpr will be dropped when the function call is transformed to a call
to a shape instantiation. We use this InstExpr if the relevant function
call has already been transformed.
Added an extra generic function Some2 and a call to it from Some that
exercises the generic function case. The existing test already tests the
method call case.
Fixes#50264
Change-Id: I2c7c7d79a8e33ca36a5e88e64e913c57500c97f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/373754
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Since we use existing instantiations from the symbol table when possible
(to make sure each instantiation is unique), we need to pop
instantiations of local types when leaving the containing scope.
g.stmts() now pushes and pops scope, and we do a Pushdcl() in g.typ0()
when creating an instantiation of a local type.
Non-instantiated local types (generic or not) are translated directly
from types2, so they don't need to be pushed/popped. We don't export
function bodies with local types, so there is no issue during import.
We still don't support local types in generic functions/methods.
Fixes#50177
Change-Id: If2d2fe71aec003d13f0338565c7a0da2c9580a14
Reviewed-on: https://go-review.googlesource.com/c/go/+/372654
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A receiver expression for a type with parameters may be an IndexExpr
or IndexListExpr in addition to an Ident or StarExpr. Add cases to
recvString to account for the new types.
Add tests that compare the fields of Func, and the fields of Type that
hold Funcs. These fields weren't previously tested.
Change-Id: Ia2cef51c85113422e0c5745c77dddcd53507ee51
Reviewed-on: https://go-review.googlesource.com/c/go/+/375095
Trust: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current -asan option does not print where the error occurred. The
reason is that the current implementation calls incorrect asan runtime
functions, which do not pass sp and pc where asan runtime functions are
called, and report the stack trace from the native code. But asan runtime
functions are called from cgo on a separated stack, so it cannot dump the
Go stack trace correctly.
The correct asan runtime function we should call is __asan_report_error,
which will pass sp and pc, and report where the error occurred correctly.
This patch fixes this issue.
Add the test cases.
Fixes#50362
Change-Id: I12ee1d46c7ae069ddef3d23f2fe86e112db60045
Reviewed-on: https://go-review.googlesource.com/c/go/+/374395
Trust: Fannie Zhang <Fannie.Zhang@arm.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The riscv64 Hifive Unmatched is the only platform that
failed on testcase TestAnalyzeAnnotations occasionally
after CL 332954 had merged. The failure happens when
ticks per second (freq) is over 1e12 which causing the timestamps
of two events are same.
There are 2 reasons causing big frequency:
1. RDCYCLE is HART based according to the riscv manual which makes
negative ticks delta
2. negative float64 -> uint64 is undefined and "lucky" negative float
is too big to handle for trace
For #46737
Change-Id: I1f3c1ac31aae249969000c719c32aaf5a66d29a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/373034
Trust: Zhuo Meng <mzh@golangcn.org>
Run-TryBot: Zhuo Meng <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
In c-archive mode, when we turn off profiling, we restore the
previous handler for SIGPROF, and ignore SIGPROF signals if no
handler was installed. So if a pending signal lands after we
remove the Go signal handler, it will not kill the program.
In the current code there is a small window, where we can still
receive signals but we are set to not handling the signal. If a
signal lands in this window (possibly on another thread), it will
see that we are not handling this signal and no previous handler
installed, and kill the program. To avoid this race, we set the
previous handler to SIG_IGN (ignoring the signal) when turning on
profiling. So when turning off profiling we'll ignore the signal
even if a stray signal lands in the small window.
Fixes#43828.
Change-Id: I304bc85a93ca0e63b0c0d8e902b097bfdc8e3f1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/374074
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When building/using plugins on darwin, we need to use flat
namespace so the same symbol from the main executable and the
plugin can be resolved to the same address. Apparently, when using
flat namespace the dynamic linker can hang at forkExec when
resolving a lazy binding. Work around it by forcing early bindings.
Fixes#38824.
Change-Id: I983aa0a0960b15bf3f7871382e8231ee244655f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/372798
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The new description matches the implementation (CL 370774).
Also, in the section on type constraints, use "defines" instead of
"determines" because the constraint interface defines the type set
which is precisely the set of acceptable type arguments.
For #49482.
Change-Id: I6f30f49100e8ba8bec0a0f1b450f88cae54312eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/372874
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>
The "someTimeout" constant in the net test is “just to test that
net.Conn implementations don't explode when their SetFooDeadline
methods are called”. It was set to 10 seconds, which is short enough
that it could actually matter on some platforms.
Since the point of the constant is just to make sure methods don't
explode, we should set it to be at least a couple of orders of
magnitude longer than the test: then it is guaranteed not to have any
unintended side-effects.
Fixes#50227
Change-Id: If97ae7bef5e7f16b336d09ccc37f5ea2ea7e70b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/372796
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 parser cannot distinguish a type parameter list of the form
[P *T ] or
[P (T)]
where T is not a type literal from an array length specification
P*T (product) or P(T) (constant-valued function call) and thus
interprets these forms as the start of array types.
This ambiguity must be resolved explicitly by placing *T inside
an interface, adding a trailing comma, or by leaving parentheses
away where possible.
This CL adjusts the parser such that these forms are
interpreted as (the beginning) of type parameter lists
if the token after P*T or P(T) is a comma, or if T is
a type literal.
This CL also adjusts the printer to print a comma if
necessary to avoid this ambiguity, and adds additional
printer tests.
Fixes#49482
Change-Id: I36328e2a7d9439c39ba0349837c445542549e84e
Reviewed-on: https://go-review.googlesource.com/c/go/+/370774
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>
We have code that intends to avoid escaping the package path for
built-in packages. But it is hard to determine which packages are
built-in from a general rule, and we really only want to avoid escaping
for the "go.shape" package (since that gives ugly shape type names). So,
fix the code to only avoid escaping the package path specifically for
the "go.shape" package.
Fixes#50200
Change-Id: Ibaedd7690b99a173007c608c5dfa783ef82b326d
Reviewed-on: https://go-review.googlesource.com/c/go/+/372934
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When a user has showSignature=true set in their Git config and the
commit in question has a signature, the git-show command will output
information about that signature. When this happens, the logic that
tries to parsing a timestamp from the git-show output chokes on this
signature information and the build stamping fails. This change prevents
commit signature information from being displayed even if
showSignature=true, preventing this issue.
Change-Id: I98d0a6fdd1e90dd1b91e0394713b6eb286a69d1a
GitHub-Last-Rev: 610706e23e
GitHub-Pull-Request: golang/go#49790
Reviewed-on: https://go-review.googlesource.com/c/go/+/367034
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also check that executables exist immediately after building them
in parallel tests.
The parallel tests in this package occasionally fail with
"no such file or directory", implying that either the build
command failed to actually write out the binary or something
concurrently deleted it.
This is purely a shot in the dark, but I'm hoping that perhaps
the stderr output from one of these commands will shed some
light on the underlying failure mode.
For #49693
Change-Id: I2e768190c56053550879b89a3ac88c027d4741dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/369034
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>
The imported code is already typechecked. NodAddrAt typechecks its
argument, which is unnecessary here and leads to errors when
typechecking unexported field references in other packages' code.
Mark the node is question as already typechecked, so we don't
retypecheck it.
Fixes#50148
Change-Id: I9789e3e7dd4d58ec095675e27b1c98389f7a0c44
Reviewed-on: https://go-review.googlesource.com/c/go/+/371554
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a port of CL 371757 from go/types to types2, with
minor adjustments for different error handling and AST.
It also names the added API test cases more consistently.
The same renaming was applied to the respective go/types
file.
Updates #50093
Change-Id: Iaa132106a197a207f831525432e62e9d452b17c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/372475
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Recently in Fedora we switched binutils ld's separate-code on. This
led to increased size of binaries, especially on 64k aligned arches.
For example trivial test binary size grew from 80k to 211k on ppc64le
tripping the size check(RHBZ#2030308). Therefore adjusting the size limit.
Change-Id: Ic722d90c338739c0b285f40b12ba4d675e9626a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/371634
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: Cherry Mui <cherryyz@google.com>
Running testshared with the -testx flag leads to:
./testshared.test -testx -testwork
+ mkdir -p /tmp/shared_test125221103
shared_test.go:79: executing go env -x GOROOT failed exit status 2:
flag provided but not defined: -x
usage: go env [-json] [-u] [-w] [var ...]
Run 'go help env' for details.
panic: executing go env -x GOROOT failed exit status 2:
flag provided but not defined: -x
usage: go env [-json] [-u] [-w] [var ...]
Run 'go help env' for details.
Change-Id: Id299979487c021e9ad1d57f5f7088d935830a6a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/371614
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
When we set a timeout, we don't actually have a guarantee one how long
the OS will take to notice it. Moreover, if the test deadlocks
completely (for example, due to a deadline never taking effect), it
would be more useful to get a full goroutine dump instead of the current
"client stuck in Dial+Copy" failure message.
For #37883
For #41863
Change-Id: I9f712ef1c620f97a5ab69baac45deb71134b99bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/371994
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>
Prior to unions, unary and binary expressions always had a recorded
type. Preserve this by recording a type for all unary and binary
expressions encountered while parsing a union type.
Updates #50093
Change-Id: I5ba20f37854760596350d91ea325dc98e67e115a
Reviewed-on: https://go-review.googlesource.com/c/go/+/371757
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>
Move calculated type sets for unions into a map, rather than storing
them on the Union type.
Type sets for unions only matter during calculation of interface type
sets, and to a lesser extent inside of Identical. The latter should not
be encountered during type checking, as Identical uses the precomputed
interface type set when comparing interfaces, and unions do not arise
outside of interface types.
Removing the tset field from Union potentially frees up memory, and
eliminates a source of races via calls to NewUnion and Identical. It
also sets the stage for recording Unions for every subexpression of
union terms, which preserves an existing invariant that BinaryExprs and
UnaryExprs should have a recorded type.
Updates #50093
Change-Id: I5956fa59be6b0907c3a71faeba9fa5dd8aae0d65
Reviewed-on: https://go-review.googlesource.com/c/go/+/371756
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>
This test has worked since CL 165801 (committed March 12, 2019), so
stop skipping it. With this, we check that Close makes concurrent I/O
operations on pipes return Errclosed on all platforms.
Updates #19093.
Change-Id: Ic090c70996c115abf80d8f9b93ca2aeaf347c9d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/371016
Trust: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This works around what appears to be either a kernel bug or a Go
runtime or syscall bug affecting certain Windows versions
(possibly all pre-2016?).
The retry loop is a simplified version of the one used in
cmd/go/internal/robustio. We use the same 2-second arbitrary timeout
as was used in that package, since it seems to be reliable in practice
on the affected builders. (If it proves to be too short, we can
lengthen it, within reason, in a followup CL.)
Since this puts a higher-level workaround in place, we can also revert
the lower-level workaround added to a specific test in CL 345670.
This addresses the specific occurrences of the bug for users of
(*testing.T).TempDir, but does not fix the underlying bug for Go users
outside the "testing" package (which remains open as #25965).
Fixes#50051
Updates #48012
Updates #25965
Change-Id: I35be7125f32f05c8350787f5ca9a22974b8d0770
Reviewed-on: https://go-review.googlesource.com/c/go/+/371296
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
Trust: Patrik Nyblom <pnyb@google.com>
Run-TryBot: Patrik Nyblom <pnyb@google.com>
Fixes go test -gcflags=all=-G=0 -short std,
except for the packages with generics in their tests
(constraints, encoding/xml), and except for the
go/internal/gcimporter and go/types tests,
because the compiler does not preserve any
in its -G=0 export information.
(That's probably acceptable for now.)
Fixes cd test/; GO_BUILDER_NAME=longtest go run run.go
completely, which should fix the longtest builder.
Fixes#50159.
Change-Id: I9390972239c18831833edd6530191da2842b876b
Reviewed-on: https://go-review.googlesource.com/c/go/+/371715
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We delay all transformations on generic functions, and only do them on
instantiated functions, for several reasons, of which one is that
otherwise the compiler won't understand the relationship between
constrained type parameters. In an instantiation with shape arguments,
the underlying relationship between the type arguments are clear and
don't lead to compiler errors.
This issue is because I missed delaying assignment transformations for
variable declarations. So, we were trying to transform an assignment,
and the compiler doesn't understand the relationship between the T and U
type parameters.
The fix is to delay assignment transformations for variable declarations
of generic functions, just as we do already for normal assignment
statements.
A work-around for this issue would be to just separate the assignment
from the variable declaration in the generic function (for this case of
an assignment involving both of the constrained type parameters).
Fixes#50147
Change-Id: Icdbcda147e5c4b386e4715811761cbe73d0d837e
Reviewed-on: https://go-review.googlesource.com/c/go/+/371534
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
We can import an shape-instantiated function/method for inlining
purposes. If we are instantiating the methods of a instantiated type
that we have seen, and it happens to need a shape instantiation that we
have imported, then don't re-create the instantiation, since we will end
up with conflicting/duplicate definitions for the instantiation symbol.
Instead, we can just use the existing imported instantation, and enter
it in the instInfoMap[].
Fixes#50121
Change-Id: I6eeb8786faad71106e261e113048b579afad04fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/371414
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
A "RET f(SB)" wasn't assembled correctly in a leaf function with
non-zero frame size. Follows CL 371034, for MIPS(32/64)(be/le)
and S390X. Other architectures seem to do it right. Add a test.
Change-Id: I41349a7ae9862b924f3a3de2bcb55b782061ce21
Reviewed-on: https://go-review.googlesource.com/c/go/+/371214
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
h2_bundle.go is automatically generated from x/net/http2. Any
formatting changes within that file need to be first made upstream.
This brings the contents of h2_bundle.go back in line with the
upstream generator, fixing the cmd/internal/moddeps test that is
currently failing on the longtest builders.
For #49884
Change-Id: I5757240b77e250e0026b8a52a0e867e1578ec2d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/371297
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fix up a unit test to make it more friendly for coverage runs.
Currently on tip if you do
cd ${GOROOT}/src ; go test -cover cmd/compile/...
it will cause a failure in the TestGoAMD64v1 testpoint of
cmd/compile/internal/amd64, the reason being that this testpoint
copies and reruns the test executable, expecting the rerun to produce
only the output "PASS", whereas if "-cover" is used, the output will
include percentage of statements covered as well. To fix, rework the
test to tolerate additional output if coverage is enabled.
Change-Id: I2512e06ca06e5f38108f2891ff84276d148c4f9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/371234
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Although most of the code seems to be already implemented
to support this for general use, it didn't make it in for
Go 1.18, so for now we should at least document that it's
only for use by the go command.
Change-Id: Id559e72d590aedeaaa50bcf880bca1a385d858dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/370954
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
And then revert the bootstrap cmd directories and certain testdata.
And adjust tests as needed.
Not reverting the changes in std that are bootstrapped,
because some of those changes would appear in API docs,
and we want to use any consistently.
Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories
when preparing the bootstrap copy.
A few files changed as a result of running gofmt -w
not because of interface{} -> any but because they
hadn't been updated for the new //go:build lines.
Fixes#49884.
Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09
Reviewed-on: https://go-review.googlesource.com/c/go/+/368254
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
As written, the conversion P(x), where P and the type
of x are type parameters with identical underlying types
(i.e., identical constraints), is valid. However, unless
the type of x and P are identical (which is covered with
the assignability rule), such a conversion is not valid
in general (consider the case where both type parameters
are different type parameters with constraint "any").
This change adjusts the rules to prohibit type parameters
in this case. The same reasoning applies and the analogue
change is made for pointer types.
The type checker already implements these updated rules.
Change-Id: Id90187900cb2820f6a0a0cf582cf26cdf8addbce
Reviewed-on: https://go-review.googlesource.com/c/go/+/371074
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test cases for this test had listed specific errors, but the
specific error values were ignored in favor of just calling
isDeadlineExceeded.
Moreover, ENOBUFS errors (which can legitimately occur in the test if
the network interface also happens to be saturated when the timeout
occurs) were not handled at all.
Now the test relies only on the timeout: we iterate until we have seen
two of the expected timeout errors, and if we see ENOBUFS instead of
"deadline exceeded" we back off to give the queues time to drain.
Fixes#49930
Change-Id: I258a6d5c935d9635b02dffd79e197ba9caf83ac8
Reviewed-on: https://go-review.googlesource.com/c/go/+/370882
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change applies the same transformation as in CL 366774,
but to the net package.
testUnixAddr was using os.CreateTemp to obtain a unique socket path,
but then calling os.Remove on that path immediately. Since the
existence of the file is what guarantees its uniqueness, that could
occasionally result in testUnixAddr returning the same path for two
calls, causing the tests using those paths to fail — especially if
they are the same test or are run in parallel.
Instead, we now create a unique, short temp directory for each call,
and use a path within that directory for the socket address.
For #34611
Change-Id: I8e13b606abce2479a0305f7aeecf5d54c449a032
Reviewed-on: https://go-review.googlesource.com/c/go/+/370694
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Passing in an explicit testing.TB gives two benefits:
1. It allows the helper to fail the test itself, instead of returning
an error to the caller. A non-nil error invariably fails the
calling test, and none of these callers bother to add detail to the
error when logging it anyway so returning the error just added
noise to the test bodies.
2. It allows the helper to use t.Cleanup to perform any needed cleanup
tasks, which will be used in CL 370695 to clean up temp directories
used as namespaces for unix socket paths.
For #34611
Change-Id: I805e701687c12de2caca955649369294229c10b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/370696
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In some leaf functions using "RET foo(SB)", the jump may be incorrectly
translated into "JMP LR" instead of "JMP foo(SB)".
Such is the case when compiling the autogenerated function in k8s
k8s.io/kubernetes/pkg/kubelet/server/stats.(*resourceAnalyzer).GetPodVolumeStats.
Fixes#50048
Change-Id: Icdf65fcda6b3c5eb9d3ad5c7aad04add9419dffb
Reviewed-on: https://go-review.googlesource.com/c/go/+/371034
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Paul Murphy <murp@ibm.com>
The exact error isn't actually relevant to the test,
and may depend on whether the Go or cgo resolver is used.
Also run the test in parallel, because it spends most of its time
sleeping in between lookups.
Fixes#38767Fixes#43140
Change-Id: I2d64ffddf2eb114a69ed3242daa9a9e4a5679f67
Reviewed-on: https://go-review.googlesource.com/c/go/+/369037
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>
TestUnixAndUnixpacketServer deferred a call to os.Remove on the local
address of a dialed unix domain socket, in an attempt to remove the
socket from the server. However, that call appears to be neither
necessary nor correct.
In this test, the file that needs to be unlinked is the one attached
to the listener — but the listener's Close method already does that
(see the Unlink call in (*UnixListener).close), so there is no need
for the test itself to do the same.
Moreover, the local address is not something that is sensible to
delete — on Linux, it is empirically always the literal string "@" —
and the Addr returned by c.LocalAddr is not reliably non-nil on all
platforms (see #34611).
Since we don't need to do anything with the local address, we shouldn't.
At best, this is a benign Remove of a file that doesn't exist anyway;
at worst, it is a nil-panic.
Fixes#34611
Change-Id: Ie072b3388d884d60e819d1df210fa7d3e2eed124
Reviewed-on: https://go-review.googlesource.com/c/go/+/370695
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>
TestListenerClose had been asserting that a Dial to the newly-closed
address always fails, on the assumption that the listener's address
and port would not be reused by some other listener that could then
accept the connection.
As far as I can tell, that assumption is not valid: the Dial after
Close may well connect to a Listener opened for some other test, or
even one opened by a completely different process running concurrently
on the same machine.
Fixes#38700
Change-Id: I925ed1b2ccb556135a2c5be0240d1789ed27d5fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/370666
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>
In identical(), we don't want any to match a shape empty-interface type
for the identStrict option, since IdenticalStrict() is specifically not
supposed to match a shape type with a non-shape type.
There is similar code in (*Type).cmp() (TINTER case), but I don't
believe that we want to disqualify shape types from matching any in this
case, since cmp() is used for back-end code, where we don't care about
shape types vs non-shape types.
The issue mainly comes about when 'any' is used as a type argument
(rather than 'interface{}'), but only with some complicated
circumstances, as shown by the test case. (Couldn't reproduce with
simpler test cases.)
Fixes#50109
Change-Id: I3f2f88be158f9ad09273237e1d346bc56aac099f
Reviewed-on: https://go-review.googlesource.com/c/go/+/371154
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently, File.Close only documents that "an" error will be returned
by pending I/O operations. Update the documentation to say that error
is specifically ErrClosed.
Change-Id: Ica817c9196ad6cb570c826789d37a4ff15a5d13d
Reviewed-on: https://go-review.googlesource.com/c/go/+/371015
Trust: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes testenv.RunWithTimeout first attempt to SIGQUIT the
subprocess to get a useful Go traceback, but if that doesn't work, it
sends a SIGKILL instead to make sure we tear down the subprocess. This
is potentially important for non-Go subprocesses.
For #37405.
Change-Id: I9e7e118dc5769ec3f45288a71658733bff30c9cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/370702
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This lifts the logic to run a subcommand with a timeout in a test from
the runtime's runTestProg into testenv. The implementation is
unchanged in this CL. We'll improve it in a future CL.
Currently, tests that run subcommands usually just timeout with no
useful output if the subcommand runs for too long. This is a step
toward improving this.
For #37405.
Change-Id: I2298770db516e216379c4c438e05d23cbbdda51d
Reviewed-on: https://go-review.googlesource.com/c/go/+/370701
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
cmd/vet has several precision improvements for the checkers copylock, printf, sortslice, testinggoroutine, and tests. Adds a high level mention in the release notes and an example of string constant concatenation.
Updates #47694
Change-Id: I7a342a57ca3fd9e2f3e8ec99f7b647269798317f
Reviewed-on: https://go-review.googlesource.com/c/go/+/370734
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Tim King <taking@google.com>
Run-TryBot: Tim King <taking@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When exporting the "any" empty interface type for unified IR, write it
out as a reference to the "any" alias, rather than to the underlying
empty interface. This matches how "byte" and "rune" are handled.
Verified to fix the issue demonstrated in CL 369975.
Change-Id: Ic2844b0acc3b17c20b3a40aaf262f62ec653eb5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/370374
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The "-2008" builders are the only ones on which the failure has
been observed, so I suspect that it is due to a platform bug fixed in a
subsequent release.
Since no one has added a workaround since #19564 was filed over four
years ago, I'm assuming that no workaround is planned for this issue.
Let's add a skip for the known failure mode and call it at that.
Fixes#19564
Change-Id: Iefc22d1cc78bfdc79c845eb60cac22e26caf388c
Reviewed-on: https://go-review.googlesource.com/c/go/+/370377
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TestLabelSystemstack needs to collect samples within runtime.systemstack
to complete the test.
The current approach uses fmt.Fprintf, which gets into systemstack
through the allocator and GC, but also does lots of other work. In my
measurements, approximately 2% of samples contain runtime.systemstack.
The new approach uses debug.SetGCPercent, which uses systemstack for
most of its work, including contention on mheap_.lock, which extends
usage even more. In my measurements, approximately 99% of samples
contain runtime.systemstack.
Fixes#50050
Change-Id: I59e5bb756341b716a12e13d2e3fe0adadd7fe956
Reviewed-on: https://go-review.googlesource.com/c/go/+/370375
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We currently run one 'go list' invocation per GOMAXPROC. Since the go
command uses memory and has its own internal parallelism, that's
unlikely to be an efficient use of resources. Run half as many. I
suspect that's still too many but this should fix our OOMs.
For #49957.
Change-Id: Id06b6e0f0d96387a2a050e400f38bde6ba71aa60
Reviewed-on: https://go-review.googlesource.com/c/go/+/370376
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
golang.org/cl/365234 incorrectly had pruningForGoVersion always return
workspace pruning instead of just returning workspace pruning at the top
level, which broke the proper determination of pruning for dependency
packages. Fix that code, and also fix a hang that resulted because the
module loading code keeps loading dependencies until it reaches a pruned
module or an unpruned module it already saw, so it could get stuck in a
cycle.
Change-Id: I8911f7d83aaee5870c43ef0355abbd439f15d4f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/366775
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Our calculation of initOrder builds the dependency graph and then
removes function nodes approximately at random. While profiling, I
noticed that this latter step introduces a superlinear algorithm into
our type checking pass, which can dominate type checking for large
packages such as runtime.
It is hard to analyze this rigorously, but to give an idea of how such a
non-linearity could arise, suppose the following assumptions hold:
- Every function makes D calls at random to other functions in the
package, for some fixed constant D.
- The number of functions is proportional to N, the size of the package.
Under these simplified assumptions, the cost of removing an arbitrary
function F is P*D, where P is the expected number of functions calling
F. P has a Poisson distribution with mean D.
Now consider the fact that when removing a function F in position i, we
recursively pay the cost of copying F's predecessors and successors for
each node in the remaining unremoved subgraph of functions containing F.
With our assumptions, the size of this subgraph is proportional to
(N-i), the number of remaining functions to remove.
Therefore, the total cost of removing functions is proportional to
P*D*Σᴺ(N-i)
which is proportional to N².
However, if we remove functions in ascending order of cost, we can
partition by the number of predecessors, and the total cost of removing
functions is proportional to
N*D*Σ(PMF(X))
where PMF is the probability mass function of P. In other words cost is
proportional to N.
Assuming the above analysis is correct, it is still the case that the
initial assumptions are naive. Many large packages are more accurately
characterized as combinations of many smaller packages. Nevertheless, it
is intuitively clear that removing expensive nodes last should be
cheaper.
Therefore, we sort by cost first before removing nodes in
dependencyGraph.
We also move deletes to the outer loop, to avoid redundant deletes. By
inspection, this avoids a bug where n may not have been removed from its
successors if n had no predecessors.
name old time/op new time/op delta
Check/runtime/funcbodies/noinfo-8 568ms ±25% 82ms ± 1% -85.53% (p=0.000 n=8+10)
name old lines/s new lines/s delta
Check/runtime/funcbodies/noinfo-8 93.1k ±56% 705.1k ± 1% +657.63% (p=0.000 n=10+10)
Updates #49856
Change-Id: Id2e70d67401af19205e1e0b9947baa16dd6506f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/369434
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>
Preparation for #44505, but safe for Go 1.18.
Also fixes the default build on Macs, at least for
people who have a $HOME/go1.17 or have run
go install golang.org/dl/go1.17@latest
go1.17 download
Replay of CL 369914 after revert in CL 370138.
Only change is adding 'export GOROOT_BOOTSTRAP' in make.bash.
Change-Id: I8ced4e87a9dc0f05cc49095578b401ae6212ac85
Reviewed-on: https://go-review.googlesource.com/c/go/+/370274
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If the test's main goroutine receives a SIGPROF while creating the
C-owned thread for the test, that sample will appear in the resulting
profile. The root end of that stack will show a set of Go functions. The
leaf end will be the C functions returned by the SetCgoTraceback
handler, which will confuse the test runner.
Add a label to the main goroutine while it calls in to C, so all profile
samples that triggered the SetCgoTraceback handler are either correct,
or can easily be excluded from the test's analysis. (The labels will not
apply to the resulting C-owned thread, which does not use goroutines.)
Fixes#43174
Change-Id: Ica3100ca0f191dcf91b30b0084e8541c5a25689f
Reviewed-on: https://go-review.googlesource.com/c/go/+/370135
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
As a side effect of the changes in cmd/go/internal/work in CL 369977,
binaries built in GOPATH mode now include rudimentary build metadata
for at least the package path and compiler in use.
That seems like a strict improvement, but the test needs to be updated
to reflect the newly-available metadata.
Change-Id: I657c785e3e9992ed594c9524409f2d076f9eb376
Reviewed-on: https://go-review.googlesource.com/c/go/+/370234
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>
Reviewed-by: Cherry Mui <cherryyz@google.com>
With https://golang.org/issue/50007 resolved, there are no known issues
with pprof labels remaining. Thus, the 10% allowed error in
TestLabelSystemstack should not be required.
Drop it in favor of an explicit assertion that all samples containing
labelHog are properly labeled.
This is no flaky in my local testing. It is possible that other bugs
will appear at larger testing scale, in which case this CL will be
reverted, but then at least we will be aware of additional failure
modes.
For #50007.
Change-Id: I1ef530c303bd9a01af649b8b08d4b35505e8aada
Reviewed-on: https://go-review.googlesource.com/c/go/+/369744
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
profBuf.write uses an index in b.tags for each entry, even if that entry
has no tag (that slice entry just remains 0). profBuf.read similarly
returns a tags slice with exactly as many entries as there are records
in data.
profileBuilder.addCPUData iterates through the tags in lockstep with the
data records. Except in the special case of the first record, where it
forgets to increment tags. Thus the first read of profiling data has all
tags off-by-one.
To help avoid regressions, addCPUData is changed to assert that tags
contains exactly the correct number of tags.
For #50007.
Change-Id: I5f32f93003297be8d6e33ad472c185d924a63256
Reviewed-on: https://go-review.googlesource.com/c/go/+/369741
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>
Deal with case where a certain instantiation of a generic
function/method leads to an unsatisfiable type assertion or type case.
In that case, the compiler was causing a fatal error while trying to
create an impossible itab for the dictionary. To deal with that case,
allow ITabLsym() to create a dummy itab even when the concrete type
doesn't implement the interface. This dummy itab is analogous to the
"negative" itabs created on-the-fly by the runtime.
We will use the dummy itab in type asserts and type switches in
instantiations that use that dictionary entry. Since the dummy itab can
never be used for any real value at runtime (since the concrete type
doesn't implement the interface), there will always be a failure for the
corresponding type assertion or a non-match for the corresponding
type-switch case.
Fixes#50002
Change-Id: I1df05b1019533e1fc93dd7ab29f331a74fab9202
Reviewed-on: https://go-review.googlesource.com/c/go/+/369894
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously, if an unrecoverable error occurred during
minimization, then the input that caused the failure
could not be retrieved by the coordinator. This was fine
if minimizing a crash, since the coordinator could simply
report the original error, and ignore the new one.
However, if an error occurred while minimizing an
interesting input, then we may lose an important error
that would be better to report.
This changes is a pretty major refactor of the minimization
logic in order to support this. It removes minimization
support of all types except []byte and string. There isn't
compelling evidence that minimizing types like int or float64
are actually beneficial, so removing this seems fine.
With this change, the coordinator requests that the worker
minimize a single value at a time. The worker updates shared
memory directly during minimzation, writing the *unmarshaled*
bytes to the shared memory region. If a nonrecoverable error occurs
during minimization, then the coordinator can get the
unmarshaled value out of shared memory for that type being
minimized.
Fixes#48731
Change-Id: I4d1d449c411129b3c83b148e666bc70f09e95828
Reviewed-on: https://go-review.googlesource.com/c/go/+/367848
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reading the version information to date has required evaluating
two pointers to strings (which themselves contain pointers to data),
which means applying relocations, which can be very system-dependent.
To simplify the lookup, inline the string data into the build info blob.
This makes go version work on binaries built with external linking
on darwin/arm64.
Also test that at least the very basics work on a trivial binary,
even in short mode.
Change-Id: I463088c19e837ae0ce57e1278c7b72e74a80b2c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/369977
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Preparation for #44505, but safe for Go 1.18.
Also fixes the default build on Macs, at least for
people who have a $HOME/go1.17 or have run
go install golang.org/dl/go1.17@latest
go1.17 download
Change-Id: I822f93e75498620fad87db2436376148c42f6bff
Reviewed-on: https://go-review.googlesource.com/c/go/+/369914
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test fails with "timeout" once per couple of months.
It may be that the arbitrary timeout is too short,
or it may be that the test is detecting a real bug
(perhaps a deadlock) and reporting it without sufficient
information to debug.
Either way, the arbitrary timeout is doing only harm:
either it is too short, or it is preventing us from getting
a useful goroutine dump when the test inevitably times out.
Fixes#35498 (hopefully).
Change-Id: Ic6bbb1ef8df2c111b9888ba9903f58633e7cb95d
Reviewed-on: https://go-review.googlesource.com/c/go/+/369854
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: Damien Neil <dneil@google.com>
Fixes for #49680, #49695, #45867, and #49370 all assumed that
SetGCPercent(-1) doesn't block until the GC's mark phase is done, but
it actually does. The cause of 3 of those 4 failures comes from the fact
that at the beginning of the sweep phase, the GC does try to preempt
every P once, and this may run concurrently with test code. In the
fourth case, the issue was likely that only *one* of the debug_test.go
tests was missing a call to SetGCPercent(-1). Just to be safe, leave a
TODO there for now to remove the extraneous runtime.GC calls, but leave
the calls in.
Updates #49680, #49695, #45867, and #49370.
Change-Id: Ibf4e64addfba18312526968bcf40f1f5d54eb3f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/369815
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 358539 revised the build-stamp format, and updated the git and hg
tests to match. However, the fossil and bzr tests were missed, and
were not caught on the builders due to the fact that none of the
builder images have the necessary VCS tools installed.
Updates #48802
Updates #49168
Change-Id: I6b9fd0e19b81cb539864c94ab0860f74e7be6748
Reviewed-on: https://go-review.googlesource.com/c/go/+/369743
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
'man getsockname' lists a number of possible failure modes, including
ENOBUFS (for resource exhaustion) and EBADF (which we could possibly
see in the event of a bug or race condition elsewhere in the program).
If getsockname fails for an explicit user-provided local address, the
user is probably not expecting LocalAddr on the returned net.Conn to
return nil. This may or may not fix#34611, but should at least help
us diagnose it more clearly.
While we're add it, also add more nil-checking logic in the test based
on the stack traces posted to
https://golang.org/issue/34611#issuecomment-975923748.
For #34611
Change-Id: Iba870b96787811e4b9959b74ef648afce9316602
Reviewed-on: https://go-review.googlesource.com/c/go/+/366536
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>
SetGCPercent(-1) is called by several tests in debug_test.go (followed
by a call to runtime.GC) due to #49370. However, startDebugCallWorker
already actually has this, just without the runtime.GC call (allowing an
in-progress GC to still mess up the test).
This CL consolidates SetGCPercent into startDebugDebugCallWorker where
applicable.
Change-Id: Ifa12d6a911f1506e252d3ddf03004cf2ab3f4ee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/369751
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
These tests disable GC because of the potential for a deadlock, but
don't consider that a GC could be in progress due to other tests. The
likelihood of this case was increased when the minimum heap size was
lowered during the Go 1.18 cycle. The issue was then mitigated by
CL 368137 but in theory is always a problem.
This change is intended specifically for #45867, but I just walked over
a whole bunch of other tests that don't take this precaution where it
seems like it could be relevant (some tests it's not, like the
UserForcedGC test, or testprogs where no other code has run before it).
Fixes#45867.
Change-Id: I6a1b4ae73e05cab5a0b2d2cce14126bd13be0ba5
Reviewed-on: https://go-review.googlesource.com/c/go/+/369747
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
startServer was invoking os.Remove on the temporary file for a unix
socket after creating it. Since the files were created in the global
temp directory, that could cause two tests to arrive at colliding
names.
(Noticed while looking into the failure at
https://storage.googleapis.com/go-build-log/af2c83b1/solaris-amd64-oraclerel_3e01fda8.log,
but I would be surprised if this solves that failure.)
This change uses unique temporary directories, and attempts to keep
name lengths minimal to avoid accidentally running into socket-name
length limitations.
Updates #34611
Change-Id: I21743f245e5c14645e03f09795013e058b984471
Reviewed-on: https://go-review.googlesource.com/c/go/+/366774
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>
This CL reorders the bullet points in the generics section to more
closely match what I think users will consider most important. I put
the ~ token before the mention of ~T in interfaces to avoid a forward
reference, though I wonder if we actually want to spent a couple more
sentences saying what union and ~T types are, since most people are
going to care about that a lot more than they care about the low-level
detail that there's a new token.
For #47694.
Change-Id: Ib84f096ef6346a711801268ce362b64fa423d3f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/369734
Trust: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
To prevent interleaving of output when 'go build' compiles several
packages in parallel, the output mutex in the Builder struct must
be locked around any calls to Builder.Print which could generate
arbitrary amounts of text (ie more than is guaranteed to be written
atomically to a pipe).
Fixes#49987
For #49338
Change-Id: I7947df57667deeff3f03f231824298d823f8a943
Reviewed-on: https://go-review.googlesource.com/c/go/+/369018
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Russ Cox <rsc@golang.org>
In iOS <14, the address space is strictly limited to 8 GiB, or 33 bits.
As a result, the page allocator also assumes all heap memory lives in
this region. This is especially necessary because the page allocator has
a PROT_NONE mapping proportional to the size of the usable address
space, so this keeps that mapping very small.
However starting with iOS 14, this restriction is relaxed, and mmap may
start returning addresses outside of the <14 range. Today this means
that in iOS 14 and later, users experience an error in the page
allocator when a heap arena is mapped outside of the old range.
This change increases the ios/arm64 heapAddrBits to 40 while
simultaneously making ios/arm64 use the 64-bit pagealloc implementation
(with reservations and incremental mapping) to accommodate both iOS
versions <14 and 14+.
Once iOS <14 is deprecated, we can remove these exceptions and treat
ios/arm64 like any other arm64 platform.
This change also makes the BaseChunkIdx expression a little bit easier
to read, while we're here.
Fixes#46860.
Change-Id: I13865f799777739109585f14f1cc49d6d57e096b
Reviewed-on: https://go-review.googlesource.com/c/go/+/344401
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
This CL updates "go help doc" docs so they reflect the following
changes:
- CL 59413 modified "go doc", so the behavior of the two-args case is
consistent with the one-arg one.
- CL 141397 removed godoc's command-line interface in favor of "go doc".
Fixes#49830.
Change-Id: I0923634291d34ae663fe2944d69757462b814919
Reviewed-on: https://go-review.googlesource.com/c/go/+/367497
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Russ Cox <rsc@golang.org>
Update the vendored x/sys to pick up CL 368994, which remove the
declaration of function darwinSupportsAVX512 in cpu/cpu_gc_x86.go.
The following commands were used:
go get -d golang.org/x/sys@97ca703d548df069cb02aacea9efc3093ffdc3c4
go mod tidy
go mod vendor
Fixes#49942
Change-Id: I05162a051f572bf8599be198a6033384b7d19445
Reviewed-on: https://go-review.googlesource.com/c/go/+/369454
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Enable a bunch of types2-related error tests to run successfully, so
they no longer have to be disabled in run.go.
- directive.go: split it into directive.go and directive2.go, since the
possible errors are now split across the parser and noder2, so they
can't all be reported in one file.
- linkname2.go: similarly, split it into linkname2.go and linkname3.go
for the same reason.
- issue16428.go, issue17645.go, issue47201.dir/bo.go: handle slightly
different wording by types2
- issue5609.go: handle slight different error (array length must be
integer vs. array bound too large).
- float_lit3.go: handle slightly different wording (overflows
float vs cannot convert to float)
I purposely didn't try to fix tests yet where there are extra or missing
errors on different lines, since that is not easy to make work for both
-G=3 and -G=0. In a later change, will flip to make the types2 version
match correctly, vs. the -G=0 version.
Change-Id: I6079ff258e3b90146335b9995764e3b1b56cda59
Reviewed-on: https://go-review.googlesource.com/c/go/+/368455
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Use gp.m.curg instead of the gp when recording cpu profiler stack
traces. This ensures profiler labels are captured when systemstack or similar
is executing on behalf of the current goroutine.
After this there are still rare cases of samples containing the labelHog
function, so more work might be needed. This patch should fix ~99% of the
problem.
Also change testCPUProfile interface a little to allow the new test to
re-run with a longer duration if it fails during a -short run.
Fixes#48577.
Change-Id: I3dbc9fd5af3c513544e822acaa43055b2e00dfa9
Reviewed-on: https://go-review.googlesource.com/c/go/+/367200
Trust: Michael Pratt <mpratt@google.com>
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
On macOS 12 a new malloc implementation (nano) is used by default,
and apparently it reserves address range
0x600000000000-0x600020000000, which conflicts with the address
range that TSAN uses for Go. Work around the issue by changing the
address range slightly.
The actual change is made on LLVM at https://reviews.llvm.org/D114825 .
This CL includes syso's built with the patch applied.
Fixes#49138.
Change-Id: I7b367d6e042b0db39a691c71601c98e4f8728a70
Reviewed-on: https://go-review.googlesource.com/c/go/+/367916
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
CL 205237 allowed SSL_CERT_DIR to be a colon delimited list of
directories. In the case that SSL_CERT_DIR is unset, the change
also made certDirectories to all be loaded rather than stopping
after successfully reading at least one file from a directory.
This update fixes code comments on the certDirectories package
level variables to reflect current behavior.
Fixes#48808
Change-Id: Id92f875545272fc6205d9955d03ea7bf844f15eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/354140
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Katie Hockman <katie@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Katie Hockman <katie@golang.org>
First, we need to set base.Pos in varDecl() and typeDecl(), so it will
be correct if we need to report type size errors while converting types.
Changed error calls in types/sizes.go to use Errorf, not ErrorfAt, since
we want to use base.Pos (which will set from t.Pos(), if that is
available).
Second, we need to add an extra call CalcSize(t1.Elem()) in the
TCHANARGS case of CalcSize(). We can use CalcSize() rather than
CheckSize(), since we know the top-level recursive type will have been
calculated by the time we process the fake TCHANARGS type. In -G=0 mode,
the size of the channel element has often been calculated because of
some other processing (but not in the case of #49767). But in -G=3 mode,
we just calculate sizes during the single noder2 pass, so we are more
likely to have not gotten to calculating the size of the element yet,
depending on the order of processing of the deferredTypeStack.
Fixes the tests fixedbugs/issue{42058a,42058b}.go that were
disabled for -G=3 mode.
Had to add exceptions in stdlib_test.go for go/types and types2, because
the types2 typechecker does not know about type size limits.
Fixes#49814Fixes#49771
Updates #49767
Change-Id: I77d058e8ceff68a58c4c386a8cf46799c54b04c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/367955
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Update the vendored x/tools to pick up CL 364678, which updates vet
analyzers following a change to the underlying of type parameters.
This also pulls in significant changes to the typeutil package to
support new constructs in typeutil.Map, but this is not used by vet.
The following commands were used:
go get -d golang.org/x/tools@e212aff8fd146c44ddb0167c1dfbd5531d6c9213
go mod tidy
go mod vendor
Fixes#49855
Change-Id: I3ffc59f3693710c83b81d390999aeabc8043723b
Reviewed-on: https://go-review.googlesource.com/c/go/+/368774
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The new minimum heap of 512 KiB has been the cause of some build
slowdown (~1%) and microbenchmark slowdown (usually ~0%, up to ~50%)
because of two reasons:
1. Applications with lots of small short-lived processes execute many
more GC cycles.
2. Applications with heaps <4 MiB GC up to 8x more often.
In many ways these consequences are inevitable given how GOGC works,
however we need to investigate more as to whether the apparent slowdowns
are indeed unavoidable or if the GC has issues scaling down, which it's
too late for for this release.
Given that this release is already huge, it's OK to push this back.
We'll take a closer look at it next cycle, so place block it behind a
new goexperiment to allow users and ourselves to easily experiment with
it.
Fixes#49744.
Updates #44167.
Change-Id: Ibad51f7873de7517490c89802f3c593834e77ff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/368137
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
When we set g.curDecl for the type params created during fillinMethods
for an instantiated type, we need to save/restore its value, because
fillinMethods() may be called while processing a typeDecl. We want the
value of g.curDecl to continue to be correct for type params created in
the typeDecl. Because of ordering issues, not restoring g.curDecl
happens to cause problems (which don't always show up visibly) exactly
when a type param is not actually used in a type declaration.
Cleared g.curDecl to "" at the later points in typeDecl() and
funcDecl(). This allows adding asserts that g.curDecl is always empty
("") when we set it in typeDecl() and funcDecl(), and always non-empty
when we use it in typ0().
Fixes#49893
Change-Id: Ic2fb1df791585bd257f2b86ffaae0453c31705c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/368454
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When TestPacketConn was added (in CL 6501057) it included arbitrary
100ms deadlines. Those deadlines were arbitrarily increased to 500ms
in CL 4922.
If the test is actually provoking a deadlock, allowing it to deadlock
will give us a more useful goroutine dump. Otherwise, the deadlines
don't seem all that useful — they appear to increase code coverage,
but have no effect on the test in the typical case, and can only
cause flakes on particularly-slow machines.
For #43627
Change-Id: I83de5217c54c743b83adddf51d4f6f2bd5b91732
Reviewed-on: https://go-review.googlesource.com/c/go/+/368215
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If this test fails, we want to know exactly what the os/exec
goroutines are doing. Panicking gives us a goroutine dump,
whereas t.Fatal does not.
While we're here, use exponential backoff instead of a hard-coded 1ms
sleep. We want to give the OS enough time to actually terminate the
subprocess.
For #42061
Change-Id: I3d50a71ac314853c68a935218e7f97ce18b08b5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/368317
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We guard against caching or reusing interfaces on the RHS of a type
declaration, because for such interfaces the base type is used as the
interface method receiver type. However, we don't need to do this for
empty interfaces. By refining our guard, we can allow importing the
predeclared 'any' type on the RHS of a type declaration.
Update tests to add more coverage for importing generic export data.
Some accomodation had to be made for the unified builder, which does not
yet fully support generics in export data.
Fixes#49888
Change-Id: I51f329de464fc7309f95991b839ab55868c2924f
Reviewed-on: https://go-review.googlesource.com/c/go/+/367851
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently, markroot is very clever about accessing the allgs slice to
find stack roots. Unfortunately, on weak memory architectures, it's a
little too clever and can sometimes read a nil g, causing a fatal
panic.
Specifically, gcMarkRootPrepare snapshots the length of allgs during
STW and then markroot accesses allgs up to this length during
concurrent marking. During concurrent marking, allgadd can append to
allgs *without synchronizing with markroot*, but the argument is that
the markroot access should be safe because allgs only grows
monotonically and existing entries in allgs never change.
This reasoning is insufficient on weak memory architectures. Suppose
thread 1 calls allgadd during concurrent marking and that allgs is
already at capacity. On thread 1, append will allocate a new slice
that initially consists of all nils, then copy the old backing store
to the new slice (write A), then allgadd will publish the new slice to
the allgs global (write B). Meanwhile, on thread 2, markroot reads the
allgs slice base pointer (read A), computes an offset from that base
pointer, and reads the value at that offset (read B). On a weak memory
machine, thread 2 can observe write B *before* write A. If the order
of events from thread 2's perspective is write B, read A, read B,
write A, then markroot on thread 2 will read a nil g and then panic.
Fix this by taking a snapshot of the allgs slice header in
gcMarkRootPrepare while the world is stopped and using that snapshot
as the list of stack roots in markroot. This eliminates all read/write
concurrency around the access in markroot.
Alternatively, we could make markroot use the atomicAllGs API to
atomically access the allgs list, but in my opinion it's much less
subtle to just eliminate all of the interesting concurrency around the
allgs access.
Fixes#49686.
Fixes#48845.
Fixes#43824.
(These are all just different paths to the same ultimate issue.)
Change-Id: I472b4934a637bbe88c8a080a280aa30212acf984
Reviewed-on: https://go-review.googlesource.com/c/go/+/368134
Trust: Austin Clements <austin@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Issue #27250 reproduced readily enough to keep the subprocess hung
indefinitely when it occurred, so the timeout does not need to be
short to maintain test fidelity. On the other hand, on heavily loaded
systems it might take a while for the kernel to actually start the
subprocess, and it might also take a while for control flow to return
to the test after the subprocess exits.
We can reduce noise from this test in two ways:
1. Measure the timeout from closer to when the subprocess actually
starts sleeping, instead of when we started creating the subprocess.
2. Use a longer timeout, since it doesn't actually need to be short.
Fixes#38921
Updates #27250
Change-Id: I01c11ae82d0cdc6e7def2da6544b4d07201b35e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/367849
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The Linux kernel for riscv64 does not include an sa_restorer field on
its sigaction struct, and expects sa_mask to come immediately after the
sa_flags field. Arrange the fields of the sigaction struct that are
known to the kernel so they appear at the correct byte offsets, and so
they agree with the output of "go tool cgo -godefs".
Follow the example set by the mips/mipsle port to leave the sa_restorer
field in place, but at an offset where it won't hurt anything.
Fixes#49709
Change-Id: I9bb0d7dbd7439d07e3a204461c7d790f33fd4977
Reviewed-on: https://go-review.googlesource.com/c/go/+/367635
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Trust: Ian Lance Taylor <iant@golang.org>
Apparently, on the iOS builder sendfile causes a SIGSYS signal
(instead of returning ENOSYS). Disabling it for now so we can
make progress on iOS. We can revisit if sendfile is actually
broken on iOS and whether it is beneficial.
Updates #49616.
Change-Id: I3883fad0ce35e3f0aa352301eb499a1afa0225a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/368054
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Changkun Ou <mail@changkun.de>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Some critical Version == "" checks were missing in mvs.go, causing
mvs.Req to fail to retain requirements provided by older versions of
main modules.
A few checks also ought to be rotated to put the less expensive
string-equality checks before the more expensive map lookups.
Fixes#48511
Change-Id: Ib8de9d49a6413660792c003866bfcf9ab7f82ee2
Reviewed-on: https://go-review.googlesource.com/c/go/+/368136
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Currently, identical handles any and interface{} by checking against
Types[TINTER]. This is not always true, since when two generated
interface{} types may not use the same *Type instance.
Instead, we must check whether Type is empty interface or not.
Fixes#49875
Change-Id: I28fe4fc0100041a01bb03da795cfe8232b515fc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/367754
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TestSignalIgnoreSIGTRAP is flaky on OpenBSD and the cause is suspected
to be a kernel bug. This test is currently only skipped on the previous
OpenBSD 6.2 and 6.4 builders for #17496. In the meantime the OpenBSD
builders were upgraded to more recent OpenBSD versions (currently 6.8
and 7.0). It seems the issue is still present in these OpenBSD versions
and there is no obvious workaround in Go. Thus, skip the flaky test on
OpenBSD in general.
Updates #17496
Updates #49725
Change-Id: I3577d287dcfaad7a81679db2e71540854fce065a
Reviewed-on: https://go-review.googlesource.com/c/go/+/367115
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Make Settings more closely align with command-line flags
and environment variables.
- Change command-line flags to begin with -
- Change syntax of build lines to use Key=Value instead of Key<tab>Value.
- Change CGO_ENABLED to 0/1, matching environment variable,
instead of false/true.
- Add GOOS and GOARCH.
These are technically redundant, in that they can be extracted
from the binary in other ways most of the time, but not always:
GOOS=ios and GOOS=darwin may produce binaries that are
difficult to tell apart. In any case, it's a lot easier to have them
directly in the settings list than derive them from other parts
of the binary.
- Add GOEXPERIMENT.
These could be inferred from the tags list, but the experiments
are being removed from the tags list.
- Change the tags list to match the -tags command-line argument.
- Add msan and race, echoing the -msan and -race arguments
(always 'true' when present, omitted when false).
- Add GO$GOARCH when set.
Change-Id: Icb59ef4faa5c22407eadd94147b7e53cf4344ce6
Reviewed-on: https://go-review.googlesource.com/c/go/+/358539
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If a GC triggers while spinning in RewindAndSetgid, it may result in
this test hanging. Avoid it by disabling the collector before entering
the uninterruptable ASM conditional wait.
Fixes#49695
Change-Id: Ie0a03653481fb746f862469361b7840f4bfa8b67
Reviewed-on: https://go-review.googlesource.com/c/go/+/365836
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test occasionally hangs on the darwin-arm64-11_0-toothrot
builder. When it does, it fails with the unhelpful error message
"timeout" instead of a useful goroutine dump.
This change eliminates the use of an arbitrary timeout channel, so
that if (and probably when) the test hangs again we will get more
useful logs to diagnose the root cause.
For #49860
Change-Id: I23f6f1c81209f0b2dbe565e1dfb26b1b2eff0187
Reviewed-on: https://go-review.googlesource.com/c/go/+/367615
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When syscall's DLL.FindProc calls into syscall_getprocaddress with a
byte slice pointer, we need to keep those bytes alive. Otherwise the GC
will collect the allocation, and we wind up calling `GetProcAddress` on
garbage, which showed up as various flakes in the builders. It turns out
that this problem extends to many uses of //go:cgo_unsafe_args
throughout, on all platforms. So this patch fixes the issue by keeping
non-integer pointer arguments alive through their invocation in
//go:cgo_unsafe_args functions.
Fixes#49731.
Change-Id: I93e4fbc2e8e210cb3fc53149708758bb33f2f9c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/367654
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
TypeParam.iface may mutate TypeParam.bound in the event that the type
parameter bound is not an interface.
Ensure that iface() is called before the type-checking pass returns, and
before NewTypeParam or TypeParam.SetConstraint exits.
Fixes#49788
Change-Id: I72279acf5f0223161671c04887bc2c3df4158927
Reviewed-on: https://go-review.googlesource.com/c/go/+/367614
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 364874 from types2 to go/types with various
adjustments:
- the error position for "not enough arguments" in calls is the
closing ) rather than the position of the last provided argument
- the ERROR comments in tests are positioned accordingly
- the reg. expression for matching error strings accepts newlines
for the . pattern (added s flag)
For #48834.
For #48835.
Change-Id: I64362ecf605bcf9d89b8dc121432e0131bd5da1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/367196
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is the missing portion of the port of CL 351669
from types2 to go/types, now that we have a local flag
to control for compiler error messages.
Mostly a clean port but for adjustments to error reporting
which requires error codes in go/types.
Prerequisite for port of CL 364874.
Change-Id: I5fc8c83003e4396351f42e9adb08f4ebc8a05653
Reviewed-on: https://go-review.googlesource.com/c/go/+/367195
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TestTinyAllocIssue37262 assumes that all of its allocations will come
from the same tiny allocator (that is, the same P), and that nothing
else will allocate from that tiny allocator while it's running. It can
fail incorrectly if these assumptions aren't met.
Fix this potential test flakiness by disabling preemption during this
test.
As far as I know, this has never happened on the builders. It was
found by mayMoreStackPreempt.
Change-Id: I59f993e0bdbf46a9add842d0e278415422c3f804
Reviewed-on: https://go-review.googlesource.com/c/go/+/366994
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
We want to support some special cases for index expressions, len, and
cap on operands of type parameters (such as indexing a value constrained
by byte slices and strings), hence the extra rules.
Change-Id: I4a07dc7e64bb47361b021d606c52eae1784d5430
Reviewed-on: https://go-review.googlesource.com/c/go/+/366814
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
- fix definition of "specific types" and add more examples
- state that a parameterized function must be instantiated
when used as a function value
- remove duplicate word ("can can" -> "can")
Thanks to @danscales for finding these.
Change-Id: Ideb41efc35a3e67694d3bc97e462454feae37c44
Reviewed-on: https://go-review.googlesource.com/c/go/+/367394
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
As stated in the code, "The builtin package needs special treatment: its
symbols are lower case but we want to see them, always". Thus, cmd/doc
forces the -u flag if the package being queried is called "builtin".
However, this happens after having already parsed the package. This
CL forces the -u flag just after parsing the command arguments and
before parsing any package.
Fixes#49796.
Change-Id: If690a900c7cfd1700feecb9529bd4344c3c249d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/367134
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
This adds support for injecting asynchronous preemption calls on
windows/arm. This code follows sigctxt.pushCall for POSIX OSes
on arm, except we subtract 1 from IP, just as in CL 273727.
Updates #10958.
Updates #24543.
Updates #49759.
Change-Id: Id0c2aed28662f50631b8c8cede3b4e6f088dafea
Reviewed-on: https://go-review.googlesource.com/c/go/+/366734
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
- Thread type argument expressions (rather than posLists) through various
type-checker functions so we can provide a better error position.
- Adjust signatures that expect a syntax.Pos to accept a poser instead
to avoid gratuituous conversions from expressions to positions.
- Rename targsx to xlist so we use xlist consistently for expression
lists.
First step in providing a better error message for the issue below.
For #49179.
Change-Id: I8fc685a2ee4f5640f4abd35568ba32bcb34e9e84
Reviewed-on: https://go-review.googlesource.com/c/go/+/366757
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
If ~T is not permitted because the underlying type of T is not the
same as T, there is no type that satisfies ~T. Besides reporting an
error, also ensure that the corresponding type set is empty.
For #49739.
Change-Id: I127f75f170902e7989f7fe7b352dabda9f72e2a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/366278
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Thanks to emmanuel@orijtech.com who wrote the initial version of
this change (CL 354490).
This change is following CL 354490 in idea but also contains various
simplifications, slightly improved printing of signature/type patterns,
adjustments for types2, and some fine-tuning of error positions.
Also adjusted several ERROR regexp patterns.
Fixes#48834.
Fixes#48835.
Change-Id: I31cf20c81753b1dc84836dbe83a39030ceb9db23
Reviewed-on: https://go-review.googlesource.com/c/go/+/364874
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
This is a port of CL 366276 from types2 to go/types
with minor adjustments due to the slightly different
handling of nil in go/types.
It uses some more detailed error strings in stmt0.src;
the same changes are made to the corresponding types2
file.
For #48852.
Change-Id: I2cdf258799bcbe2d12bbadaf67b8b4504b356bd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/366277
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The notion of specific types will be used to define rules for
assignability, convertability, etc. when type parameters are
involved.
Change-Id: Ic5c134261e2a9fe05cdf25efd342f052458ab5c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/366754
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tests do custom flag processing so we must process the workfile flag
after that happens.
Also fix an issue where errors weren't handled properly when the
workfile wasn't absolute (the go command should just exit), and where a
parse error was just dropped.
Fixes#48576
Change-Id: I3a94d8d3a515114b2c4cc0e73f63447df2fc6bc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/366174
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Tools like objdump uses the pcln table to find the line number of
a given PC. For a PIE binary, at least in some cases such as on
macOS 12 with ld64-711, the table contains unrelocated address,
which does not match the address in the symbol table, causing the
lookup to fail.
In Go 1.18 the pcln table is essentually position independent,
except the start PC. Instead of reading the static content from
the table, use the PC of runtime.text from the symbol table.
While here, change the type of textStart to uint64. What matters
here is the word size of the target program, not the host, so it
shouldn't be uintptr.
Fixes#49700.
Change-Id: I517d79be7ba02dd4dd0275e75a11a136b08d76cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/366695
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This patch revises the fix for issue 46234, fixing a bug that was
accidentally introduced by CL 320913. When inlining a chunk of code
with a closure expression, we want to avoid updating the source
positions in the function being closed over, but we do want to update
the position for the ClosureExpr itself (since it is part of the
function we are inlining). CL 320913 unintentionally did away with the
closure expr source position update; here we restore it again.
Updates #46234.
Fixes#49171.
Change-Id: Iaa51bc498e374b9e5a46fa0acd7db520edbbbfca
Reviewed-on: https://go-review.googlesource.com/c/go/+/366494
Trust: Than McIntosh <thanm@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Accepting SIGURG signals could cause SIGURG to take up the entire
channel buffer.
Enhance the stability of test cases by:
1. Stop accepting the SIGURG signal by adding ‘Reset(sys call.SIGURG)’
2. Close the c1 chan by adding ‘defer Stop(c1)’ (Another bug, NOT this bug)
Fixes#49724
Change-Id: I909a9993f0f6dd109c15e48a861683b87dfc4ab3
Reviewed-on: https://go-review.googlesource.com/c/go/+/366514
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
We want to distinguish special compiler-generated package paths,
like go.shape, from user paths, like go.opentelemetry.io/otel/semconv.
The former have no slash in them.
Writing a test for this seems hard, as the dependency we'd need to
add would be non-hermetic. (Or it would need a new tricky run.go mode.)
This CL does fix the example in the issue.
Fixes#49606
Change-Id: I38f1b970b6dd31e0617763a27ff227e3afee74d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/365834
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This test is slow and resource-intensive, and will rarely catch
failures. It is important to run sometimes, but probably a waste of
time on smaller (and especially reverse) builders.
Rather than hard-coding a list of small builders, only run it on the
longtest builders.
Fixes#35233Fixes#30892Fixes#49753
Change-Id: I25a9702e1f541246ea200fd7c79414ca5f69edae
Reviewed-on: https://go-review.googlesource.com/c/go/+/366538
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently this test makes it clear that it's unsafe for a GC to run,
otherwise a deadlock could occur, so it calls SetGCPercent(-1). However,
a GC may be actively in progress, and SetGCPercent is not going to end
any in-progress GC. Call runtime.GC to block until at least the current
GC is over.
Updates #49680.
Change-Id: Ibdc7d378e8cf7e05270910e92effcad8c6874e59
Reviewed-on: https://go-review.googlesource.com/c/go/+/366534
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When we have a typed nil, we already say so; thus it is sufficient
to use "nil" in all the other cases.
This is closer to (1.17) compiler behavior. In cases where the
1.17 compiler prints "untyped nil" (e.g., wrong uses of "copy"),
we already print a different message. We can do better in those
cases as well; will be addressed in a separate CL (see #49735).
Fixes#48852.
Change-Id: I9a7a72e0f99185b00f80040c5510a693b1ea80f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/366276
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We need VCS status information for each main package we load.
If two main packages are under the same VCS repository,
we can reuse that information to avoid duplicating work.
For instance, the kubernetes holds 51 main packages in its root module,
meaning that "go list ./..." repeated the same git calls 51 times.
Instead, use a global par.Cache to deduplicate that work.
Below are the numbers on kubernetes 5eb584d1cb6917,
via "benchcmd -n 8 KubernetesListPackages go list ./...":
name old time/op new time/op delta
KubernetesListPackages 8.91s ± 0% 3.33s ± 1% -62.61% (p=0.000 n=7+8)
name old user-time/op new user-time/op delta
KubernetesListPackages 11.2s ± 1% 8.1s ± 2% -27.50% (p=0.000 n=7+8)
name old sys-time/op new sys-time/op delta
KubernetesListPackages 8.02s ± 0% 1.67s ± 6% -79.21% (p=0.001 n=6+8)
name old peak-RSS-bytes new peak-RSS-bytes delta
KubernetesListPackages 127MB ± 2% 123MB ± 7% ~ (p=0.328 n=8+8)
Fixes#49582.
Change-Id: Ib7ef5dc7a35c83a11e209441f5d6f3b8da068259
Reviewed-on: https://go-review.googlesource.com/c/go/+/365394
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Dominik Honnef <dominik@honnef.co>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This test spends most of its time sleeping and waiting on a subprocess
to sleep. It seems like a prime candidate to run in parallel, although
we may need to relax its hard-coded 2s timeout on the sleep(1)
subprocess.
For #48770
Change-Id: I4e839739fe82446615f9894c1904c87e5f3cf386
Reviewed-on: https://go-review.googlesource.com/c/go/+/366256
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
It appears that at least the OpenBSD kernel gets sloppier the longer
the timeout we give it, up to an observed overhead of around 25%.
Let's give it a little more than that (33%) in the comparison, and
also increase the growth curve to match the actual observed times
instead of exponential initial growth.
Fixes#36108
Change-Id: Id3e54559b7c45b7c8bc0ca07dce74ca60e77e7ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/366176
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test otherwise fails to build on windows/arm64 as of CL 364774
due to a warning (promoted to an error) about a mismatched dllexport
attribute. Fortunately, it seems not to need the forward-declared
function in this file anyway.
Updates #49633
Updates #49721
Change-Id: Ia4698b85077d0718a55d2cc667a7950f1d8e50ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/366075
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
go work sync panics when there are no workspace modules. This is
because the code that set the pruning mode only did so with modules
present. This change changes pruningForGoVersion to properly return
workspace pruning in workspace mode to prevent that. Another weird
scenario can happen when there are no workspace modules, but the
command-line-arguments module is created by default. Check for that
when iterating over the workspace modules to avoid trying to find the
nonexistant go.mod file for that modules.
Fixes#49591
Change-Id: Iee8bc92a8aaf9c440f88fe4f9ca908a8d461cd36
Reviewed-on: https://go-review.googlesource.com/c/go/+/365234
Trust: Michael Matloob <matloob@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
- add section on type parameters
- added two sections on the scope of type parameters
- expanded general section on types accordingly
- introduced the notion of a named type which will
help in simplifying various rules (subsequent CLs)
Change-Id: I49c1ed7d6d4f951d751f0a3ca5dfb637e49829f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/365414
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These tests were checking for fairly narrow timing windows, but were
running in parallel and heavily dependent on timer and goroutine
scheduling. This change eliminates unnecessary goroutines, runs the
tests sequentially (dramatically shortening the timeouts to reduce the
penalty of doing so), and uses timestamp comparison instead of
background timers to hopefully gain some robustness from monotonic
timestamps.
Many of the other tests from this package would benefit from similar
simplifications, which we can apply if and when we notice flaky
failures or want to improve the latency of running the test.
Fixes#36108
Change-Id: I17d8af7d2eefb1ec14fe0d9d891142a39599a562
Reviewed-on: https://go-review.googlesource.com/c/go/+/365334
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
When reconstructing inputs, we miscalculated the number of mutations
that needed to be applied. If the count%chainedMutation == 0 we would
apply 0 mutations, when we should actually be applying chainedMutation
mutations, due to how count is incremented.
Fixes#49047
Change-Id: I76773bff0afd6dfd40deafc317be095da995ecc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/365294
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
It causes a crash because of the unexpected XDOT operation. It's not
needed, since we will run ComputeAddrTaken() on function instantiations
after stenciling. And it's not always correct, since we may not be able
to distinguish between a array and a slice, if a type is dependent on a
type param.
However, we do need to call ComputeAddrTaken on instantiations created
during inlining, since that is after the main ComputeAddrTaken pass.
Fixes#49659
Change-Id: I0bb610cf11f14e4aa9068f6ca2a012337b069c79
Reviewed-on: https://go-review.googlesource.com/c/go/+/365214
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
If we have to build a test package, and if the full set of packages
being tested imports the regular package somewhere, then make building
the test package depend on building the regular package. That way if
the regular package fails to build we only report the error once.
Fixes#44624
Change-Id: Ic7d66d8fec9c4688d369153a4b21194989f8def3
Reviewed-on: https://go-review.googlesource.com/c/go/+/365215
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
- fixed a typo in the method set section
- express in the syntax that ~T denotes an underlying type
- be more precise when talking about types vs type terms
- refer to "unions" rather than "union expressions"
- make it clear in the spec title that this is WIP
Change-Id: I9b2c4b1f77bc50dd574ed6893bedd40529c320fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/365154
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The linker DWARF test includes an "examiner" helper type (with
associated methods) that is used to help linker DWARF tests read DWARF
info in a higher level and more structured way than just raw
debug/dwarf operations. This patch extracts out "examiner" and
relocates it to a separate package, so that it can be used in other
package tests as well, if need be.
Change-Id: Iec66061e2719ee698c12d8fa17b11698442b336d
Reviewed-on: https://go-review.googlesource.com/c/go/+/364036
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is the first of several CLs that update the existing
Go 1.17 spec for type parameters.
This CL updates the section on method sets and interface types.
It also adds "any", "comparable" to the list of predeclared
identifiers.
Change-Id: I0ce25dc02791c33150c0d949528512610faf3eab
Reviewed-on: https://go-review.googlesource.com/c/go/+/362999
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When using faketime, only run the scavenger for one loop.
It tries to run for 1 ms, but with faketime that calculation fails.
Prohibit write barriers in the faketime write function, in case
the GC wants to print something (e.g., with GODEBUG=gctrace=1).
Fixes#49614
Change-Id: Iab5097fe78b6e0032ea8b493088264dfb25013c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/364757
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a port of CL 359016 from types2 to go/types. Some of the code
around untyped nil differed (because we have to treat untyped nil
differently in go/types for historical reasons).
Updates #47916
Change-Id: Ifc428ed977bf2f4f84cc831f1a3527156940d7b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/364716
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
There are code paths (particularly error formatting or tracing) that
call tparamIndex before the type parameter is bound. We cannot rely on
the index being non-negative.
Change-Id: Ibad91c691b4f319b0c7b465a750b679a8a7af6a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/364715
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Introduce a new constant compilerErrorMessages, which is set to false
for now, so that we can port types2 error handling more precisely. Use
this to (partially) port CL 363436, excluding issue49005.go, which does
not exist in go/types (it was added in a previous CL related to compiler
error messages, that was not ported). I've also included the bugfix from
CL 364034, so that go/types is not broken at this commit.
In subsequent CLs I'll catch up with error handling locations in types2
that use compiler error messages.
Change-Id: I13fd6c43d61b28e0a7a3b0ae8ba785fb8506fbb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/364379
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This makes two changes: (1) mutator.mutate now only applies a single
mutation to the input, and (2) in workerServer.fuzz if, after five
mutations are applied to the input, no new coverage is found the input
is reset to its initial state. This process is repeated until new
coverage is found, or the fuzz call times out.
This results in finding new coverage expanding inputs which have less
divergence from the initial input they were mutated from, which makes
traversing certain types of call graphs significantly more efficient.
Fixes#49601Fixes#48179Fixes#47090
Change-Id: I74d18a56ca2669f20192951090b281f58ee0b5dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/364214
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
This CL is a clean port of CL 363517 from go/types to types2,
with the exception that types_test.go was not removed because
it's still needed to set a types2-specific test flag.
Change-Id: I12177866537c0f95f3fa36fa0f4aa02016609ca9
Reviewed-on: https://go-review.googlesource.com/c/go/+/364494
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL is a clean port of CL 363176 from go/types to types2.
It also includes a minor adjustment to a field access in go/types
to match types2 in that respect.
Change-Id: If33fc7e68372b12d61d06b75dd9f7c0715b57bc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/364474
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a port of CL 363114 from go/types to types2 with a temporary
work-around in tparamIndex to avoid a crash with the unified build
and test/typeparam/setsimp.go.
Change-Id: Id4805385f21c95b461911b246fb47ee278a84ac9
Reviewed-on: https://go-review.googlesource.com/c/go/+/364336
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL is a mostly clean port of CL 362801 from go/types to types2.
It deviates from go/types in some of the testing code because types2
already had made some of the changes.
It also re-introduces some empty lines that got lost in earlier CLs.
Change-Id: I0bebd68f0880fac61631a5d0c323a9f8ce853ac6
Reviewed-on: https://go-review.googlesource.com/c/go/+/364335
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
exec_test.go's init function uses os.NewFile(fd) + f.Stat as a portable
mechanism to determine if an FD is in use.
Unfortunately, the current use is racy: if an unused FD becomes used
between NewFile and f.Close, then we will unintentionally close an FD we
do not use.
We cannot simply drop Close, as the finalizer will close the FD. We
could hold all of the os.Files in a global for the lifetime of the
process, but the need for such a hack is indicative of the larger
problem: we should not create an os.File for an FD that we do not own.
Instead, the new fdtest.Exists provides a helper that performs the
equivalent of fstat(2) on each OS to determine if the FD is valid,
without using os.File.
We also reuse this helper on a variety of other tests that look at open
FDs.
Fixes#49533
Change-Id: I36e2bdb15f271ab01e55c18db6564271995a15af
Reviewed-on: https://go-review.googlesource.com/c/go/+/364035
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change updates the cmd module's requirement on x/mod and vendors in
the changes.
This pulls in the following changes into our vendored copy of x/mod:
golang.org/cl/351319: module: accept trailing slash in MatchPrefixPattern
golang.org/cl/353749: semver: remove unused err field
golang.org/cl/355630: x/mod: update requirement on x/crypto
golang.org/cl/359412: modfile: rename directory directive to use
Changes have been made in cmd/go renaming all uses of directory to use
and fixing references to functions in x/mod/modfile to account for the
changes in the last of thse CLs.
For #45713
Change-Id: I9121d08f6e6b11838bca50e6cbd756baeeae867b
Reviewed-on: https://go-review.googlesource.com/c/go/+/364114
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
casgstatus currently calls nanotime on every casgstatus when tracking,
even though the time is only used in some cases. For goroutines making
lots of transitions that aren't covered here, this can add a small
overhead. Switch to calling nanotime only when necessary.
Change-Id: I2617869332e8289ef33dd674d786e44dea09aaba
Reviewed-on: https://go-review.googlesource.com/c/go/+/364375
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Because any is an a alias, it is naively formatted as interface{} in
error messages. This is a source of verbosity and potential confusion.
We can improve the situation by looking for pointer equality with the
any type. To avoid churn in the importers, do this all at once across
the compiler, go/types, and go/internal/gcimporter. CL 364194 makes the
corresponding change in x/tools/go/internal/gcimporter, allowing the
x/tools trybots to pass.
Fixes#49583
Change-Id: Ib59570937601308483f6273364cc59338f9b8b3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/363974
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is a clean port of CL 362798 from go/types to types2,
with an additional comment adjustment in types2 and go/types.
Change-Id: Ifa3d11f512f794f8ae2b6aca50b625a4a44672de
Reviewed-on: https://go-review.googlesource.com/c/go/+/364135
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Also mention local types restriction.
We probably want to say more at some point, this is just a
placeholder to start.
Update #47631
Change-Id: I828e451e1e8504d21cb55c7132e9cb330b160a54
Reviewed-on: https://go-review.googlesource.com/c/go/+/364134
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When a DW_FORM_line_strp is used without a debug_line_str section a
good error message (about the missing section) is generated but
immediately overwritten by the underflow error generated by trying to
read the non-existent section.
Updates #49590
Change-Id: I1c431392123a86c78c95ef1f185ebd6f17f2476a
Reviewed-on: https://go-review.googlesource.com/c/go/+/363894
Run-TryBot: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Trust: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
But exclude the test when running unified build for now
(the unified builder's importers are not yet updated to
handle extended interfaces).
Also, fix respective error position.
Fixes#47967.
Change-Id: I4e3d829b5c12001c024b9eefcc27f97b10c1d1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/363834
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Because the underlying type of a type parameter is an interface,
the questions whether *P for a type parameter P has methods or
not is settled: P is also an interface pointers to interfaces
don't have methods.
This allows us to eliminate the now unneccesary test in "implements"
and also allows us to remove a special case for type parameters in
"lookupFieldOrMethod".
Change-Id: I8b218f81584a8e42e75884089a44293365b700df
Reviewed-on: https://go-review.googlesource.com/c/go/+/363838
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Checker.implements implements the complete interface
"implements" predicate. Use it instead of Checker.satisfies.
This is mostly a refactoring of the code but the constraint
types have already been instatiated with the respective type
arguments as needed before calling "implements".
Future CLs will address the various TODOs.
Change-Id: If530cca36643a561282361348f1526157a7182de
Reviewed-on: https://go-review.googlesource.com/c/go/+/363837
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Most of the time we don't have a type parameter. Avoid using a
closure in that case.
While at it, rename argument from typ to t (to match style in
that file), and clarify the doc string.
Change-Id: Ie62821073f60f353526263f8b380bad9f72d842e
Reviewed-on: https://go-review.googlesource.com/c/go/+/363668
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The bare error message "%s is not a generic type" is probably never
sufficient, so change the signature of genericType to instead return an
message that may be formatted as additional context in errors.
Along the way, refactor instantiatedType to have access to the entire
index expression.
Fixes#48827
Change-Id: I0c455c1ce46ac3f1ef2990c997da19e5fc6c4eae
Reviewed-on: https://go-review.googlesource.com/c/go/+/363994
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
During development, we used placeholder _Todo error codes for new
errors related to generics. Add real error codes in these places.
As a result, 9 new error codes are added for ~50 call sites.
Change-Id: Ib57b4cd9f0a2e160971a3aeea18f9fe26fc0f835
Reviewed-on: https://go-review.googlesource.com/c/go/+/363874
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The main fix is that we should call ir.SetPos() at the beginning of
(*subster).node.edit function, since that is analogous to the
ir.SetPos() at the beginning of typecheck.typecheck(). It ensures that
transform functions can use base.Pos() with appropriate results, just
like their corresponding tc*() functions do.
A small fix is to make sure that the new nodes creates for dictionary
references have the correct position based on the location of the
function call.
Another small fix is to the use of base.Pos when creating a new selector
expression (including implicit XDOTs) for a method expression in
buildClosure().
Also, I converted the final use of base.Pos in stencil.go to src.NoXPos,
since the nodes created by AddImplicitDots will be checked for their
type, but won't actually be used.
I also needed to add an ir.SetPos() at the beginning of transformCall(),
since transformCall() is called in the modify and dict passes, when we
base.Pos is not being set for each node.
This change fixes all the line numbering problems printed out from
Alessandro's program, except for auto-generated functions (which I think
are fine).
Fixes#49523
Change-Id: I9836a497b7beba25ecafdde653a6c2036a3020d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/363835
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently "released" is not accumulated bytes released. If the last
attempt to scavenge ends up as 0, then the scavenger will go to sleep
too soon. This is an artifact from the old code where scavenge would
only be called into once.
Change-Id: I85aa2261f1504a6fb5bf086daa029eecb0e09cf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/363416
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The simplified version of under exposed a bug (by crashing):
When a pointer base is used before the pointer is fully set
up, the base is nil. Set the pointer base to Typ[Invalid]
when creating the pointer, and add an extra safety check
into deref. Reviewed all code that creates pointers.
The same error cannot happen with other types because
accessing parts of another type results in an expression
that is not a type, and thus these kids of cycles cannot
happen.
Change-Id: I8332a281a534c094cfbb3623a636960865813ff6
Reviewed-on: https://go-review.googlesource.com/c/go/+/363665
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Instantiate already returns an error when validation fails. Panicking on
an incorrect number of type arguments means that callers must both
pre-validate the number of type arguments and handle resulting errors.
Returning an error rather than panicking allows eliminating
pre-validation at the call-site.
Also update the Instantiate docstring to correct some stale/inaccurate
information, and to clarify its behavior more precisely.
Updates #47916
Change-Id: I997ef30b3486760a90b0db4c3ea7111280d74a81
Reviewed-on: https://go-review.googlesource.com/c/go/+/363635
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add a test that exercises the fall-back logic in Context to handle hash
collisions by de-duplicating using Identical.
This has to be a somewhat invasive test because we don't know any actual
cases of hash collisions.
Change-Id: Idf00f7a6ab8c7517ed0f91fdc42d54f5e736b1b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/363517
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Users can re-use a type checking context by passing it via types.Config.
There is no need for us to expose the internal type checking context
when the config context is unset, and in fact doing so could lead to a
memory leak for users that re-use types.Config, expecting it to be small
and immutable.
Keep track of the Context on Checker instead, and zero it out at the end
of type checking.
Change-Id: Iff5b328a09cd0af76fcd4869f5f15352131b5986
Reviewed-on: https://go-review.googlesource.com/c/go/+/363175
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The interface type string preserves certain non-semantic attributes of
the type, such as embedded interfaces. We want the hash to represent the
interface identity, so hash the type set representation of the interface
instead.
Change-Id: I14081ac20b738c5fe11785e0846a9b4358594768
Reviewed-on: https://go-review.googlesource.com/c/go/+/363115
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Extend the type checking context to allow de-duplicating *Signature
instances, in addition to *Named instances.
Naively we would deduplicate instances of different-but-identical origin
*Signature types. That may be OK, but it seems a bit strange to get the
same signature when instantiating two different functions. For now,
differentiate *Signature types by prepending a unique identifier for the
origin pointer, thus guaranteeing that instances de-duplicated if they
come from the exact same (pointer identical) origin type.
Updates #47103
Change-Id: I93cc3cacad195267fe0a5801f9c5a3b1e61eb907
Reviewed-on: https://go-review.googlesource.com/c/go/+/362801
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In the few remaining places where we use asNamed, if the argument
is indeed a *Named, we either don't need to look "inside" it, or
we call under() (which calls Named.underlying() which does resolve);
so there's no need for an implicit resolution (which was done by
asNamed). The only place where we do need to resolve is in lookup,
so added the explicit resolve call in that case.
Change-Id: Iff0a19fde7581e94149e89b9e48157c1981db105
Reviewed-on: https://go-review.googlesource.com/c/go/+/363441
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Until now, the type checker operated with the definition that the
underlying type of a type parameter is itself. This leads to some
inconcistencies and caused us to disallow type declarations where
the RHS is a stand-alone type parameter.
This change implements an alernative definition: the underlying
type of a type parameter is the underlying type of its constraint;
i.e., the underlying type of a type parameter is always an interface
(because constraints must be interfaces). This matches the theory
closely and also resolves some inconsistencies. For example, we
don't need to prohibit stand-alone type parameters on the RHS of
a type declaration (though, for the sake of keeping the tests the
same, we still do in this CL). We also get a clear understanding of
what it would mean to use a type assertion or type switch on a type
parameter (still disabled with this CL). Finally, the declaration
of a type parameter now very closely matches the definition of an
ordinary type.
The main consequence is that the rules for assignment need to be
slightly modified: even though a type parameter is an interface,
we cannot simply assign to it per the rules for interfaces: the
type parameter's type is fixed for the instantiation and we need
to reflect that accordingly when checking for assignability.
This CL does not enable the new mode, it implements it in parallel
to the existing mode; the internal flag tparamIsIface is used to
switch between the modes.
The changes to the code are numerous, but straight-forward: when-
ever we deal with an underlying type that might be a type parameter
(or newly, an interface), we need to act slightly differently. For
the time being this leads to some code duplication because the code
supports both modes.
While some of the code for the new mode seems more complicated
(e.g., when we have an interface, the code checks that it is not
the underlying type of a type parameter), in reality many of the
extra checks are redundant and only present because of an abundance
of caution: interfaces with specific type sets are not permitted as
types for ordinary variables, and so even if we were to hit those
cases w/o excluding type parameters the behavior would be the same.
Runs all tests with tparamIsIface enabled and disabled.
Current setting: disabled.
Change-Id: I7bb6453f4fe2569d92face222058fb4e17b12f25
Reviewed-on: https://go-review.googlesource.com/c/go/+/359016
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed all uses of underIs (global function and method) and made
sure we are ok with a nil incoming argument (indicating a type set
with no specific types).
Added a couple of checks where we didn't have them (and somehow
didn't run into a problem yet).
Change-Id: Ifde45a3a80ddf2b1a19c83f79258ad8207dfb09f
Reviewed-on: https://go-review.googlesource.com/c/go/+/363658
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When being used by the compiler, augment the types2 missing method
message with extra info, if a method is missing, but a method with the
correct name except for case (i.e. equal via string.EqualFold()) is
present. In that case, print out the wanted method and the method that
is present (that has the wrong case).
In the 1.17 compiler, we don't do this case-folding check when assigning
an interface to an interface, so I didn't add that check, but we could
add that.
Fixes#48471
Change-Id: Ic54549c1f66297c9221d979d49c1daa719aa66cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/363437
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When being used by the compiler, fix up types2 error messages to be more
like Go 1.17 compiler errors. In particular:
- add information about which method is missing when a type is not
assignable/convertible/etc. to an interface.
- add information about any existing method which has the same name,
but wrong type.
- add extra hint in the case that the source or destination type is a
pointer to an interface, rather than an interface.
- add extra hint "need type assertion" in the case that the source is
an interface that is implemented by the destination.
- the following change in the CL stack also adds information about any
existing method with a different name that only differs in case.
Include much of the new logic in a new common function
(*Checker).missingMethodReason().
types2 still adds a little more information in some cases then the Go
1.17 compiler. For example, it typically says "(value of type T)",
rather than "(type T)", where "value" could also be "constant",
"variable", etc.
I kept the types2 error messages almost all the same when types2 is not
used by the compiler. The only change (to reduce amount of compatibility
code) was to change "M method" phrasing in one case to "method M"
phrasing in one error message (which is the phrasing it uses in all
other cases). That is the reason that there are a few small changes in
types2/testdata/check/*.src.
Added new test test/fixedbugs/issue48471.go to test that the added
information is appearing correctly.
Also adjusted the pattern matching in a bunch of other
test/fixedbugs/*.go, now that types2 is producing error messages closer
to Go 1.17. Was able to remove a couple test files from the types2
exception list in run.go.
Updated #48471
Change-Id: I8af1eae6eb8a5541d8ea20b66f494e2e795e1956
Reviewed-on: https://go-review.googlesource.com/c/go/+/363436
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Because we do not permit a stand-alone type parameter on the RHS of
a type declaration, the underlying type of a (Named) type cannot be
a type parameter. This allows us to simplify some code.
Specifically, when parsing union elements, we don't need to delay
a check for later, which allows further simplifications when computing
type sets.
Change-Id: I4047c609f87ebb194ea8c1bad630a70d255b20cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/363438
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Like the VDSO, we cannot directly traceback from the Linux kernel ARM
atomic/barrier helpers. However, unlike the VDSO, this functions are
extremely simple. Neither of the functions we use, kuser_cmpxchg and
kuser_memory_barrier, touch SP or LR.
We can use this to our advantage to read LR and simply start tracebacks
in the caller.
Fixes#49182
Change-Id: I890edbeb7c128938000fe7baf6f913c02a956edd
Reviewed-on: https://go-review.googlesource.com/c/go/+/362977
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When sending a Request with a non-context deadline, we create a
context with a timeout. This context is canceled when closing the
response body, and also if a read from the response body returns
an error (including io.EOF).
Cancelling the context in Response.Body.Read interferes with the
HTTP/2 client cleaning up after a request is completed, and is
unnecessary: The user should always close the body, the impact
from not canceling the context is minor (the context timer leaks
until it fires).
Fixes#49366.
Change-Id: Ieaed866116916261d9079f71d8fea7a7b303b8fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/361919
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The Linux kernel starting in 5.9 and fixed in 5.16 has a bug that can
break CPU timer signal delivery on new new threads if the timer
interrupt fires during handling of the clone system call.
Broken CPU timer signal deliver will skew CPU profile results and cause
this test to fail.
There is currently no known workaround, so mark the test as flaky on
builders with known broken kernels.
For #49065
Change-Id: I37ceb9ea244869b0aab5cd9a36b27ca2f7e5d315
Reviewed-on: https://go-review.googlesource.com/c/go/+/363214
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
the CgoPprof tests currently assume that calls to their cgoTraceback
functions are primarily for generating pprof samples and exit early
after receiving two calls.
This is a fragile assumption, as cgoTraceback will be called for _any_
signal received, hence why the test already looks for 2 calls instead of
1.
Still, this has caused flaky failures in two cases:
* #37201, where async preemption signals add additional probability of
receiving non-profiling signals. This was resolved by disabling async
preemption.
* #49401, where some ITIMER_PROF SIGPROF signals are ignored in favor of
per-thread SIGPROF signals.
Rather than attempting to keep plugging holes, this CL drops the fragile
assumption from these tests. Now they simply unconditionally run for the
full 1s before exiting.
Fixes#49401
Change-Id: I16dc9d2f16c2fb511e9db93dd096a402121f86ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/363634
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Rhys Hiltner <rhys@justin.tv>
This change sets a timeout of 10 seconds on each
execution of the fuzz target, both during fuzzing
and during minimization. This is not currently
customizable by the user, but issue #48157 tracks
this work.
Deadlocks will be considered non-recoverable errors,
and as such, will not be minimizable.
Fixes#48591
Change-Id: Ic86e8e9e9a0255e7860f7cbf5654e832785d1cbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/363134
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Context.TypeHash is not being used outside of the type checker, so
unexport it.
The TypeHash method is meant to hash instances, not arbitrary types, and
will soon be modified to differentiate origin types by pointer identity
(even if they are *Signature types).
Change-Id: Ia8d4a7c6350ce7f278b70630585efb0009fef63a
Reviewed-on: https://go-review.googlesource.com/c/go/+/363516
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We don't have guarantees that our type hash is perfect, and in fact
fuzzing found cases where identical types hashed to different values. In
case non-identical types hash to the same value, we should ensure that
we de-duplicate using Identical.
Adjust the type map to keep a slice of distinct type identities, so that
we can guarantee that type identity is preserved by de-duplication.
To allow look-up of instances by their identity, before they are
actually instantiated, add a Context.lookup method that accepts origin
type and type arguments. Replace the multi-function typeForHash method
with an update method that requires its argument be non-nil.
Change-Id: I8fe6fb2955f508db608161b7285b02d0a2fa0e46
Reviewed-on: https://go-review.googlesource.com/c/go/+/362798
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently the recover4 test, which recovers from a panic created from a
fault, generates a fault by creating a hole in a mapping. It does this
via munmap. However, it's possible the runtime can create a new mapping
that ends up in that hole, for example if the GC executes, causing the
test to fail.
In fact, this is the case now with a smaller minimum heap size.
Modify the test to use mprotect, and clean up the code a little while
we're here: define everything in terms of the length of original
mapping, deduplicate some constants and expressions, and have the test
recover properly even if recover() returns nil (right now it panics
because it fails to type assert nil as error).
Fixes#49381.
Change-Id: If399eca564466e5e8aeb2dc6f86a246d0fce7b5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/363534
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When register ABI is used, reflect.Value.Call prepares the call
arguments in a memory representation of the argument registers.
It has special handling to keep the pointers in arguments live.
Currently, this handles pointer-typed arguments. But when an
argument is an aggregate-type that contains pointers and passed
in registers, it currently doesn't keep the pointers live. Do
so in this CL.
May fix#49363.
Change-Id: Ic6a0c5fdf9375ef02f7c03fbe9345e2e98c9353d
Reviewed-on: https://go-review.googlesource.com/c/go/+/363358
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When the link exits on error it currently calls Out.Close, which
will munmap the output buffer and close the file. This may be
called in concurrent phase where other goroutines may be writing
to the output buffer. The munmap can race with the write, causing
it to write to unmapped memory and crash. This CL changes it to
just close the file without unmapping. We're exiting on error
anyway so no need to unmap.
Fixes#47816.
Change-Id: I0e89aca991bdada3d017b7d5c8efc29e46308c03
Reviewed-on: https://go-review.googlesource.com/c/go/+/363357
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This change doesn't modify any functionality.
It also doesn't update all of the comments and
variable names of the internal code, but everything
user facing should be correct.
Updates #49185
Change-Id: Ia8b2c94b89ba45897c4085ea0c17a3d8896f7ec7
Reviewed-on: https://go-review.googlesource.com/c/go/+/362794
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Our compiler gets confused between functions that were declared
with no body, and those which have a body but it is empty.
Ensure that when stenciling, we generate a nonempty body.
The particular test that causes this problem is in
cmd/compile/internal/gc/main.go:enqueueFunc. It thinks that if
a function has no body, then we need to generate ABI wrappers for
it, but not compile it.
Fixes#49524
Change-Id: Id962666a2098f60a2421484b6a776eafdc4f4a63
Reviewed-on: https://go-review.googlesource.com/c/go/+/363395
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Currently TestPhysicalMemoryUtilization can fail on systems with large
physical page sizes like 64 KiB because all the of the holes to be
scavenged are not aligned to the page size. The holes themselves are 64
KiB so this is actually quite likely.
Bump the size of the allocations for systems with larger physical page
sizes, and add additional slack to the threshold for unaligned pieces of
the holes that may be unaligned.
Fixes#49411.
Change-Id: Iafb35b8761dc9cdc53d3745c4771b1a64c5c97b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/363415
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
FreeOSMemory relies on the function FreeOSMemory increasing HeapReleased
as opposed to the background scavenger, because it reads memory stats
*after* the free of a large allocation. However, before that even
happens, the background scavenger can swoop in and release all that
memory, making it appear as if FreeOSMemory didn't do anything.
This change modifies the test to just make sure that the large
allocation's memory is returned to the OS *somehow*, by the end of the
test. It doesn't really care which happens. It also increases the size
of that large allocation to increase the likelihood that the test isn't
relying 100% on the background scavenger, and that FreeOSMemory is doing
some of the work.
Fixes#49478.
Change-Id: Ief1d839753720ebb88cbb616c46302293ee2d19c
Reviewed-on: https://go-review.googlesource.com/c/go/+/363414
Reviewed-by: David Chase <drchase@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
In function connectionCleanerRunLocked append to closing slice affects db.freeConns and vise versa. Sometimes valid connections are closed and some invalid not.
Change-Id: I5282f15be3e549533b7d994b17b2060db3c0e7da
GitHub-Last-Rev: b3eb3ab6f4
GitHub-Pull-Request: golang/go#49429
Reviewed-on: https://go-review.googlesource.com/c/go/+/362214
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When building a call expression for function instantiation closure, if
it's a variadic function, the CallExpr.IsDDD must be set for typecheck
to work properly. Otherwise, there will be a mismatch between the
arguments type and the function signature.
Fixes#49516
Change-Id: I0af90ee3fcc3e6c8bba8b20e331e044cbce17985
Reviewed-on: https://go-review.googlesource.com/c/go/+/363314
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
When acquire a goroutine profile, we stop the world then acquire a
stack trace for each goroutine. When cgo traceback is used, the
traceback code may call the cgo traceback function using cgocall.
As the world is stopped, cgocall will be blocked at exitsyscall,
causing a deadlock. Bypass the scheduler (using asmcgocall) to fix
this.
Change-Id: Ic4e596adc3711310b6a983d73786d697ef15dd72
Reviewed-on: https://go-review.googlesource.com/c/go/+/362757
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A chunk of code in abiutils was synthesizing the internals of a Go
string type as "struct { unsafe.Pointer, uintptr }" instead of the
more canonical representation "struct { *uint8, int }" used elsewhere
in the compiler. The abiutils type was being pulled into the code
during late call expansion, which resulted in two different entries in
the SSA named value table for the same variable piece, each with
different types; this then confused DWARF location list generation.
This patch changes the abiutils synthesized type to be consistent with
other parts of the back end, and makes a similar change for
synthesized slice types (use "struct { *uint8, int, int }").
Fixes#47354.
Change-Id: If789031cdc7abaf215bc75ee6eb863defbe530be
Reviewed-on: https://go-review.googlesource.com/c/go/+/362715
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
During the register ABI work, a change was made in CL 302071 to
"stackframe" to treat register-resident output parameter (PARAMOUT)
variables that same as locals, which meant that if they were unused,
we'd delete them from the "Dcl" slice. This has the effect of making
them invisible to DWARF generation later on in the pipeline, meaning
that we don't get DIEs for them in the debug info. This patch fixes
the problem by capturing these params prior to optimization and then
adding them back in for consideration when we're processing the
params/locals of a function during DWARF generation.
Fixes#48573.
Change-Id: I2b32882911c18f91c3e3d009486517522d262685
Reviewed-on: https://go-review.googlesource.com/c/go/+/362618
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Revamp the way that buildLocationLists() handles zero-width
operations, to fix a couple of problems that result in bad debug
locations.
The problematic scenario in this specific bug is where you have a
parameter arriving in a register X, then a spill of register X to
memory as the first non-zero-width instruction in the function.
Example:
v68 = ArgIntReg <unsafe.Pointer> {ctx+0} [1] : BX (ctx[unsafe.Pointer])
v67 = ArgIntReg <unsafe.Pointer> {ctx+8} [2] : CX (ctx+8[unsafe.Pointer])
...
v281 = StoreReg <unsafe.Pointer> v67 : ctx+8[unsafe.Pointer]
The existing buildLocationLists implementation effectively buffers or
bundles changes from zero-width instructions until it it sees a
non-zero-width instruction, but doing that in this case winds up
making it look as though the parameter is live into the function in
memory, not in a register.
The fix for this to separate out zero-width ops into two distinct
categories: those that whose lifetimes begin at block start (ex:
OpArg, Phi) and those whose effects are taking place at the nearest
non-zero-width instruction (ex: OpSelect0). In this patch we now
handle the first category of ops in an initial pre-pass for each
block, and leave the second category for the main pass through the
block. See the notes on the issue below for a more detailed
explanation of the failure mode.
Fixes#46845.
Change-Id: I27488d4c041019d5a0b897b7cf53000f63aab1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/362244
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
We already have various member functions of TCPAddr that return an
AddrPort, but we don't have a helper function to go from a AddrPort to a
TCPAddr. UDP has this, but it was left out of TCP. This commit adds the
corresponding function.
Updates #49298.
Change-Id: I85732cf34f47c792fe13a6b4af64fd4b0e85d06a
Reviewed-on: https://go-review.googlesource.com/c/go/+/362596
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently it's quite hard to debug these error messages about ignored symbols
because there are only some numbers and no symbol name. Add symbol name. Before:
135029: sym#952: ignoring symbol in section 11 (type 0)
After:
135029: sym#952 (_ZN11__sanitizer9SpinMutexC5Ev): ignoring symbol in section 11 (type 0)
Change-Id: I7fec50b5798068c74827376613be529803838c5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/363034
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitry Vyukov <dvyukov@google.com>
Doing this a little early in the release cycle as there have been some
changes in the handling of old timezones. They should continue to
work as expected, but more testing time may be useful.
For #22487
Change-Id: I3686fed79a052c46112445055044cff5842f2a45
Reviewed-on: https://go-review.googlesource.com/c/go/+/362874
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
A UDPAddr with a nil IP is a valid state, representing an AF-agnostic
unspecified address, so checking for addr.IsValid() isn't correct;
remove that, as it's only needed in the UDP rx path where it can be
added. Secondly, forcing everything to be IPv6 also is not correct, and
was likely done when the missing .AsSlice() made doing the right thing
less ergonomic. Fix this by using .AsSlice(), which properly preserves
IP version.
Change-Id: Idd1eaecd4076f32a843f859a0a9802ef98f956d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/361478
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
structuralString was used only in one place (for built-in copy).
Remove it in favor of custom and more efficient inlined code.
Follow-up on feedback received for CL 363075.
Change-Id: Ic5857c47255c5c712be7971aae4542fef9960fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/363154
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
If we have all channel types in a constraint, there is no structural type
if they don't all have the same channel direction (and identical element
types, of course). By allowing different channel types for the purposes of
the structural type, as long as there is not a send-only _and_ a receive-
only channel in the type set, we make it possible to find a useful, if
restricted by channel direction, structural type where before there was
none.
So if we have unrestricted and send-only channels, the structural type is
the send-only channel, and vice versa.
For all operations on channels that rely on a structural type, it's always
ok to have an unrestricted channel, so this is not affecting their behavior.
But it makes those operations more flexible in the presence of type parameters
containing mixed channel types.
For constraint type inference, where we currently may not infer a channel
at all, this change allows us to infer a more restricted channel (send- or
receive-only). If the inferred channel type is a valid type argument we win;
if not we haven't lost anything.
Use structuralType for send and receive operations and adjust related
error messages (the error message that change are the ones involving
type parameters, so historic error messages are preserved).
Fixes#45920.
Change-Id: If3a64d29c37e7734d3163df330f8b02dd032bc60
Reviewed-on: https://go-review.googlesource.com/c/go/+/363075
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For generic functions, we can export untransformed OKEY nodes, and the
key identifier is written as an ONONAME. But in this case, we do not
want to call Resolve() on the identifier, since we may resolve to a
global type (as happens in this issue) or other global symbol with the
same name, if it exists. We just want to keep the key identifier as an
Ident node.
To solve this, I added an extra bool when exporting an ONONAME entry,
which indicates if this entry is for a key or for a global (external)
symbol. When the bool is true (this is for a key), we avoid calling
Resolve().
Fixes#49497
Change-Id: Ic8fa93d37bcad2110e0e0d060080b733e07e35d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/363074
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Adds a new flag to 'go mod vendor' which overrides the default
'vendor' destination directory. This can be helpful for writing the
vendor tree to a temporary location for use by other tools.
The argument can be a relative or an absolute path.
This flag has no other influence on how the command behaves.
Fixes#47327
Change-Id: I4502931127616b181dc90a2066d2fb57bfe48f96
Reviewed-on: https://go-review.googlesource.com/c/go/+/338149
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
- move structuralType/structuralString into type.go
- move functions exported for the compiler into compilersupport.go
- updated/added comments
- removed AsNamed and AsInterface - not needed by compiler
No semantic changes.
Change-Id: Ia454a49edafd627c2a25b0b71db4aa93ddd7f1f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/362995
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Functions returning type parameters were erroneously being interpreted
as 'constructors' of their type parameter, resulting in them being
excluded from documentation. Fix this by explicitly excluding type
parameters when looking for defined type names among function results.
Fixes#49477
Change-Id: I22510f655f47e192a852332df5b91740f46c51eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/362758
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
And rename structureString to structuralString.
Now that we have an updated definition for structural types in
the (forthcoming) spec, name the corresponding function accordingly.
No semantic changes.
Change-Id: Iab838f01a37075bedf2d8bc4f166b0217672b85f
Reviewed-on: https://go-review.googlesource.com/c/go/+/362994
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
We have V and T and Vu and Tu. When calling the various isX predicates
consistently use Vu and Tu.
(We could also use V an T because the predicates call under anyway,
but using Vu and Tu removes an unnecessary call to Named.under if
V or T are *Named.)
Also, removed some outdated comments.
Change-Id: I6fcd9ce5f6292e89ac2afd597b72fd0790e84ff1
Reviewed-on: https://go-review.googlesource.com/c/go/+/362895
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We already guard against this in the type checker, and it will
eventually be allowed per the accepted proposal.
Add a placeholder error code for the corresponding type checker error.
Change-Id: I5cc2f1413ecc89ec2094f7178fdb156fb8cc2e43
Reviewed-on: https://go-review.googlesource.com/c/go/+/360235
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
If we reach a generic type that is part of a cycle
and we are in a type parameter list, we have a cycle
through a type parameter list, which is invalid.
Fixes#49439.
Change-Id: Ia6cf97e1748ca0c0e61c02841202050091365b0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/361922
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Also, invert the boolean result. This matches Checker.validType;
it's also easier to understand. Preparation for the next CL which
detects cycles through type parameter lists.
Change-Id: I00a75d2359ca20827c9bf406945508716c826fc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/362336
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
[ this is a roll-forward of golang.org/cl/357169 with minor changes
to fix the cmd/go/internal/modload tests: because they don't run the
go command, some initialization isn't run on the test and modroots is
empty in cases it can't be when the full command setup is done. So
directly check for workFilePath != "" instead of calling inWorkspaceMode
which checks that Init is called first, and check that modRoots is non
empty when calling mustGetSingleMainModule.]
This change corrects a bug in the handling of module loading of
workspaces. Namely, there is an assumption by the module pruning code
that if a root module is selected then the packages of that module can
be resolved without loading the whole module graph. This is not true
in workspace mode because two workspace modules can require different
versions of a dependency. Worse, one workspace module can directly
require a depencency that is transitively required by another
workspace module, changing the version of that module loaded in the
fully expanded graph.
To correct this, a new 'workspace' pruning mode is added where the
roots are the workspace modules themselves, satisfying the assumption
made by the module pruning logic.
The rest of this change accounts for the new pruning mode where it's
used and correctly sets the requirements in this pruning mode.
Change-Id: I8bdf4b30f669c1ded0ed8a5dd202ac8d1939bbbd
Reviewed-on: https://go-review.googlesource.com/c/go/+/362754
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently, when a command scheduled by bgrun fails, bgwait returns to
the caller even in case the fatal error was detected.
In case of a syntax error in one of the standard packages, as an
example, the runInstall function will try to read the generated archive
file, only to fail since the file does not exist. Since the runInstall
function is called in a goroutine, cmd/dist will continue to report
errors until all background goroutines are done.
Update the bgwait function to wait until program termination in case of
a fatal error, since returning to the caller (with an error, as an
example) will cause cmd/dist to report an additional error during the
next build phase.
Fixes#45410
Change-Id: If89976abad70f8d6ec79b2a5a1f2306e9c034c5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/320311
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
This enhances the existing line number test
to allow a specific -gcflags (e.g., -G=3)
and to permit ignoring duplicate line numbers
(which is arguably a bug, but not THIS bug,
and it lowers the risk of a flaky test).
Limited to Linux/Darwin and amd64/arm64,
also tests with "unified" mangling.
And, using these new powers, adds a test.
Updates #49436.
Change-Id: I09c82e6a08d53edd5a752522a827e872d3e16e0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/362714
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The Go 1.18 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
This CL updates only the tools module, keeping mod unchanged because
its lastest commit isn't ready to be vendored yet.
For #36905.
Updates #49350.
Change-Id: Ib39713d28a55fc9ec79058aab9919eba912def5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/361094
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The Go 1.18 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
This CL updates only the crypto module, as well as the TestDependencies
policy to accommodate the dependency order change done in CL 345649.
The next CL will update further modules.
For #36905.
Change-Id: If93160d8d72ca86e9995aaf5bdfc3d2c20b4695d
Reviewed-on: https://go-review.googlesource.com/c/go/+/362736
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The Go 1.18 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
This CL updates only the net, text modules.
The next CL will update further ones.
For #36905.
Change-Id: I9a5ac3cca22da961cfd09f3202e01e1187d42bdd
Reviewed-on: https://go-review.googlesource.com/c/go/+/362735
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The Go 1.18 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
This CL updates only the lower-level modules arch, sys, term for better
bisection. The next CL will update further ones.
For #36905.
Change-Id: I455428c051ec49b446b8b558a6f579cd9be4d796
Reviewed-on: https://go-review.googlesource.com/c/go/+/362734
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When //go:embed d matches directory d, it embeds the directory
tree rooted at d, but it excludes files beginning with . and _,
as well as files having problematic names that will not be packaged
into modules (names such as .git and com1).
After long discussions on #42328 and #43854, we decided to keep
the behavior of excluding . and _ files by default, but to allow the pattern
prefix 'all:' to override this default. This CL implements that change.
Note that paths like .git and com1 are still excluded, as they must be,
since they will never be packed into a module.
Fixes#43854.
Change-Id: I4f3731e14ecffd4b691fda3a0890b460027fe209
Reviewed-on: https://go-review.googlesource.com/c/go/+/359413
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In stencil.go, change doubleCheck to false, which will turn off some
double-checking code which isn't needed generally, now that we have lots
of tests of end-to-end runs.
Also, removed checkDictionary() which is unused and is unlikely to be
useful in the future.
Change-Id: I4e5acceab80f4904b174422bae21ca82cf04f943
Reviewed-on: https://go-review.googlesource.com/c/go/+/361923
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This is a port of CL 360955 to go/types. Note that go/types and types2
differ in handling of untyped nil within both Checker.shift and
Checker.implicitTypeAndValue.
A missing comment was added to Checker.indexExpr.
Change-Id: Ia9149ff9c0af68213c579090902ab7989828ddd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/362534
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Recent changes to runtime enabled crashdumps, which under some
circumstances apparently might result in memory being uploaded to
Microsoft. A change like this should go through the proper proposals
process where we can discuss how to gate it and what all of its
implications are.
This reverts CL 307372 and its cleanup CL 360617.
Change-Id: If2e74015899d746831da40546c82eacacdf739e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/362454
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change corrects a bug in the handling of module loading of
workspaces. Namely, there is an assumption by the module pruning code
that if a root module is selected then the packages of that module can
be resolved without loading the whole module graph. This is not true
in workspace mode because two workspace modules can require different
versions of a dependency. Worse, one workspace module can directly
require a depencency that is transitively required by another
workspace module, changing the version of that module loaded in the
fully expanded graph.
To correct this, a new 'workspace' pruning mode is added where the
roots are the workspace modules themselves, satisfying the assumption
made by the module pruning logic.
The rest of this change accounts for the new pruning mode where it's
used and correctly sets the requirements in this pruning mode.
Change-Id: I5d4d9877e492e196681f6ee9f8f18a08b4e95c61
Reviewed-on: https://go-review.googlesource.com/c/go/+/357169
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
CL 361411 improved error message for go version requirement, but forgot
to update the test in cmd/go to match new error message. That causes
longtest builders failed.
This CL changes mod_vendor_goversion.txt to match compiler error, and
limit fixedbugs/issue49368.go to run with -G=3 only.
Updates #49368
Change-Id: I125fe0a8c2a1595066d39c03e97819e7a1274e0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/361963
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This reverts commit 759eaa22ad.
Reason to revert: break unified IR builder
Though the unified IR is not for go1.18, it's the only user of types2
lazy resolution APIs at this moment. And it consistently failed after
CL 362254 is the sign that the change was wrong somehow.
Change-Id: I6bfc3192904fe2129fd3c165f0df8761e8eb441c
Reviewed-on: https://go-review.googlesource.com/c/go/+/361964
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TestPanicSystemstack spins up a subprocess that has 2 goroutines
deadlock on a runtime lock while on the system stack, with GOMAXPROCS=2.
Each goroutine is going to be running on a P, and then is going to wedge
itself up on that P.
If a GC is active and a worker starts executing (using a P), then it
could try to preempt a goroutine that is already blocked. It won't be
able to, so it'll just sit there forever trying to suspend it. At this
point there are no more Ps to execute the remaining goroutine that needs
to print something so the parent process can continue the test.
This change fixes this issue by disabling GCs in the child process. An
alternative fix could be to increase GOMAXPROCS in the child, but maybe
letting the GC be on (which assumes it'll always be able to *eventually*
suspend a G) is just asking for trouble.
Fixes#49388.
Change-Id: I405c9dad50e24e1e68f2c52a646538da15797fbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/361897
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently the debug call protocol implementation we use for testing is
riddled with write barriers, and called from a signal handler. This is
not safe, as write barriers need a P to execute.
Ideally this implementation would be rewritten to avoid the write
barriers, but it's not straightforward, and needs some thought. As a
temporary measure, disable GC during the debug call tests to avoid a
write barrier.
Note that this does not indicate a problem with real use of the debug
call protocol. Only our test implementation has this issue, because it
needs to get executed in a signal handler, normally a separate process
is interfacing with the protocol via process signals and ptrace (and the
like).
Fixes#49370.
Change-Id: Ic0fde5d0f4c64f9ecc9789b7dabb3954538fe0a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/361896
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Make it explicit in the code where we call under.
The asNamed and asTypeParam converters need to
stay: asNamed does resolution if necessary, and
asTypeParam may or may not call under() depending
on the next CL.
Reviewed uses of asNamed and .(*Named) for correctness.
Removed unnecessary Named.resolve call in lookup.
Change-Id: I2acf176925e00bd1703a00230a779aa65a8f5a51
Reviewed-on: https://go-review.googlesource.com/c/go/+/362254
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Go 1.17 introduced an unnecessary change to when a zip's data descriptor
is read for file entries, how it is parsed and how the crc32 field is
used.
Before Go 1.17, the data descriptor was read immediately after a file
entry's content. This continuous read is a pattern existing applications
have come to rely upon (for example, where reads at specific offsets
might be translated to HTTP range requests).
In Go 1.17, all data descriptors are immediately read upon opening the
file. This results in scattered and non-continuous reads of the archive,
and depending on the underlying reader, might have severe performance
implications. In addition, an additional object is now initialized for
each entry, but is mostly redundant.
Previously, the crc32 field in the data descriptor would return an error
if it did not match the central directory's entry. This check has
seemingly been unintentionally removed. If the central directory crc32
is invalid and a data descriptor is present, no error is returned.
This change reverts to the previous handling of data descriptors, before
CL 312310.
Fixes#48374Fixes#49089
Change-Id: I5df2878c4fcc9e500064e7175f3ab9727c82f100
Reviewed-on: https://go-review.googlesource.com/c/go/+/357489
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Mark a struct as "complete" with a non-nil (but possibly zero length)
fields list. Add a test when type-checking struct composite literals,
the same way we do for other composite literal types.
Fixes#49276.
Change-Id: If44a3d790bf7032ddcd155af49bdc47b1cdff4fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/361412
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Make system cert pools special, such that when one has extra roots
added to it we run verifications twice, once using the platform
verifier, if available, and once using the Go verifier, merging the
results.
This change re-enables SystemCertPool on Windows, but explicitly does
not return anything from CertPool.Subjects (which matches the behavior
of macOS). CertPool.Subjects is also marked deprecated.
Fixes#46287Fixes#16736
Change-Id: Idc1843f715ae2b2d0108e55ab942c287181a340a
Reviewed-on: https://go-review.googlesource.com/c/go/+/353589
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
CL 344955 and CL 359476 removed almost all // +build lines, but leaving
some assembly files and generating scripts. Also, some files were added
with // +build lines after CL 359476 was merged. Remove these or rename
files where more appropriate.
For #41184
Change-Id: I7eb85a498ed9788b42a636e775f261d755504ffa
Reviewed-on: https://go-review.googlesource.com/c/go/+/361480
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The previous change was an automated change that made gcPercent a
type-safe atomic variable. However, that introduced a lot of redundant
formal atomic loads of the variable. Remove them by only loading once in
each case, and reusing the value.
Change-Id: I49647135f423574f94506d456d1cc390150fad02
Reviewed-on: https://go-review.googlesource.com/c/go/+/357795
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Addr's MarshalBinary required two allocations in the case of a zone
existing, and AddrPort and Prefix both required three. This refactors
things slightly so that each marshal function only needs a single
allocation.
Change-Id: I9bde9969fedc1cad64bebb607188c4287f6a0d01
Reviewed-on: https://go-review.googlesource.com/c/go/+/361054
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When VerifyOptions.Roots is nil, default to using the platform X.509
certificate verification APIs on darwin, rather than using the Go
verifier. Since our oldest supported version of macOS is 10.12, we are
able to use the modern verification APIs, and don't need to resort to
the complex chain building trickery employed by chromium et al.
Unfortunately there is not a clean way to programmatically add test
roots to the system trust store that the builders would tolerate. The
most obvious solution, using 'security add-trusted-cert' requires human
interaction for authorization. We could also manually add anchors to
the constructed SecTrustRef, but that would require adding a whole
bunch of plumbing for test functionality, and would mean we weren't
really testing the actual non-test path. The path I've chosen here is
to just utilize existing valid, and purposefully invalid, trusted
chains, from google.com and the badssl.com test suite. This requires
external network access, but most accurately reflects real world
contexts.
This change removes the x509.SystemCertPool() functionality, which will
be ammended in a follow-up change which supports the suggested hybrid
pool approach described in #46287.
Updates #46287Fixes#42414Fixes#38888Fixes#35631Fixes#19561
Change-Id: I17f0d6c5cb3ef8a1f2731ce3296478b28d30df46
Reviewed-on: https://go-review.googlesource.com/c/go/+/353132
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The Addr type got an encoding.BinaryUnmarshaler implementation, but not
AddrPort and Prefix. This commit adds the missing implementation of that
interface to these types. It also adds two round trip tests that follow
the template of the existing one for Addr.
Updates #49298.
Change-Id: Iac633aed8aac579960815bb64d06ff3181214841
Reviewed-on: https://go-review.googlesource.com/c/go/+/360875
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We have AddrFrom4, AddrFrom6, AddrFromSlice and As4, As6, but we are
missing AsSlice, so this commit adds the missing function. It also gets
rid of the less ergonomic and inconsistently named IPAddrParts.
Updates #49298.
Change-Id: I1c6a2c32fc6c69b244ab49765412ffe3bbe7e5c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/360874
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change allows the check to pass unmodified under GopherJS, which
stack traces are formatted differently (due to being generated by
NodeJS). There are no other functions named `interestingGoroutines` in
the standard library, so it's very unlikely to create false negatives,
and will allow reduce the number of overlays GopherJS needs to maintain.
Change-Id: I925594c6c313ca35805811f240c8528241950547
GitHub-Last-Rev: 26b32efb22
GitHub-Pull-Request: golang/go#49128
Reviewed-on: https://go-review.googlesource.com/c/go/+/358154
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Damien Neil <dneil@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The old implement passed start - 1 or end in func lookup to adjust the offset.But if the time is close to the last zoneTrans, like the issue, testcase and comment, the "start" from lookup will be omega. It can't be adjusted correctly.
Fixes#49284
Change-Id: Ibaf82dc4db6d5dd3279796f003d2b19c38a26341
Reviewed-on: https://go-review.googlesource.com/c/go/+/360616
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Findley <rfindley@google.com>
Title doesn't handle Unicode punctuation and language-specific
capitalization rules. Replace the BUG comment with a Deprecated
one, suggesting a more robust alternative, and allowing Title
to be exposed to tooling.
Fixes#48367.
Change-Id: I952f1f37cd35b587a95893fb022827bdd9ec7de9
Reviewed-on: https://go-review.googlesource.com/c/go/+/359485
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Currently, newstack loads gp.stackguard0 twice to check for different
poison values. The race window between these two checks can lead to
unintentional stack doubling, and ultimately to stack overflows.
Specifically, newstack checks if stackguard0 is stackPreempt first,
then it checks if it's stackForceMove. If stackguard0 is set to
stackForceMove on entry, but changes to stackPreempt between the two
checks, newstack will incorrectly double the stack allocation.
Fix this by loading stackguard0 exactly once and then checking it
against different poison values.
The effect of this is relatively minor because stackForceMove is only
used by a small number of runtime tests. I found this because
mayMorestackMove uses stackForceMove aggressively, which makes this
failure mode much more likely.
Change-Id: I1f8b6a6744e45533580a3f45d7030ec2ec65a5fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/361775
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The amd64/arm64 relocation processing is used as a template
and updated for ppc64le.
This requires updating the TOC relocation handling code to
support linux type TOC relocations too (note, AIX uses
TOC-indirect accesses).
Noteably, the shared flag of go functions is used as a proxy
for the local entry point offset encoded in elf objects. Functions
in go ppc64le shared objects always[1] insert 2 instructions to
regenerate the TOC pointer.
[1] excepting a couple special runtime functions, see preprocess
in obj9.go for specific details of this behavior.
Change-Id: I3646e6dc8a0a0ffe712771a976983315eae5c418
Reviewed-on: https://go-review.googlesource.com/c/go/+/352829
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
consistentHeapStats is updated during a stack allocation, so a stack
growth during an acquire or release could cause another acquire to
happen before the operation completes fully. This may lead to an invalid
sequence number.
Fixes#49395.
Change-Id: I41ce3393dff80201793e053d4d6394d7b211a5b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/361158
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Currently the scavenger is paced to 1% of 1 CPU because it had
scalability problems. As of the last few CLs, that should be largely
resolved. This change resolves the TODO and paces the scavenger
according to 1% of overall CPU time.
This change is made separately to allow it to be more easily rolled
back.
Change-Id: I1ab4de24ba41c564960701634a128a813c55ece9
Reviewed-on: https://go-review.googlesource.com/c/go/+/358675
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently the scavenge rate is determined by a bunch of ad-hoc
mechanisms. Just use a controller instead, now that we have one.
To facilitate this, the scavenger now attempts to scavenge for at least
1 ms at a time, because any less and the timer system is too imprecise to
give useful feedback to the controller. Also increase the amount that we
scavenge at once, to try to reduce the overheads involved (at the
expense of a little bit of latency).
This change also modifies the controller to accept an update period,
because it's useful to allow that to be variable.
Change-Id: I8a15b2355d0a7c6cbac68c957082d5819618f7d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/353975
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change adds a new debug flag that makes the runtime map pages
PROT_NONE in sysUnused on Linux, in addition to the usual madvise calls.
This behavior mimics the behavior of decommit on Windows, and is helpful
in debugging the scavenger. sysUsed is also updated to re-map the pages
as PROT_READ|PROT_WRITE, mimicing Windows' explicit commit behavior.
Change-Id: Iaac5fcd0e6920bd1d0e753dd4e7f0c0b128fe842
Reviewed-on: https://go-review.googlesource.com/c/go/+/356612
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change modifies the scavenger to no longer hold the heap lock while
actively scavenging pages. To achieve this, the change also:
* Reverses the locking behavior of the (*pageAlloc).scavenge API, to
only acquire the heap lock when necessary.
* Introduces a new lock on the scavenger-related fields in a pageAlloc
so that access to those fields doesn't require the heap lock. There
are a few places in the scavenge path, notably reservation, that
requires synchronization. The heap lock is far too heavy handed for
this case.
* Changes the scavenger to marks pages that are actively being scavenged
as allocated, and "frees" them back to the page allocator the usual
way.
* Lifts the heap-growth scavenging code out of mheap.grow, where the
heap lock is held, and into allocSpan, just after the lock is
released. Releasing the lock during mheap.grow is not feasible if we
want to ensure that allocation always makes progress (post-growth,
another allocator could come in and take all that space, forcing the
goroutine that just grew the heap to do so again).
This change means that the scavenger now must do more work for each
scavenge, but it is also now much more scalable. Although in theory it's
not great by always taking the locked paths in the page allocator, it
takes advantage of some properties of the allocator:
* Most of the time, the scavenger will be working with one page at a
time. The page allocator's locked path is optimized for this case.
* On the allocation path, it doesn't need to do the find operation at
all; it can go straight to setting bits for the range and updating the
summary structure.
Change-Id: Ie941d5e7c05dcc96476795c63fef74bcafc2a0f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/353974
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The first stack-trace in #49361 shows that traceBuf must precede fin in
lockrank ordering, since traceBuf is acquired in StartTrace(), which
eventually leads to getting fin in queueFinalizer(). It is fine to move
traceBuf above fin, since there are no other conflicting dependencies.
The second stack trace shows that there is an edge bewtween reflectOffs
and fin, since reflectOffs is acquired in addReflectOff, and map
operations can lead to an allocation that eventually causes fin to be
acquired in queueFinalizer().
Fixes#49361
Change-Id: I8e857ef9ecdff37fdd229e4dba22e15bc71d4ba5
Reviewed-on: https://go-review.googlesource.com/c/go/+/361407
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The argument liveness tests expect outputs where a dead stack slot
has a poisoned value. If the test function is preempted at the
prologue, it will go with the morestack code path which will spill
all the argument registers. Mark them nosplit to avoid that.
Should fix#49354.
Change-Id: I3b13e72e925748687a53c494bfaa70f07d9496fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/361211
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
CL 360057 fixed missing update source type in storeArgOrLoad. However,
we should only update the type when processing struct/array. If we
update the type right before calling storeArgOrLoad, we may generate a
value with invalid type, e.g, OpStructSelect with non-struct type.
Fixes#49378
Change-Id: Ib7e10f72f818880f550aae5c9f653db463ce29b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361594
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently, we rely on a "crawling" step during export to identify
function and method bodies that need to be exported or re-exported so
we can trim out unnecessary ones and reduce build artifact sizes. To
catch cases where we expect a function to be inlinable but we failed
to export its body, we made this condition a fatal compiler error.
However, with generics, it's much harder to perfectly identify all
function bodies that need to be exported; and several attempts at
tweaking the algorithm have resulted in still having failure cases.
So for now, this CL changes a missing inline body into a graceful
failure instead.
Change-Id: I04b0872d0dcaae9c3de473e92ce584e4ec6fd782
Reviewed-on: https://go-review.googlesource.com/c/go/+/361403
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
The current code, introduced in CL 2422, mixes K bits of entropy with
the private key and message digest to generate the signature nonce,
where K is half the bit size of the curve. While the ECDLP complexity
(and hence security level) of a curve is half its bit size, the birthday
bound on K bits is only K/2. For P-224, this means we should expect a
collision after 2^56 signatures over the same message with the same key.
A collision, which is unlikely, would still not be a major practical
concern, because the scheme would fall back to a secure deterministic
signature scheme, and simply leak the fact that the two signed messages
are the same (which is presumably already public).
Still, we can simplify the code and remove the eventuality by always
drawing 256 bits of entropy.
Change-Id: I58097bd3cfc9283503e38751c924c53d271af92b
Reviewed-on: https://go-review.googlesource.com/c/go/+/352530
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This adds a debugging hook for optionally calling a "maymorestack"
function in the prologue of any function that might call morestack
(whether it does at run time or not). The maymorestack function will
let us improve lock checking and add debugging modes that stress
function preemption and stack growth.
Passes toolstash-check -all (except on js/wasm, where toolstash
appears to be broken)
Fixes#48297.
Change-Id: I27197947482b329af75dafb9971fc0d3a52eaf31
Reviewed-on: https://go-review.googlesource.com/c/go/+/359795
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This moves and slightly generalizes the -d debug flag parser from
cmd/compile/internal/base to cmd/internal/objabi so that we can use
the same debug flag syntax in other tools.
This makes a few minor tweaks to implementation details. The flag
itself is now just a flag.Value that gets constructed explicitly,
rather than at init time, and we've cleaned up the implementation a
little (e.g., using a map instead of a linear search of a slice). The
help text is now automatically alphabetized. Rather than describing
the values of some flags in the help text footer, we simply include it
in the flags' help text and make sure multi-line help text renders
sensibly.
For #48297.
Change-Id: Id373ee3b767e456be483fb28c110d025149be532
Reviewed-on: https://go-review.googlesource.com/c/go/+/359956
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A code comment on amd64 for windows and plan9 contained a snippet for
splitting apart the sec and nsec components of a unix timestamp, with
produced assembly below, which was then cleaned up by hand. When arm64
was ported, that code snippet in the comment went through the compiler
to produce some code that was then pasted and cleaned up. Unfortunately,
the comment had a typo in it, containing 8 zeros instead of 9.
This resulted in the constant used in the assembly being wrong, spotted
by @bufflig's eagle eyes. So, this commit fixes the comment on all three
platforms, and the assembly on windows/arm64.
Fixes#48072.
Change-Id: I786fe89147328b0d25544f52c927ddfdb9f6f1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/361474
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
TestHammerStoreLoad involves a stress test of StorePointer, which has a
write barrier. The "pointer" that is being written is not a real value,
which is generally fine (though not *really* safe) on 64-bit systems
because they never point to an actual object.
On 32-bit systems, however, this is much more likely. Because I can't
figure out how to rewrite the test such that it still is testing the
same conditions but is also using real pointers, just disable the GC
during the test, and make sure there isn't one currently in progress.
Fixes#49362.
Change-Id: If81883fedf06568132e6484f40c820aa69027a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/361455
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The new GC pacer has a bug where the hard goal isn't set in relation to
the original heap goal, but rather to the one already extrapolated for
overshoot.
In practice, I have never once seen this case arise because the
extrapolated goal used for overshoot is conservative. No test because
writing a test for this case is impossible in the idealized model the
pacer tests create. It is possible to simulate but will take more work.
For now, just leave a TODO.
Change-Id: I24ff710016cd8100fad54f71b2c8cdea0f7dfa79
Reviewed-on: https://go-review.googlesource.com/c/go/+/361435
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
These error messages contain the expected shortened revision in braces,
but don't explicitly tell the user that this is the expected one.
Just unified it with the "does not match version-control timestamp" error which does the same...
Change-Id: I8e07df7bd776fd1b39c4c90c4788cb3d626ea00b
GitHub-Last-Rev: d14681ad08
GitHub-Pull-Request: golang/go#42578
Reviewed-on: https://go-review.googlesource.com/c/go/+/269877
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
In modules that specify 'go 1.17' or higher, the go.mod file
explicitly requires modules for all packages transitively imported by
the main module. Users tend to use 'go mod download' to prepare for
testing the main module itself, so we should only download those
relevant modules.
In 'go 1.16' and earlier modules, we continue to download all modules
in the module graph (because we cannot in general tell which ones are
relevant without loading the full package import graph).
'go mod download all' continues to download every module in
'go list all', as it did before.
Fixes#44435
Change-Id: I3f286c0e2549d6688b3832ff116e6cd77a19401c
Reviewed-on: https://go-review.googlesource.com/c/go/+/357310
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
The behavior of all Curve methods and package functions when provided an
off-curve point is undefined, except for IsOnCurve which should really
always return false, not panic.
Change-Id: I52f65df25c5af0314fef2c63d0778db72c0f1313
Reviewed-on: https://go-review.googlesource.com/c/go/+/361402
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Adjust TypeDefn(), which is used by reportTypeLoop(), to work for nodes
with no Ntype set (which are all nodes in -G=3 mode). Normally,
reportTypeLoop() would not be called, because the types2 typechecker
would have already caught it. This is a possible way to report an
unusual type loop involving type params, which is not being caught by
the types2 type checker.
Updates #48962
Change-Id: I55edee46026eece2e8647c5b5b4d8dfb39eeb5f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/361398
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently allocToCache ham-handedly calls pageAlloc.allocRange on the
full size of the cache. This is fine as long as scavenged bits are never
set when alloc bits are set. This is true right now, but won't be true
as of the next CL.
This change makes allocToCache more carefully set the bits. Note that in
the allocToCache path, we were also calling update *twice*, erroneously.
The first time, with contig=true! Luckily today there's no correctness
error there because the page cache is small enough that the contig=true
logic doesn't matter, but this should at least improve allocation
performance a little bit.
Change-Id: I3ff9590ac86d251e4c5063cfd633570238b0cdbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/356609
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This doesn't handle every possible scenario,
but improves the one we can control. For example,
if the worker panics for some reason, we have no
way of knowing whether the panic occurred in an
expected way (while executing the fuzz target) or
due to an internal error in the worker. So any
panic will still be treated as a crash.
However, if it fails due to some internal bug that
we know how to catch, then the error should be
reported to the user without a new crasher being
written to testdata.
This is very difficult to test. The reasons an
internal error would occur is because something went
very wrong, and we have a bug in our code (which is
why they were previously panics). So simulating
a problem like this in a test is not really feasible.
Fixes#48804
Change-Id: I334618f84eb4a994a8d17419551a510b1fdef071
Reviewed-on: https://go-review.googlesource.com/c/go/+/361115
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This change implements the GC pacer redesign outlined in #44167 and the
accompanying design document, behind a GOEXPERIMENT flag that is on by
default.
In addition to adding the new pacer, this CL also includes code to track
and account for stack and globals scan work in the pacer and in the
assist credit system.
The new pacer also deviates slightly from the document in that it
increases the bound on the minimum trigger ratio from 0.6 (scaled by
GOGC) to 0.7. The logic behind this change is that the new pacer much
more consistently hits the goal (good!) leading to slightly less
frequent GC cycles, but _longer_ ones (in this case, bad!). It turns out
that the cost of having the GC on hurts throughput significantly (per
byte of memory used), though tail latencies can improve by up to 10%! To
be conservative, this change moves the value to 0.7 where there is a
small improvement to both throughput and latency, given the memory use.
Because the new pacer accounts for the two most significant sources of
scan work after heap objects, it is now also safer to reduce the minimum
heap size without leading to very poor amortization. This change thus
decreases the minimum heap size to 512 KiB, which corresponds to the
fact that the runtime has around 200 KiB of scannable globals always
there, up-front, providing a baseline.
Benchmark results: https://perf.golang.org/search?q=upload:20211001.6
tile38's KNearest benchmark shows a memory increase, but throughput (and
latency) per byte of memory used is better.
gopher-lua showed an increase in both CPU time and memory usage, but
subsequent attempts to reproduce this behavior are inconsistent.
Sometimes the overall performance is better, sometimes it's worse. This
suggests that the benchmark is fairly noisy in a way not captured by the
benchmarking framework itself.
biogo-igor is the only benchmark to show a significant performance loss.
This benchmark exhibits a very high GC rate, with relatively little work
to do in each cycle. The idle mark workers are quite active. In the new
pacer, mark phases are longer, mark assists are fewer, and some of that
time in mark assists has shifted to idle workers. Linux perf indicates
that the difference in CPU time can be mostly attributed to write-barrier
slow path related calls, which in turn indicates that the write barrier
being on for longer is the primary culprit. This also explains the memory
increase, as a longer mark phase leads to more memory allocated black,
surviving an extra cycle and contributing to the heap goal.
For #44167.
Change-Id: I8ac7cfef7d593e4a642c9b2be43fb3591a8ec9c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/309869
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
On ARM64 PE, when external linking, the PE relocation does not
have an explicit addend, and instead has the addend encoded in
the instruction or data. An instruction (e.g. ADRP, ADD) has
limited width for the addend, so when the addend is large we use
a label symbol, which points to the middle of the original target
symbol, and a smaller addend. But for an absolute address
relocation in the data section, we have the full width to encode
the addend and we should not use the label symbol. Also, since we
do not adjust the addend in the data, using the label symbol will
actually make it point to the wrong address. E.g for an R_ADDR
relocation targeting x+0x123456, we should emit 0x123456 in the
data with an IMAGE_REL_ARM64_ADDR64 relocation pointing to x,
whereas the current code emits 0x123456 in the data with an
IMAGE_REL_ARM64_ADDR64 relocation pointing to the label symbol
x+1MB, so it will actually be resolved to x+0x223456. This CL
fixes this.
Fixes#47557.
Change-Id: I64e02b56f1d792f8c20ca61b78623ef5c3e34d7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360895
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
In order to know the actual number of bytes
of the entire corpus entry, the coordinator
would likely need to unmarshal the bytes and
tally up the length. That's more work than it
is worth, so this change just clarifies that
the printed # of bytes is the length of the
entire file, not just the entry itself.
Fixes#48989
Change-Id: I6fa0c0206a249cefdf6335040c560ec0c5a55b4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/361414
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
https://golang.org/cl/246763 accidentally changed this to assign the old
value of vdsoPC to the upper half of sec as that is the last value in
R1.
The old value of vdsoPC is usually zero, so this typically works.
However, the reentrant case will have a non-zero value, resulting in a
bogus returned time. I am unsure if walltime is reachable from a signal
handler, so this may never occur.
Change-Id: I8562d6ec2a845fcffee9618d994b8ea57fbd199e
Reviewed-on: https://go-review.googlesource.com/c/go/+/361159
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This enables the elimination of convertibleToImpl again,
with the code structure close to the original non-generic
version, and closely matching the structure of assignableTo.
We also don't need the hasTerm tests; instead we can rely
directly on the mechanism of TypeParam.is which is feeding
a nil term if there are no specific types.
Change-Id: I0385acca779d75c3c961d06afb464714fe51705d
Reviewed-on: https://go-review.googlesource.com/c/go/+/361269
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Don't inline a function fn that has no shape parameters, but is passed
at least one shape arg. This means we must be inlining a non-generic
function fn that was passed into a generic function, and can be called
with a shape arg because it matches an appropriate type parameter. But
fn may include an interface conversion (that may be applied to a shape
arg) that was not apparent when we first created the instantiation of
the generic function. We can't handle this if we actually do the
inlining, since we want to know all interface conversions immediately
after stenciling. So, we avoid inlining in this case.
Fixes#49309.
Change-Id: I7b8ab7b13e58fdb0111db91bc92a91d313f7c2c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/361260
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Update cmd/doc and go/doc for the generics, by adding handling for type
parameters and the new embedded interface elements.
Specifically:
- Format type parameters when summarizing type and function nodes.
- Find the origin type name for instantiation expressions, so that
methods are associated with generic type declarations.
- Generalize the handling of embedding 'error' in interfaces to
arbitrary predeclared types.
- Keep embedded type literals.
- Update filtering to descend into embedded type literals.
Also add "any" to the list of predeclared types.
Updates #49210
Change-Id: I6ea82869f19c3cdbc3c842f01581c8fc7e1c2ee7
Reviewed-on: https://go-review.googlesource.com/c/go/+/359778
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The x/sys/windows package currently uses go:linkname for other facilities
inside of runtime that are not suitable to be exposed as a public API
due to their dangers but are still necessary for manipulating any
low-level plumbing that the runtime controls.
Logging, via the built-in println and panic handler, is one such
low-level plumbing feature. In this case, x/sys/windows/svc needs to be
able to redirect panics to the Windows event log. Because the event log
is a complicated interface, this requires a bit more fiddling than the
simple solution used on Android (baking it into runtime itself), and
because Windows services are very diverse, the event log might not even
always be a desirable destination.
This commit accomplishes this by exposing a function pointer called
"overrideWrite" that low-level runtime packages like x/sys/windows/svc
can use to redirect output logs toward the event log or otherwise.
It is not safe or acceptable to use as a generic mechanism, and for that
reason, we wouldn't want to expose this as a real stable API, similar to
the other instances of go:linkname in x/sys/windows. But for packages
that must interoperate with low-level Go runtime fundamentals, this is a
safety hatch for packages that are developed in tandem with the runtime.
x/sys/windows is one such package.
Updates #42888.
Change-Id: I77a32ff7e1494324e8cc38e792e007f86d32672d
Reviewed-on: https://go-review.googlesource.com/c/go/+/278792
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The test had been setting an arbitrary 200ms timeout to allow the
server's handler to set up before timing out. That is not only
potentially flaky on slow machines, but also typically much longer
than necessary. Replace the hard-coded timeout with a much shorter
initial timeout, and use exponential backoff to lengthen it if needed.
This allows the test to be run about 20x faster in the typical case,
which may make it easier to reproduce rare failure modes by running
with a higher -count flag.
For #43120
Change-Id: I1e0d0ec99d5a107fff56e3bcc7174d686ec582d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/361275
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
It appears Windows 7 ignores WER_FAULT_REPORTING_NO_UI WerSetFlags
API flag.
And now after CL 307372, runtime will display WER GUI dialogue.
We don't want to introduce random GUI dialogues during Go program
execution. So disable dump crash creation on Windows 7 altogether.
Updates #20498
Change-Id: Ie268a7d4609f8a0eba4fe9ecf250856b0a61b331
Reviewed-on: https://go-review.googlesource.com/c/go/+/360617
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
These functions are exported for the compiler and are used after
type checking is finished. There is no need to call under() in
their implementations; they can rely entirely on the public API.
This opens the door to moving them into the compiler eventually.
They may also be slightly more efficient.
Change-Id: Ib4f83d2dcf82e3c319c3147e01ecaea684553ea5
Reviewed-on: https://go-review.googlesource.com/c/go/+/361214
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
- reordered some functions for better organization
- renamed single arguments typ to t for consistency
- updated some comments
No functional changes.
Change-Id: I4362ac48044595cdf5c3d9eb7b2f7b94e776d65b
Reviewed-on: https://go-review.googlesource.com/c/go/+/360956
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Rename the isX predicates to allX to clearly identify that these
predicates are looking inside type parameters.
Introduce is_X as predicates that do not look
inside type parameters so we can see all call sites.
The next CL will rename them all back to isX.
Review all call sites and use correct predicate.
Replace the single helper function is with isBasic and allBasic.
Change-Id: I3430ccfc466fdedf4b58a6158f95d47b9020f7a5
Change-Id: I81116b87cf8f2e17526723c7440676d133057aca
Reviewed-on: https://go-review.googlesource.com/c/go/+/360955
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Type parameters only exist within the scope of a type or function
declaration, so there is really no reason to package-qualify them. It is
also confusing to do so, as it makes their type string look like a
defined type.
Fixes#49215
Change-Id: I986c527e78d45f3cadd75bc3b244e23dabe707ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/360938
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When drivers return driver.ErrBadConn, no meaningful
information about what the cause of the problem is
returned. Ideally the driver.ErrBadConn would be
always caught with the retry loop, but this is not
always the case. Drivers today must choose between
returning a useful error and use the rety logic.
This allows supporting both.
Fixes#47142
Change-Id: I454573028f041dfdf874eed6c254fb194ccf6d96
Reviewed-on: https://go-review.googlesource.com/c/go/+/333949
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fix idle connection reuse so that ConnMaxIdleTime clears down excessive
idle connections.
This now ensures that db.freeConn is ordered by returnedAt and that
connections that have been idle for the shortest period are reused
first.
In addition connectionCleanerRunLocked updates the next check deadline
based on idle and maximum life time information so that we avoid waiting
up to double MaxIdleTime to close connections.
Corrected the calling timer of connectionCleaner.
Fixes#39471
Change-Id: I6d26b3542179ef35aa13e5265a89bc0f08ba7fa1
Reviewed-on: https://go-review.googlesource.com/c/go/+/237337
Reviewed-by: Tamás Gulácsi <tgulacsi78@gmail.com>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Trust: Ian Lance Taylor <iant@golang.org>
On 64-bit, this is more efficient, and on ARM64, this prevents the time
from moving backwards due to the weaker memory model. On ARM32 due to
the weaker memory model, we issue a memory barrier.
Updates #48072.
Change-Id: If4695716c3039d8af14e14808af217f5c99fc93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/361057
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Pointers to arrays can be used to cast from a slice. We need
the shape of such type params to be different so we can compile
those casts correctly.
This is kind of a big hammer to fix#49295. It would be nice to
only do this when we know there's a []T->*[N]T conversion.
Fixes#49295
Change-Id: Ibda33057fab2dd28162537aab0f1244211d68e3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/361135
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
TestCPUProfileMultithreadMagnitude compares Go's CPU profile against the
OS's accounting of the process's execution time, expecting them to be
near equal. Background work from the runtime (especially in the garbage
collector) can add significant noise to that measurement and flakiness
to the test. Disable automatic GC cycles during the test.
Updates #49065
Change-Id: Ie88895bfea17374278c5187f3a83e9f486bd37fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/359934
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
This provides the runtime glue (_rt0_riscv64_linux_lib) for c-archive and c-shared
support, along with enabling both of these buildmodes on linux/riscv64.
Both misc/cgo/testcarchive and misc/cgo/testcshared now pass on this platform.
Fixes#47100
Change-Id: I7ad75b23ae1d592dbac60d15bba557668287711f
Reviewed-on: https://go-review.googlesource.com/c/go/+/334872
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The X3 (aka GP) register will potentially be loaded with the __global_pointer$ symbol
during program start up (usually by the dynamic linker). As such, non-Go code may depend
on the contents of GP and calculate offsets based on it, including code called via cgo
and signal handlers installed by non-Go code. As such, stop using the X3 register so
that there are fewer issues interacting between Go and non-Go code.
While here remove the X4 (TP) name from the assembler such that any references must
use the 'TP' name. This should reduce the likelihood of accidental use (like we do
for the 'g' register). The same applies for X3 (GP) when the -shared flag is given.
Updates #47100
Change-Id: I72e82b5ca3f80c46a781781345ca0432a4111b74
Reviewed-on: https://go-review.googlesource.com/c/go/+/351859
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a port of both CL 360396 and CL 360796 to go/types. The latter
is added to avoid introducing an intermediate bug.
An error message was adjusted in issue49296.go2, with a TODO to switch
to the types2 error.
Change-Id: Iede294b69b4e097e53876498f039ee18667568c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/360934
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Previously, opening a zip with (*Reader).Open could result in a panic if
the zip contained a file whose name was exclusively made up of slash
characters or ".." path elements.
Open could also panic if passed the empty string directly as an argument.
Now, any files in the zip whose name could not be made valid for
fs.FS.Open will be skipped, and no longer added to the fs.FS file list,
although they are still accessible through (*Reader).File.
Note that it was already the case that a file could be accessible from
(*Reader).Open with a name different from the one in (*Reader).File, as
the former is the cleaned name, while the latter is the original one.
Finally, made the actual panic site robust as a defense-in-depth measure.
Fixes CVE-2021-41772
Fixes#48085
Co-authored-by: Filippo Valsorda <filippo@golang.org>
Change-Id: I6271a3f2892e7746f52e213b8eba9a1bba974678
Reviewed-on: https://go-review.googlesource.com/c/go/+/349770
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Julie Qiu <julie@golang.org>
This is a port of CL 358597 to go/types. A comment was missing in the
base of applyTypeFunc, which had been there since the initial check-in
of types2; somehow it was not in go/types.
Change-Id: If08efd92d782dd3099b26254ae6e311c6cea8c3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/360477
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently, the syscall test suite takes very little time to run. It
stands to reason that pretty much every time, zero GCs execute.
With CL 309869, this changes because the minimum heap size is lowered,
triggering two bugs in the test suite.
One bug is in TestFcntlFlock, where a raw FD is wrapped in an os.File
whose last reference is passed into a Cmd. That FD is then closed by a
defer syscall.Close, instead of the os.File's Close, so the finalizer
may fire *after* that FD has already been reused by another test.
The second bug is in the child helper process of TestPassFD, where
there's a small window in which a temp file's FD is encoded for an
out-of-band unix domain socket message to the parent, but not yet sent.
The point of encoding is also the last reference that FD's os.File, so a
finalizer may run at any time. While it's safe for the finalizer to run
after the FD is sent, if it runs before, the send will fail, since unix
domain sockets require that any sent FDs are valid.
Change-Id: I2d1bd7e6db6efcc6763273217fd85cb5b9764274
Reviewed-on: https://go-review.googlesource.com/c/go/+/360575
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL replaces monoEdge's "report" field with fields "pos" and
"typ", and pushes the logic for formatting them into the report
loop. This avoids needing to allocate a function closure for each
edge.
Also tweak a test case so the two type parameters involved in the
cycle aren't both "T" so they're easier to understand.
Change-Id: I9d392ad1d99a4c5e89da4613084e885149ebad07
Reviewed-on: https://go-review.googlesource.com/c/go/+/360815
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This test assumes that two successive TCP connections will use different
source ports. This does not appear to be a universally safe assumption.
Rewrite the test to use httptrace to detect connection reuse instead.
Fixes#46707
Change-Id: Iebfbdfdeb77a1e6663a0c654dc847cc270c5d54d
Reviewed-on: https://go-review.googlesource.com/c/go/+/360854
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
It is now possible to do completely allocation-free UDP.
This is implemented completely separately from ReadFromUDP
because ReadFromUDP exists in a delicate balance to allow
mid-stack inlining. After performance-sensitive callers have
migrated to ReadFromUDPAddrPort, we may be able to simplify
ReadFromUDP to call ReadFromUDPAddrPort.
name old time/op new time/op delta
WriteToReadFromUDPAddrPort-8 4.71µs ± 2% 4.81µs ± 5% +2.18% (p=0.000 n=14+14)
name old alloc/op new alloc/op delta
WriteToReadFromUDPAddrPort-8 4.00B ± 0% 0.00B -100.00% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
WriteToReadFromUDPAddrPort-8 1.00 ± 0% 0.00 -100.00% (p=0.000 n=15+15)
Change-Id: I37f5ad9416a1d4333ed48d83474b2cf933b2a1be
Reviewed-on: https://go-review.googlesource.com/c/go/+/360600
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
See the recent change optimizing WriteMsgUDPAddrPort
for an explanation of why this change includes copy/paste/modify
instead of implementing WriteToUDP using WriteToUDPAddrPort.
name old time/op new time/op delta
WriteToReadFromUDPAddrPort-8 5.02µs ± 3% 4.71µs ± 2% -6.31% (p=0.000 n=15+14)
name old alloc/op new alloc/op delta
WriteToReadFromUDPAddrPort-8 68.0B ± 0% 4.0B ± 0% -94.12% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
WriteToReadFromUDPAddrPort-8 3.00 ± 0% 1.00 ± 0% -66.67% (p=0.000 n=15+15)
Change-Id: I301715e774de07eb6ccb4e329ccf2e554609abc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/360599
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL adds a check to ensure that generic Go code doesn't involve
any unbounded recursive instantiation, which are incompatible with an
implementation that uses static instantiation (i.e., monomorphization
or compile-time dictionary construction).
Updates #48098.
Change-Id: I9d051f0f9369ab881592a361a5d0e2a716788a6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/357449
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This is a port of CL 357917 to go/types. Some error messages in
assignability.go2 had to be adjusted. I left a TODO to investigate
whether we should align error messages.
Change-Id: Ia323ffe18bc08e82de62044f35b8b0f3edd7dc08
Reviewed-on: https://go-review.googlesource.com/c/go/+/360476
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 358594 to go/types. Some code in conversions.go had
to be trivially reorganized to align with types2 -- I'm not sure how
go/types diverged from the base.
Change-Id: I40ce247bbb3b9d0e87ce88c50e440c12774c0745
Reviewed-on: https://go-review.googlesource.com/c/go/+/360475
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
For constraint type inference failures where the type parameter doesn't
match the constraint, print the type parameter rather than its type name
object. This provides more flexibility for improving the error message
down the road.
Change-Id: I188871d6f26a16cd96e59770966a1ec65607b128
Reviewed-on: https://go-review.googlesource.com/c/go/+/360514
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When converting a constant to a type parameter, the result is never
constant (type parameters are not constant types), but we still need
to verfy that the constant is representable by each specific type in
the type set of the type parameter.
Fixes#49247.
Change-Id: I460983c7070b33baadce25dd23210e10930cfb2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/360396
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Use gp.m.curg instead of the gp when recording cpu profiler stack
traces. This ensures profiler labels are captured when systemstack or similar
is executing on behalf of the current goroutine.
After this there are still rare cases of samples containing the labelHog
function, so more work might be needed. This patch should fix ~99% of the
problem.
Fixes#48577.
Change-Id: I27132110e3d09721ec3b3ef417122bc70d8f3279
Reviewed-on: https://go-review.googlesource.com/c/go/+/351751
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
TestExec and TestExecHelper check for a workaround of a particular OS
bug on darwin that's triggered more often via asynchronous preemption.
As part of this, the test sets up 100 CPU-bound goroutines, and sets
GOMAXPROCS to 50, sleeping for a little bit before calling Exec. Thus
far, this is fine because the scheduler runs the Execing goroutine in a
timely manner. However, CL 309869 will reduce the minimum heap size,
causing a GC to happen during the test.
On a 16 CPU machine, with GOMAXPROCS at 50, and 100 CPU-bound
goroutines, both the OS scheduler and the Go scheduler are severly
oversaturated. As a result, the test often (not always, but often) runs
out for the full lifetime of those 100 goroutines, which run for about 1
second.
The minimum heap size reduction is not necessary to trigger this; an
additional call to runtime.GC in the helper is also sufficient to
trigger this delay.
The delay on its own isn't great, since it adds a whole second to
all.bash on its own. However, it also seems correlated with other
subprocess tests in the syscall package, namely TestPassFD and
TestFcntlFlock. These tests fail in a fairly superficial way: the file
descriptor for the temporary directories they make gets clobbered, is
closed, or becomes stale.
Change-Id: I213dd5e38967d19a8b317e6d4c5024b57f9e3fed
Reviewed-on: https://go-review.googlesource.com/c/go/+/360574
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add asan tests to check the use of Go with -asan option.
Currenly, the address sanitizer in Go only checks for error
memory access to heap objects.
TODO: Enable check for error memory access to global objects.
Updates #44853.
Change-Id: I83579f229f117b5684a369fc8f365f4dea140648
Reviewed-on: https://go-review.googlesource.com/c/go/+/298615
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Go exchanges siginfo and sigevent structures with the kernel. They
contain unions, but Go's use is limited to the first few fields. Pad out
the rest so the size Go sees is the same as what the Linux kernel sees.
This is a follow-up to CL 342052 which added the sigevent struct without
padding, and to CL 353136 which added the padding but with an assertion
that confused several type-checkers. It updates the siginfo struct as
well so there are no bad examples in the defs_linux_*.go files.
Reviewed-on: https://go-review.googlesource.com/c/go/+/353136
Change-Id: I9610632ff0ec43eba91f560536f5441fa907b36f
Reviewed-on: https://go-review.googlesource.com/c/go/+/360094
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Add explicit address sanitizer instrumentation to the runtime and
syscall packages. The compiler does not instrument the runtime
package. It does instrument the syscall package, but we need to add
a couple of cases that it can't see.
Refer to the implementation of the asan malloc runtime library,
this patch also allocates extra memory as the redzone, around the
returned memory region, and marks the redzone as unaddressable to
detect the overflows or underflows.
Updates #44853.
Change-Id: I2753d1cc1296935a66bf521e31ce91e35fcdf798
Reviewed-on: https://go-review.googlesource.com/c/go/+/298614
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: fannie zhang <Fannie.Zhang@arm.com>
This is one step towards optimizing WriteMsgUDPAddrPort.
Further steps remain, namely to avoid the syscall.Sockaddr interface,
as we do for UDPConn.WriteToUDP and UDPConn.ReadFromUDP.
A previous change optimized ReadMsgUDPAddrPort by having
ReadMsgUDP call ReadMsgUDPAddrPort rather than the other way around.
This change does not implement WriteMsgUDP in terms of WriteMsgUDPAddrPort,
because a few layers deep, on posix platforms only
(in ipToSockaddrInet4 and ipToSockaddrInet6),
is special handling of zero-length IP addresses and IPv4zero.
It treats IP(nil) as equivalent to 0.0.0.0 or ::,
and 0.0.0.0 as equivalent to :: in an IPv6 context.
Based on the comments, I suspect that this treatment was intended
for the Listen* API, not the Write* API, but it affects both,
and I am nervous about changing the behavior for Write*.
The netip package doesn't have a way to represent a "zero-length IP address"
as distinct from an invalid IP address (which is a good thing),
so to implement WriteMsgUDP using WriteMsgUDPAddrPort,
we would have to duplicate this special handling at the start of WriteMsgUDP.
But this handling depends on whether the UDPConn is an IPv4 or an IPv6 conn,
which is also platform-specific information.
As a result, every attempt I made to implement WriteMsgUDP using
WriteMsgUDPAddrPort while preserving behavior ended up
being considerably worse than copy/paste/modify.
This does mean that WriteMsgUDP and WriteMsgUDPAddrPort will have
different behavior in these cases.
name old time/op new time/op delta
ReadWriteMsgUDPAddrPort-8 5.29µs ± 6% 5.02µs ± 7% -5.14% (p=0.000 n=13+15)
name old alloc/op new alloc/op delta
ReadWriteMsgUDPAddrPort-8 128B ± 0% 64B ± 0% -50.00% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
ReadWriteMsgUDPAddrPort-8 4.00 ± 0% 2.00 ± 0% -50.00% (p=0.000 n=15+15)
Change-Id: Ia78eb49734f4301d7772dfdbb5a87e4d303a9f7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/360597
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Instead of implementing ReadMsgUDPAddrPort in terms of ReadMsgUDP,
do it the other way around. This keeps the code minimal while
still avoiding allocs.
We could also rearrange ReadMsgUDP to be mid-stack inlined to avoid
allocating the *UDPAddr, but anyone who's trying to eliminate
allocs should use ReadMsgUDPAddrPort instead anyway,
because ReadMsgUDP will always allocate at least once (the IP slice).
name old time/op new time/op delta
ReadWriteMsgUDPAddrPort-8 5.26µs ± 3% 5.29µs ± 6% ~ (p=0.429 n=12+13)
name old alloc/op new alloc/op delta
ReadWriteMsgUDPAddrPort-8 176B ± 0% 128B ± 0% -27.27% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
ReadWriteMsgUDPAddrPort-8 5.00 ± 0% 4.00 ± 0% -20.00% (p=0.000 n=15+15)
Change-Id: I15228cb4ec4f13f2f390407b6c62c44c228e7201
Reviewed-on: https://go-review.googlesource.com/c/go/+/360596
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously, when resolving references of form
(https://golang.org/?hello).ResolveReference(?)
we only used URL.RawQuery to determine whether or not a query part is
defined. Go 1.7 introduced URL.ForceQuery as a flag for the situation
where a query part is provided but empty. But we did not use it in
ResolveReference. This leads to the erroneous output
https://golang.org/?hello
when the correct output should be
https://golang.org/?
This commit rectifies that error.
Fixes#46033
Change-Id: I05bc0b48bf2bbf13b4ddc0dd10599ea613dc2188
Reviewed-on: https://go-review.googlesource.com/c/go/+/317930
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Damien Neil <dneil@google.com>
When type inference cannot infer type arguments it prints the list of
inferred type arguments (often empty) at the end of the error message.
This was meant as debugging support only. Removed for now.
Eventually we should provide a better error message.
Fixes#49272.
Change-Id: I68d43a6ace91081009cab0f2fbad7bfbddf5e76b
Reviewed-on: https://go-review.googlesource.com/c/go/+/360554
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
If a identical input is already present in the corpus, don't re-add it.
This may happen when the same input produces a different coverage map,
causing the coordinator to think it has found a new input.
This fixes a race between reading/writing cached inputs.
Fixes#48721
Change-Id: I4807602f433c2b99396d25ceaa58b827796b3555
Reviewed-on: https://go-review.googlesource.com/c/go/+/359755
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
This is a port of CL 357814 from go/types to types2 with minor
adjustments due to small differences in error handling code.
Change-Id: I72ecc4532e8349f569cabb38006f3d8ff517bf30
Reviewed-on: https://go-review.googlesource.com/c/go/+/360276
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When checking assignability, a value of a named type (incl. a type parameter)
can never be assigned to a variable of a differently named type. Specifically,
if the types are two differently named type parameters, then values of one are
never assignable to variables of the other.
This CL clarifies the assignabiliy rules and simplifies the implementation.
Fixes#49242.
Change-Id: Id72a2c9bed5cdb726855e7a707137db1009e7953
Reviewed-on: https://go-review.googlesource.com/c/go/+/360274
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Add a comment how strings of length 0 are treated and
that they always will result in the return of a string
equal to the constant string "".
The previous implementation would return a string header that uses
runtime.zerobase as the backing array pointer while the string constant
"" has 0 as pointer value.
Using 0 has the backing array pointer is also the behaviour of
string([]byte(input)) which makes the new behaviour a better drop in
replacement.
Change-Id: Ic5460e9494b6708edbdfa4361e878d50db54ba10
Reviewed-on: https://go-review.googlesource.com/c/go/+/360255
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Martin Möhrmann <martin@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This code is only generated when linking cgo internally with fixed
position code. This feature of the internal linker is only supported
on ppc64le/linux targets. This moves ppc64le/linux a little closer
to supporting PIE when internal linking.
This is more similar to the implementation suggested in the power
architecture elfv2 supplement, and works with both PIE and static
code.
Change-Id: I0b64e1c22b9e07b5151378d2ab19ee0e50405fc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/357332
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is heavily based on CL 341336 by Joe Tsai and CL 351452 by
Jay Conrod.
T.Run and T.Name use a map[string]int64 to hold the next suffix to use
when duplicate names are passed to T.Run. This map necessarily retains
one entry per unique name. However, it's a waste of memory to retain
one entry per duplicate name: when we encounter the Nth duplicate, we
know that names 00 through N-1 have been used just by looking at N.
We do still need to store (and check for collisions againsts) explicit
names provided by the caller. For example, if the user passes in "a",
then "a#01", then "a" again, we cannot deduplicate the second "a" to
"a#01" — we need to instead skip ahead to "a#02". We can do so by
checking the count of "a", then generating a proposed deduplicated
name, then double-checking that proposed name against only the
explicit names so far.
This somewhat reduces memory usage for tests that spawn large numbers
of duplicate subtests, but doesn't solve the problem of memory growth
for fuzzing — we still have to track all of the explicit,
user-provided subtest names, and in a long-running fuzz test that set
alone may be unbounded.
This fixes memory growth for the example described in
https://golang.org/issue/44517#issuecomment-897104060,
but not the one in
https://golang.org/issue/44517#issuecomment-933825661.
For #44517
Change-Id: Ia159ecfcf44561ba67508d3af6377c27856df31d
Reviewed-on: https://go-review.googlesource.com/c/go/+/354749
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Use a pointer reciever to avoid copying the hiter struct when
checking if it is intialized.
Found through profiling that showed reflect map iteration spending
a good amount of time in duffcopy.
This change will also help other MapIter methods checking hiter struct
initialization like Value() and Key().
name old time/op new time/op delta
MapIterNext-12 97.9ns ± 4% 83.8ns ± 2% -14.37% (p=0.000 n=10+10)
Change-Id: I73ab964fa28061ee7e6d5c663a85048bd2e0274e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360254
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Martin Möhrmann <martin@golang.org>
The intention is for BenchmarkFooBar functions to map 1:1 to drawFooBar
functions. Recent draw.go changes have added more drawFooBar functions
and have further modified the mapping, as fallback drawFooBar functions
aren't invoked as often as they used to.
This commit restores the 1:1 mapping and reorganizes the BenchmarkFooBar
functions in the same order as the matching drawFooBar functions appear.
Also modify a TestDraw test case from vgradGreen(255) = {0, 136, 0, 255}
to vgradGreen(90) = {0, 48, 0, 90}. Doing so matches the existing "The
source pixel is {0, 48, 0, 90}" comment but also makes for a more
interesting test case, as the source pixel is no longer fully opaque.
Fully opaque is already covered by the vgradGray() test case on the next
line.
Also fix a "variable source" comment copy-pasto when the source image is
actually uniform, not variable.
Also add a func DrawMask type switch comment about interface types.
Change-Id: I828e71f2ee8ec617f523c8aafb118fb7ba166876
Reviewed-on: https://go-review.googlesource.com/c/go/+/358974
Trust: Nigel Tao <nigeltao@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a port of the idea used in CL 359134 from go/parser to syntax,
with adjustments due to the slightly different structure of the two
parsers, and some refactoring to simplify the logic.
Fixes#49175.
Change-Id: Ib4955bde708f2b08345f35523e6094c03ab3076c
Reviewed-on: https://go-review.googlesource.com/c/go/+/360135
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
There are multiple things preventing the -memprofilerate flag from
working right now:
- CmdFlags.MemProfileRate has type int64, which is currently not
supported by the compiler's reflection-based registerFlags.
Unfortunately, rather than letting you know this, registerFlags
simply ignores this field.
- Nothing consumes CmdFlags.MemProfileRate anyway. startProfile
instead uses a package-local memprofilerate variable that is never
set to anything.
Fix this by making CmdFlags.MemProfileRate an int (that's what
runtime.MemProfileRate is anyway) and using it in startProfile. While
we're here, prevent similar flag parsing bugs in the future by making
registerFlags panic if it encounters a flag field of unsupported type.
Change-Id: Ib9a1fcd8f4c5e9d7175a4fabc375f31e79774f9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/359955
Trust: Austin Clements <austin@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Currently, the compiler will emit any const that doesn't fit in an
int64 to go_asm.h like
#define const_stackPreempt constant.intVal{val:(*big.Int)(0xc000c06c40)}
This happens because dumpasmhdr formats the constant.Value using the
verb "%#v". Since constant.Value doesn't implement the GoString()
method, this just prints the Go-syntax representation of the value.
This happens to work for small integer constants, which go/constant
represents directly as an int64, but not for integer constants that
don't fit in an int64, which go/constant represents as a big.Int.
Make these constants usable by changing the formatting verb to "%v",
which will call the String() method, giving a reasonable result in all
cases.
Change-Id: I365eeb88c8acfc43ff377cc873432269bde3f541
Reviewed-on: https://go-review.googlesource.com/c/go/+/359954
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Fix two defer bugs related to adding/removing open defer entries.
The bugs relate to the way that we add and remove open defer entries
from the defer chain. At the point of a panic, when we want to start
processing defer entries in order during the panic process, we need to
add entries to the defer chain for stack frames with open defers, since
the normal fast-defer code does not add these entries. We do this by
calling addOneOpenDeferFrame() at the beginning of each time around the
defer loop in gopanic(). Those defer entries get sorted with other open
and non-open-coded defer frames.
However, the tricky part is that we also need to remove defer entries if
they end not being needed because of a recover (which means we are back
to executing the defer code inline at function exits). But we need
to deal with multiple panics and in-process defers on the stack, so we
can't just remove all open-coded defers from the the defer chain during
a recover.
The fix (and new invariant) is that we should not add any open-coded
defers to the defer chain that are higher up the stack than an open-coded
defer that is in progress. We know that open-coded defer will still be
run until completed, and when it is completed, then a more outer frame
will be added (if there is one). This fits with existing code in gopanic
that only removes open-coded defer entries up to any defer in progress.
These bugs were because of the previous inconsistency between adding and
removing open defer entries, which meant that stale defer entries could
be left on the list, in these unusual cases with both recursive
panics plus multiple independent (non-nested) cases of panic & recover.
The test for #48898 was difficult to add to defer_test.go (while keeping
the failure mode), so I added as a go/test/fixedbug test instead.
Fixes#43920
Updates #43941Fixes#48898
Change-Id: I593b77033e08c33094315abf8089fbc4cab07376
Reviewed-on: https://go-review.googlesource.com/c/go/+/356011
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
Improved readability, replaced constant time bit masked operations with
named functions, added comments. The behavior of every function should
be unchanged.
The largest change is the logic that in p224Contract checks if the value
is greater than or equal to p. Instead of a lot of error-prone masking,
we run a throwaway subtraction chain and look at the final borrow bit.
We could also not throw away the subtraction chain output and do a
constant time select instead of another masked subtraction, but we'd
still have to fix any underflows (because these are unsaturated limbs
and they underflow at 2^32 instead of 2^28). That's similar but
different from the carry-down chain we do elsewhere in that function
(which does undeflow fixing and borrow at the same time). I thought
having both variations in the same function would be confusing. Here's
how it would look like.
var b uint32
var outMinusP p224FieldElement
for i := 0; i < len(out); i++ {
outMinusP[i], b = bits.Sub32(out[i], p224P[i], b)
}
for i := 0; i < 3; i++ {
mask := maskIfNegative(outMinusP[i])
outMinusP[i] += (1 << 28) & mask
// Note we DON'T borrow here, because it happened above.
}
for i := 0; i < len(out); i++ {
out[i] = select32(b, out[i], outMinusP[i])
}
Change-Id: I00932e8f171eff7f441b45666dccfd219ecbbc50
Reviewed-on: https://go-review.googlesource.com/c/go/+/326311
Trust: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Julie Qiu <julie@golang.org>
This change creates a formal exported interface for the GC pacer and
creates tests for it that simulate some series of GC cycles. The tests
are completely driven by the real pacer implementation, except for
assists, which are idealized (though revise is called repeatedly).
For #44167.
Change-Id: I0112242b07e7702595ca71001d781ad6c1fddd2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/353354
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change adds two fields to gcControllerState: stackScan, used for
pacing decisions, and scannableStackSize, which directly tracks the
amount of space allocated for inuse stacks that will be scanned.
scannableStackSize is not updated directly, but is instead flushed from
each P when at an least 8 KiB delta has accumulated. This helps reduce
issues with atomics contention for newly created goroutines. Stack
growth paths are largely unaffected.
StackGrowth-48 51.4ns ± 0% 51.4ns ± 0% ~ (p=0.927 n=10+10)
StackGrowthDeep-48 6.14µs ± 3% 6.25µs ± 4% ~ (p=0.090 n=10+9)
CreateGoroutines-48 273ns ± 1% 273ns ± 1% ~ (p=0.676 n=9+10)
CreateGoroutinesParallel-48 65.5ns ± 5% 66.6ns ± 7% ~ (p=0.340 n=9+9)
CreateGoroutinesCapture-48 2.06µs ± 1% 2.07µs ± 4% ~ (p=0.217 n=10+10)
CreateGoroutinesSingle-48 550ns ± 3% 563ns ± 4% +2.41% (p=0.034 n=8+10)
For #44167.
Change-Id: Id1800d41d3a6c211b43aeb5681c57c0dc8880daf
Reviewed-on: https://go-review.googlesource.com/c/go/+/309589
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change moves heapLive and heapScan updates on gcController into a
method for better testability. It's also less error-prone because code
that updates these fields needs to remember to emit traces and/or call
gcController.revise; this method now handles those cases.
For #44167.
Change-Id: I3d6f2e7abb22def27c93feacff50162b0b074da2
Reviewed-on: https://go-review.googlesource.com/c/go/+/309275
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently GC pacer updates are applied somewhat haphazardly via direct
field access. To facilitate ease of testing, move these field updates
into methods. Further CLs will move more of these updates into methods.
For #44167.
Change-Id: I25b10d2219ae27b356b5f236d44827546c86578d
Reviewed-on: https://go-review.googlesource.com/c/go/+/309274
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
CL 333389 erroneously moved traceGCSweepDone inside the sl.valid block
that it introduced in mcentral.cacheSpan, when it should have left it
outside that scope, because the trace event is created unconditionally
at the top of the method.
Fixes#49231.
Change-Id: If719c05063d4f4d330a320da6dc00d1e9d8102e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/359775
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change provides ability to create dumps on Windows that can be used by
"dlv core" command. Currently only full dumps can be correctly read by Delve.
Below are the steps to create and use the dumps.
1. Configure Windows OS to collect dumps before running the program.
Instructions on how to do the configuration are here:
https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps.
In order for Delve to read the dump, set the DumpType to full dump, i.e. DumpType=2.
2. Go program only generates dumps when the environment variable GOTRACEBACK
is set to crash. Run command "set GOTRACEBACK=crash" before running the program.
3. Dump files will be generated in %LOCALAPPDATA%\CrashDumps
4. Use Delve command "dlv core" to open the dump, e.g.: "dlv core a.exe a.exe.3840.dmp".
Fixes#20498
Change-Id: Ib9aa82e7aea9da19594dc49348876997b24e9600
Reviewed-on: https://go-review.googlesource.com/c/go/+/307372
Run-TryBot: Alessandro Arzilli <alessandro.arzilli@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Currently, the runtime zeroes allocations in several ways. First, small
object spans are always zeroed if they come from mheap, and their slots
are zeroed later in mallocgc if needed. Second, large object spans
(objects that have their own spans) plumb the need for zeroing down into
mheap. Thirdly, large objects that have no pointers have their zeroing
delayed until after preemption is reenabled, but before returning in
mallocgc.
All of this has two consequences:
1. Spans for small objects that come from mheap are sometimes
unnecessarily zeroed, even if the mallocgc call that created them
doesn't need the object slot to be zeroed.
2. This is all messy and difficult to reason about.
This CL simplifies this code, resolving both (1) and (2). First, it
recognizes that zeroing in mheap is unnecessary for small object spans;
mallocgc and its callees in mcache and mcentral, by design, are *always*
able to deal with non-zeroed spans. They must, for they deal with
recycled spans all the time. Once this fact is made clear, the only
remaining use of zeroing in mheap is for large objects.
As a result, this CL lifts mheap zeroing for large objects into
mallocgc, to parallel all the other codepaths in mallocgc. This is makes
the large object allocation code less surprising.
Next, this CL sets the flag for the delayed zeroing explicitly in the one
case where it matters, and inverts and renames the flag from isZeroed to
delayZeroing.
Finally, it adds a check to make sure that only pointer-free allocations
take the delayed zeroing codepath, as an extra safety measure.
Benchmark results: https://perf.golang.org/search?q=upload:20211028.8
Inspired by tapir.liu@gmail.com's CL 343470.
Change-Id: I7e1296adc19ce8a02c8d93a0a5082aefb2673e8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/359477
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
This reverts CL 359096.
Updates #47788.
Reason for revert: -buildmode=shared may have actually been working in a few very specific cases. We should not remove -buildmode=shared until we have implemented an alternative to support those few cases.
Change-Id: Ia962b06abacc11f6f29fc29d092773be175e32f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/359575
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Use of these functions is almost (but not) always a bad idea.
Very rarely they are necessary, and third-party implementations
(using a mutex and an atomic word, say) cannot integrate as well
with the race detector as implmentations in package sync itself.
Fixes#45435.
Change-Id: I0128ca48ef5e0a3b09c913f0f3a7ee5c56388000
Reviewed-on: https://go-review.googlesource.com/c/go/+/319769
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, there is a chance that the sweep termination condition could
flap, causing e.g. runtime.GC to return before all sweep work has not
only been drained, but also completed. CL 307915 and CL 307916 attempted
to fix this problem, but it is still possible that mheap_.sweepDrained is
marked before any outstanding sweepers are accounted for in
mheap_.sweepers, leaving a window in which a thread could observe
isSweepDone as true before it actually was (and after some time it would
revert to false, then true again, depending on the number of outstanding
sweepers at that point).
This change fixes the sweep termination condition by merging
mheap_.sweepers and mheap_.sweepDrained into a single atomic value.
This value is updated such that a new potential sweeper will increment
the oustanding sweeper count iff there are still outstanding spans to be
swept without an outstanding sweeper to pick them up. This design
simplifies the sweep termination condition into a single atomic load and
comparison and ensures the condition never flaps.
Updates #46500.
Fixes#45315.
Change-Id: I6d69aff156b8d48428c4cc8cfdbf28be346dbf04
Reviewed-on: https://go-review.googlesource.com/c/go/+/333389
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Proposal #37641 reserved the paths "example" and "test" for end users,
so no path beginning with either of those elements may be added to the
standard library.
(We are unlikely to add them by accident, but this test codifies the
policy accepted in the proposal.)
Fixes#37641
Change-Id: I999064180336c923d4918a1176c371b8f5666f8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/359576
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This new function, although different in signature from other
reflect functions, allows the caller to avoid the panic caused by
nil embedded fields in calls to FieldByIndex.
Fixes#48218
Change-Id: I447f135bb789148c27ae3f2f23dcf43094f4c1de
Reviewed-on: https://go-review.googlesource.com/c/go/+/357962
Trust: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test currently uses only SIGKILL (which cannot be trapped by the
worker process) and SIGILL (which is handled by the Go runtime, and
does pretty unambiguously indicate a crash). It is missing a third
(and perhaps more likely) case: a signal like SIGTERM that is handled
by the Go runtime and causes the test to terminate, but nonetheless
does not indicate a crash.
Change-Id: I0595a0917e977e8eb2c24ae8b706d734ce3b2f4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/359482
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Normally, when fuzzing identifies a failure it saves the failing input
to the package's testdata directory. However, the testdata directory
for packages outside the main module is normally not writable — and
when it is, writing to a testdata directory inside the module cache
would corrupt the checksum for that module (and permanently alter the
behavior of that version of the module globally).
In the future we could consider a flag to allow failures to be saved
to an alternate location, or perhaps in the build cache; or, we could
suppress writes entirely and rely on the user to identify and copy the
failing input from the test log. However, it's a bit late in the cycle
for that big a design decision right now. For Go 1.18, we will just
enforce that the package to be fuzzed resides in the main module,
which is typically a writable VCS checkout.
Fixes#48495
Change-Id: I8d3d56372394b1aaa94fa920399c659363fa17fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/359414
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
We had been repeating conditions for specific platforms and
architectures to gate fuzzing tests, but the more of those tests we
add the more we will have to update if the set of supported platforms
and archictures expands over time.
We also ought to provide a friendlier error message when
'go test -fuzz' is used on non-supported platforms.
This change adds predicates in cmd/internal/sys, which already
contains similar predicates for related functionality (such as the
race detector), and uses those predicates in 'go test' and TestScript.
For #48495
Change-Id: If24c3997aeb4d201258e21e5b6cf4f7c08fbadd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/359481
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
There have a few updates to the Go object file in this cycle (e.g.
FuncInfo format change, some changes in constant values), and it
is not compatible with the old tools. Bump up the version number.
Change-Id: Id176979b139c76ded2c50f2678eb313934326d6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/359483
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When these packages are released as part of Go 1.18,
Go 1.16 will no longer be supported, so we can remove
the +build tags in these files.
Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs
as defined in src/cmd/dist/buildtool.go, which need to continue
to build with Go 1.4 for now.
Also reverted src/vendor and src/cmd/vendor, which will need
to be updated in their own repos first.
Manual changes in runtime/pprof/mprof_test.go to adjust line numbers.
For #41184.
Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e
Reviewed-on: https://go-review.googlesource.com/c/go/+/344955
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
cmd/go has its own //go:build evaluator, which is needed for
patterns like 'all'. The code is a modified copy of some unexported
routines from the go/build package. Update it by copying those
again and re-modifying them. The modifications are primarily the new
func eval and also ignoring errors.
This CL will need to be backported to Go 1.17, or else Go 1.17
will break when faced with certain //go:build-only repos during
'go list all' or 'go mod tidy'.
For #41184.
Fixes#49198.
Change-Id: Ie0fe3caa8d49004935ecd76d7977f767fe50e317
Reviewed-on: https://go-review.googlesource.com/c/go/+/359355
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Each gentraceback call uses a different set of flags. Combine these into
a common variable, only adjusted as necessary.
The effective changes here are:
* cgo traceback now has _TraceJumpStack. This is a no-op since it
already passes curg.
* libcall traceback now has _TraceJumpStack. This is a behavior change
and will allow following stack transitions if a libcall is performed on
g0.
* VDSO traceback drops _TraceTrap. vdsoPC is a return address, so
_TraceTrap was not necessary.
Change-Id: I351b3cb8dc77df7466795d5fbf2bd8f30bba2d37
Reviewed-on: https://go-review.googlesource.com/c/go/+/358900
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The net/http package has a documented contract that if DialContext, DialDLSContext, Dial or DialTLS are specified in an instance of Transport, that they will be used to set up the connection. If they are not specified, then a reasonable fallback is made (e.g. using the net package).
This is ordinarily true, except for when compiling for the js/wasm target, where the browser's Fetch API is preferred in all cases (except for when it is undefined/unavailable) and therefore the dial functions are all ignored. As a result, the http.Transport implementation under js/wasm doesn't meet that contract.
This PR updates the RoundTrip behaviour of http.Transport so that if DialContext, DialTLSContext, Dial or DialTLS are specified, they are used as expected. The Fetch API will be used as a fallback if they are not specified.
Fixes#27495
Change-Id: I88c6eb6ffdd077827b421d606f3e60ebdafd538f
GitHub-Last-Rev: 948a0ed97e
GitHub-Pull-Request: golang/go#46923
Reviewed-on: https://go-review.googlesource.com/c/go/+/330852
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Damien Neil <dneil@google.com>
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Now that Go 1.17 is out and Go 1.15 is unsupported,
removing // +build lines can be done safely: in the worst case,
if code is compiled using Go 1.16 the toolchain will detect
the presence of a //go:build without // +build and fail the build.
(It will not silently choose the wrong files.)
Note that +build lines will continue to work in Go sources forever.
This just provides a mechanism for users who are done with
Go 1.16 to remove them easily, by running "go fix".
Also update for new generics AST.
For #41184.
Fixes#48978.
Change-Id: I11a432c319e5abd05ad68dda9ccd7a7fdcc8bbb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/240611
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Fail out when loading a file that contains a dynamic symbol table
command that indicates a larger number of symbols than exist in the
loaded symbol table.
Thanks to Burak Çarıkçı - Yunus Yıldırım (CT-Zer0 Crypttech) for
reporting this issue.
Fixes#48990
Fixes CVE-2021-41771
Change-Id: Ic3d6e6529241afcc959544b326b21b663262bad5
Reviewed-on: https://go-review.googlesource.com/c/go/+/355990
Reviewed-by: Julie Qiu <julie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Katie Hockman <katie@golang.org>
This is a port of 4 CLs from types2: CL 356010, CL 357333, CL 357410,
and CL 357249. These 4 CLs are all related to implementing conversions,
and porting them together saved time (particularly because go/types was
already threading a *reason argument in some places).
Change-Id: Ic89b608d7096b61bfb9f7d71fdae2cc50b0ed70e
Reviewed-on: https://go-review.googlesource.com/c/go/+/359137
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a rough port of CL 354131 to go/* libraries, though in practice
I just tried to reconcile any places where the phrase "type list"
occurred in the source. This resulted in adjusting quite a bit more code
than initially expected, including a few lingering cases in the
compiler.
Change-Id: Ie62a9e1aeb831b73931bc4c78bbb6ccb24f53fb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/359135
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Now that we allow eliding 'interface' from constraint types, we need to
be a bit more careful about not consuming a '[' when parsing the next
expression after "type T [". We want to check if the next expression is
an identifier not followed by ']', in which case we're in a generic
type, but need to avoid parsing index or slice expressions. Such
expressions aren't valid array lengths because these expressions are
never constant, so when encountering a following '[' we can instead
assume that this is a type parameter field with array or slice type
constraint.
Test cases are added for the related issues #49174 and #49175, along
with a flag to enable tracing error tests.
For #49174
For #49175
Change-Id: I0476ef20c4c134ac537118272f20caaf123ee70e
Reviewed-on: https://go-review.googlesource.com/c/go/+/359134
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
CL 352057 added track argument stack slot liveness, and updated
TestTracebackArgs for argument liveness. But when optimization is
disabled, all arguments are considered lived. The abiSel does not
consider this case and return wrong expected result.
To fix this, checking if we are running in a noopt builder and return
the correct expected result. Also, skipping TestTracebackArgs in quick
mode, since when quick mode run the test without optimization disable.
Updates #45728
Change-Id: I3737a1b1a5fa0c711fbb3218205f2f6e34f36260
Reviewed-on: https://go-review.googlesource.com/c/go/+/359196
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The bootstrap directories are built with the Go 1.4 go command,
and they will retain the // +build lines until we bump the bootstrap
toolchain to Go 1.17 or later.
cmd/dist builds cmd/go and all its dependencies, using the
assembler, compiler, and linker that were built using Go 1.4.
We don't want to have to keep // +build lines in cmd/go and
all its dependencies, so this CL changes cmd/dist to understand
the //go:build lines.
cmd/dist is a standalone Go program that must itself build with
very old Go releases, so we cannot assume go/build/constraint
is available. Instead, implement a trivial parser/evaluator.
For #41184.
Change-Id: I84e259dec3bd3daec3f82024eb3500120f53096d
Reviewed-on: https://go-review.googlesource.com/c/go/+/359314
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We may revisit this decision in a future release. By disallowing this
for Go 1.18 we are ensuring that we don't lock in the generics design
in a place that may need to change later. (Type declarations are the
primary construct where it crucially matters what the underlying type
of a type parameter is.)
Comment out all tests that rely on this feature; add comments referring
to issue so we can find all places easily should we change our minds.
Fixes#45639.
Change-Id: I730510e4da66d3716d455a9071c7778a1e4a1152
Reviewed-on: https://go-review.googlesource.com/c/go/+/359177
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Use ".fslckout" or "_FOSSIL_" files to correctly identify the root of
Fossil checkout directories.
Previously, Go has assumed VCS checkouts are indicated by a dot-file
named after the VCS command (eg, .git, .hg, .fossil). This is not
normally true for Fossil, but has worked so far since Go downloads
repositories into a ".fossil" file before opening (checking out).
Using the incorrect path prevents Go identifying Fossil checkouts and
correctly tagging with -buildvcs (to be added in a follow up CL).
Change-Id: I3c030a0b600dfe7f4b3fcf1551b1d7cb84629b81
Reviewed-on: https://go-review.googlesource.com/c/go/+/357954
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently, for stack traces (e.g. at panic or when runtime.Stack
is called), we print argument values from the stack. With register
ABI, we may never store the argument to stack therefore the
argument value on stack may be meaningless. This causes confusion.
This CL makes the compiler keep trace of which argument stack
slots are meaningful. If it is meaningful, it will be printed in
stack traces as before. If it may not be meaningful, it will be
printed as the stack value with a question mark ("?"). In general,
the value could be meaningful on some code paths but not others
depending on the execution, and the compiler couldn't know
statically, so we still print the stack value, instead of not
printing it at all. Also note that if the argument variable is
updated in the function body the printed value may be stale (like
before register ABI) but still considered meaningful.
Arguments passed on stack are always meaningful therefore always
printed without a question mark. Results are never printed, as
before.
(Due to a bug in the compiler we sometimes don't spill args into
their dedicated spill slots (as we should), causing it having
fewer meaningful values than it should be.)
This increases binary sizes a bit:
old new
hello 1129760 1142080 +1.09%
cmd/go 13932320 14088016 +1.12%
cmd/link 6267696 6329168 +0.98%
Fixes#45728.
Change-Id: I308a0402e5c5ab94ca0953f8bd85a56acd28f58c
Reviewed-on: https://go-review.googlesource.com/c/go/+/352057
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Rename structuralType to singleType throughout. This reflects
more closely what the function does: if a type set consists of
exactly one type term, singleType returns the corresponding type.
Rename singleUnder to structure. The structure function returns
the "type structure" of a type, either its underlying type for
a non-type parameter, or the single underlying type (if it exists)
for a type parameter.
Change constraint type inference to use the structure type for
inference, unless the structure type is the underlying type of
a single defined type, in which case it uses the latter. This
preserves existing behavior while making constraint type inference
slightly more flexible.
Change-Id: I38ee89ffdabd12bfeaa0be2ad6af8fb373c11fc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/359015
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
isNamed(t) is easily confused with asNamed(t) != nil (e.g., we
have isPointer(t) that is defined as asPointer(t) != nil).
This rename also helped clarifying a couple of places in the
assignability rules where it makes sense to simply look for
types that have names.
Change-Id: Ie995908613a26883ffe0562343d297a1e981e9ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/358621
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL changes the convenience converters asT to use under instead
of optype. To make sure the effect is well understood, in a first
step, all asT functions are renamed to toT so that we can see which
call sites are affected. In almost all places, the change is what we
want. In some places we may get more conservative behavior (which is
easy to relax if need be). In some places (function calls through a
type parameter, append built-in) we now use singleUnder instead, for
a more general behavior, matching other primary expressions or built-
ins.
This change removes the last use of optype and thus also theTop and
top, all of which have been deleted from the code.
The next CL renames the toT converters back to their asT form.
Change-Id: I35d1ad866ce46de175a055b36ef577d99bb9de22
Reviewed-on: https://go-review.googlesource.com/c/go/+/358597
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Similar to conversions, handle ordinary cases first, followed by
type-by-type assignability tests in case of type parameters with
specific types in their type sets.
Add a new class of type checker tests, in testdata/spec, which
I hope we can populate over time with tests following the spec
organization. Moved the conversions.go2 tests in the same dir.
Change-Id: Iac253ae375c08022bdc39e92e3951ec3f509e432
Reviewed-on: https://go-review.googlesource.com/c/go/+/357917
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The behavior of is/underIs was murky with the presence of a top type term
(corresponding to a type set that is not constrained by any types, yet the
function argument f of is/underIs was called with that term).
Change is/underIs to call f explicitly for existing specific type terms,
otherwise return the result of f(nil). Review all uses of is/underIs and
variants.
This makes the conversion code slightly more complicated because we need
to explicitly exclude type parameters without specific types; but the
code is clearer now.
Change-Id: I6115cb46f7f2a8d0f54799aafff9a67c4cca5e30
Reviewed-on: https://go-review.googlesource.com/c/go/+/358594
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Previously, the worker would attempt to deflake
an input that was reported to have caused new
coverage. The chances of a flake causing new
coverage seem pretty low to me, and even if it
was a flake that caused it, adding that input to
the cache doesn't seem like a bad thing. The
input is already going to be deflaked during
minimization anyway. If by some off-chance the
code is causing a lot of flaky coverage
increases, and the user doesn't want minimization
to occur, then setting -fuzzminimizetime=1x will
deflake in the way they want without minimizing.
This can be documented as needed.
This fixes a bug where the mem.header().count
could have been one too large if an unrecoverable
crash occured while deflaking an input that
caused code coverage.
Fixes#49047
Change-Id: Ibdf893d7a89a46dd700702afb09e35623615390e
Reviewed-on: https://go-review.googlesource.com/c/go/+/358094
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Julie Qiu <julie@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
cmd/go is not subject to all the same restrictions as most of cmd.
In particular it need not be buildable with the bootstrap toolchain.
So it is better to keep as little code shared between cmd/go and
cmd/compile, cmd/link, cmd/cgo as possible.
cmd/internal/str started as cmd/go/internal/str but was moved
to cmd/internal in order to make use of the quoted string code.
Move that code to cmd/internal/quoted and then move the rest of
cmd/internal/str back to cmd/go/internal/str.
Change-Id: I3a98f754d545cc3af7e9a32c2b77a5a035ea7b9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/355010
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
For base generic type that is written to export file, we need to mark
all of its methods, include exported+unexported methods, as reachable,
so they can be available for instantiation if necessary. But markType
only looks for exported methods, thus causing the crash in #49143.
To fix this, we introduce new method p.markGeneric, to mark all methods
of the base generic type.
This issue has happend for a while (maybe since we add generic
import/export during go1.18 cycle), and was un-intentionally "fixed" in
CL 356254, when we agresssively call p.markEmbed(t). CL 357232 fixed
that wrong agressive behavior, thus reproduce the bug on tip.
Fixes#49143
Change-Id: Ie64574a05fffb282e9dcc8739df4378c5b6b0468
Reviewed-on: https://go-review.googlesource.com/c/go/+/358814
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Const strings can be marked readonly. This is particularly
important for this relatively large table (88kb).
This is a follow-up to CL 315189.
The generation script is a bit awkward. It needs access to crypto/elliptic
internals, but also needs to be package main. Work around this by
exporting those internals with the "tablegen" build tag.
This requires changing the function signature at the Go-asm bridge.
As long as we're here, shrink the point argument type as well;
the net result is three fewer words of params.
Performance impact is probably noise.
name old time/op new time/op delta
ScalarBaseMult/P256-8 11.4µs ± 2% 11.3µs ± 1% -1.32% (p=0.000 n=19+16)
ScalarBaseMult/P224-8 579µs ± 1% 577µs ± 0% -0.30% (p=0.024 n=19+20)
ScalarBaseMult/P384-8 2.31ms ± 4% 2.34ms ± 4% +1.25% (p=0.033 n=20+20)
ScalarBaseMult/P521-8 1.33ms ± 0% 1.33ms ± 1% ~ (p=0.173 n=18+17)
ScalarMult/P256-8 42.7µs ± 0% 42.7µs ± 2% ~ (p=0.989 n=20+20)
ScalarMult/P224-8 579µs ± 0% 579µs ± 0% ~ (p=0.538 n=19+18)
ScalarMult/P384-8 2.32ms ± 3% 2.34ms ± 5% ~ (p=0.235 n=19+20)
ScalarMult/P521-8 1.33ms ± 1% 1.34ms ± 2% ~ (p=0.141 n=17+20)
Change-Id: I3bee56df34ae61ca8829791d2e67e058ecc8ddbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/339591
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
If we receive an async signal while running in the VDSO, such as a
SIGABRT or SIGSEGV sent from another process, we fail to print the
stacktrace with "runtime: unknown pc <vdso PC>".
We already have machinery to handle SIGPROF in the VDSO, but it isn't
hooked up for other signals. Add it to the general signal traceback
path.
This case is covered by TestSegv by making the test more strict w.r.t.
accepted output.
Fixes#47537
Change-Id: I755585f70e0c23e207e135bc6bd2aa68298e5d24
Reviewed-on: https://go-review.googlesource.com/c/go/+/339990
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 64070 removed lockOSThread from the cgocall path, but didn't update
the signal-in-cgo detection in sighandler. As a result, signals that
arrive during a cgo call are treated like they arrived during Go
execution, breaking the traceback.
Update the cgo detection to fix the backtrace.
Fixes#47522
Change-Id: I61d77ba6465f55e3e6187246d79675ba8467ec23
Reviewed-on: https://go-review.googlesource.com/c/go/+/339989
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Unlike what the comment says, the GC can see this pointer.
Might as well make it a real pointer, even though ^uintptr(0)
isn't currently causing problems.
Removed the comment about GC not seeing the pointer.
Change-Id: I04bc1fd4848698bec6afb79bd5fda671dfc9a073
Reviewed-on: https://go-review.googlesource.com/c/go/+/241661
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Colin Arnott <colin@urandom.co.uk>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
_g_, _p_, and _m_ are primarily vestiges of the C version of the
runtime, while today we prefer Go-style variable names (generally gp,
pp, and mp).
This change replaces all remaining uses of _m_ with mp. There are very
few remaining and all replacements are trivial.
[git-generate]
cd src/runtime
rf 'mv canpanic._m_ canpanic.mp'
GOOS=solaris \
rf 'mv semasleep._m_ semasleep.mp'
GOOS=aix GOARCH=ppc64 \
rf 'mv semasleep._m_ semasleep.mp'
Change-Id: I83690f7b4d4dc57557963100e9a2560ff343f3e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/307813
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
There were two main outer switch statements in node() that can just be
combined. Also, for simplicity, changed an IsCmp() conditional into just
another case in the switch statement.
Also, the inner OCALL switch statement had a bunch of fairly duplicate
cases. Combined the cases that all had no special semantics, into a
single default case calling transformCall().
In the OCALL case in dictPass(), got rid of a check for OFUNCINST (which
will always have been removed by this point). Also, eliminated an assert
that could cause unneded failures. transformCall() should always be
called if the node op is still OCALL, so no need to assert on the ops of
call.X.
Added an extra test in issue47078.go, to explicitly check for case where
the X argument of a call is a DOTTYPE.
Change-Id: Ifb3f812ce12820a4ce08afe2887f00f7fc00cd2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/358596
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Pull in CL 358034 (and some more changes with passing tests) with:
go get -d golang.org/x/tools@f916b54
go mod tidy
go mod vendor
This teaches x/tools/cmd/bundle and the package loader it uses about
the new export data version.
Fixes#49159.
Change-Id: Icc36e77e602b1cd2da03708f20d05a66fcf693cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/358620
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
CR bits and CR fields should be treated separately. Some instructions
modify an entire CR, a CR field, or a single CR bit.
Add a new argument class for CR bits, and teach the assembler the
recognize them as names like CR0LT or CR2SO, and update the CR
bit logic instructions to use them. They will no longer accept
register field (CRn) type arguments.
Fixes#46422
Change-Id: Iaba127d88abada0c2a49b8d3b07a976180565ae4
Reviewed-on: https://go-review.googlesource.com/c/go/+/357774
Run-TryBot: Paul Murphy <murp@ibm.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Add utimensat as a wrapper around the libc function of the same name.
utimensat was added in macOS 10.13 which is the minimum supported
release since Go 1.17 dropped support for macOS 10.12.
This also allows to drop the fallback to setattrlistTimes which was
used to set timestamps with nanosecond resolution before utimensat could
be used, see #22528 and CL 74952.
Updates #22528
Change-Id: I87b6a76acf1d642ceede9254f7d9d06dddc3fd71
Reviewed-on: https://go-review.googlesource.com/c/go/+/358274
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These are the runtime support functions for letting Go code interoperate
with the C/C++ address sanitizer. Calls to asanread/asanwrite are now
inserted by the compiler with the -asan option. Calls to
asanunpoison/asanpoison will be from other runtime functions in a
subsequent CL.
Updates #44853.
Change-Id: I9e8fc0ce937828bc7f4a8b6637453ddc3862c47b
Reviewed-on: https://go-review.googlesource.com/c/go/+/298613
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The -asan option compiles Go code to use the address sanitizer. This is
intended for use when linking with C/C++ code compiled with -fsanitize=address.
When memory blocks are passed back and forth between C/C++ and Go, code in
both languages will agree as to whether the memory is validly allocated or not,
and will report errors for any use of invalid memory.
Updates #44853.
Change-Id: I0209002ef795cc1c823daae557fb80c906158db3
Reviewed-on: https://go-review.googlesource.com/c/go/+/298612
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Remove a unnecessary statement in the test function, the variables
aren't checked afterwards. Also remove return statements in helper
functions and remove the declaration that a the helper function return a
value. The return value isn't used in the current state of code
Change-Id: I5bc384104c1002c4138e0894938778ae9710ce4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/358714
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
When adding a large constant to a register we generate two adds,
we may generate two ADD instructions if the constant does not fit
in one ADD but does fit in two. This is generally fine except that
if the target register is SP (such as in function prologues or
epilogues for functions with large frames), this creates an
intermediate state that the SP is not 0 nor the full frame size.
For signal safety (preemption signal and profiling signal) we
require that the frame is either not created at all or fully
created, meaning that the SP must be written in a single
instruction. Splitting to two adds breaks the requirement. So not
splitting it.
(We could mark such instructions not async-preemptible. But
profiling signal can still cause problems.)
(We could generate "ADD $c1, SP, Rtmp; ADD $c2; Rtmp; SP" to save
an instruction if that is desired, while still ensuring that SP
is written in a single instruction.)
May fix flaky failures like https://build.golang.org/log/11537ec020a902b0ec0fc065f61161b729eb9880
Change-Id: I5cf38a6a028afe01aa3b6eeb163487bbd504b64f
Reviewed-on: https://go-review.googlesource.com/c/go/+/358436
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Bump the export version to a new value iexportVersionGo1_18 (2). This
will give a better error message when old compilers/tools encounter the
new export format (that includes parameterized types and functions).
We are also making a breaking change in the format:
- a 'kind' byte is added to constant values
Also updated tinter() to pass the implicit bit through during type
substitution.
Tested that all tests still pass if the iexportVersionCurrent is changed
back to 1 in typecheck/iexport.go, iimporter/iimport.go, and
gcimporter/iimport.go
Updates #47654
Change-Id: I1dbeb167a97f6c7e0b7e0c011d6bada5db312b36
Reviewed-on: https://go-review.googlesource.com/c/go/+/357049
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Dan Scales <danscales@google.com>
The -asan option causes the compiler to add instrumentation for the
C/C++ address sanitizer. Every memory read/write will be replaced
by a call to asanread/asanwrite.
This CL also inserts asan instrumentation during SSA building.
This CL passes tests but is not usable by itself. The actual
implementation of asanread/asanwrite in the runtime package, and
support for -asan in the go tool and tests, will follow in subsequent
CLs.
Updates #44853.
Change-Id: Ia18c9c5d5c351857420d2f6835f0daec2ad31096
Reviewed-on: https://go-review.googlesource.com/c/go/+/298611
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We want to set a finalizer on splicePipe, so make it large enough to
not use the tiny allocator. Otherwise the finalizer will not run until
the rest of the tiny allocation can be freed. This only matters on
32-bit systems.
Fixes#48968
Change-Id: I8eb3c9f48fdccab7dc79c5b918d4257b6151ee91
Reviewed-on: https://go-review.googlesource.com/c/go/+/358114
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Generic function symbols sometimes have % in them, like:
main.B2[%2eshape.string_0].m2·f
Which confuses this code because it doesn't esacpe % when
using this string as a format string, instead of a format argument.
Or could we get rid of the . -> %2e rewrite somehow?
I think it comes from LinkString.
Change-Id: I3275501f44cf30485e9d4577e0dfa77996d4939e
Reviewed-on: https://go-review.googlesource.com/c/go/+/357837
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The method of using references to dictionaries to hold methods
live during linker deadcode elimination wasn't working very well.
I implemented a new scheme in the CL below this, so this CL strips
out the old method.
The new method has the added benefit of having 0 runtime overhead
(unlike the stuff we're ripping out here, which does have a small overhead).
Update #48047
Change-Id: I68ac57119792d53c58f1480f407de6ab2bb53211
Reviewed-on: https://go-review.googlesource.com/c/go/+/357836
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
On wasm, the wasm_exec.js helper passes the command line arguments and
environment variables via a reserved space in the wasm linear memory.
Increase this reserved space from 4096 to 8192 bytes so more environment
variables can fit into the limit.
Later, after https://golang.org/cl/350737 landed, we can switch to the
WASI interface for getting the arguments and environment. This would
remove the limit entirely.
Fixes#49011
Change-Id: I48a6e952a97d33404ed692c98e9b49c5cd6b269b
Reviewed-on: https://go-review.googlesource.com/c/go/+/358194
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Now that we've removed the necessity for subscripts in importers, we can
effectively eliminate them from the the type parameter API by removing
them from the type string.
Change-Id: Ic4491b0dea27b0e0ce2d0636dccfaf05168ef9e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/357814
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
When running benchmarks with high -count and no tests (either at all or
filtered with -run), the time for runTests to check for tests -count
times can add a significant delay to starting benchmarks.
To avoid this delay, make runTests bail out on the second iteration if
the first found no tests to run. We expect the same tests to run every
time, so there is no reason to duplicate work.
One caveat: the testing docs do not explicitly require the same subtests
to be run on every call, so this could break tests that depend on
multiple runs to actually run all tests. I consider such tests invalid,
but some may exist.
Fixes#49050
Change-Id: I7b34f3832b31493cc089ee0555e231f4dc690154
Reviewed-on: https://go-review.googlesource.com/c/go/+/356669
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- change _TypeSet.hasTerms() to report if a type set has actual types
(excluding a "universe" term)
- handle empty type set type arguments correctly
- bring comments up-to-date in Checker.satisfies
Change-Id: I87f9a1096ebb21a1b08c87a9b59f400f3bc2f040
Reviewed-on: https://go-review.googlesource.com/c/go/+/358175
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This updates the testing package documentation to reference the
specification for the benchmark format, and points users to our
standard tools for working with benchmark data. (It's somewhat
remarkable how widely used benchstat appears to be given that we don't
mention it anywhere!)
Change-Id: Idbb4416d2fde9606ea7e6c15595f3b9e6a38f3b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/357589
Trust: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing DrawMask method is generic and is therefore calling the At().RGBA() method for every pixel of the mask and the source.
Do a specific implementation when the mask is *image.Alpha (which is
common) and use use the PixOffset method to increase performances.
name old time/op new time/op delta
RGBA2-12 1.60ms ± 0% 1.13ms ± 1% -29.16% (p=0.008 n=5+5)
GenericMaskOver-12 915µs ± 4% 926µs ± 1% ~ (p=0.190 n=5+4)
RGBA64Over-12 1.53ms ± 3% 1.21ms ± 2% -20.74% (p=0.008 n=5+5)
GrayOver-12 1.36ms ± 2% 1.01ms ± 7% -26.27% (p=0.008 n=5+5)
Fixes: #46395
Change-Id: Iaeaa8cfcc6a3fe93eb19b361f3bf076e41cac5b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/323749
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
Trust: Andrew Gerrand <adg@golang.org>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
CL 358117 fixed a bug that Phi's argument wasn't updated correctly after
removing a predecessor of Block. This CL factor out the code that
updates phi argument into a Block's method, so it's easier to use,
maintain and hopefully prevent that kind of bug in the future.
Change-Id: Ie9741e19ea28f56860425089b6093a381aa10f5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/357964
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
removePred and removeArg do different things. removePred moves the last
predecessor to index k, whereas removeArg slides all the args k or
greater down by 1 index.
Kind of unfortunate different behavior in things named similarly.
Fixes#49122
Change-Id: I9ae409bdac744e713f4c121f948e43db6fdc8542
Reviewed-on: https://go-review.googlesource.com/c/go/+/358117
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Implement singleUnder[String] which determines a single underlying type
for a given type: either the underlying type, or the single underlying
type for a type parameter, if it exists. Use singleUnder[String] instead
of optype for copy built-in.
This CL removes a dependency on optype and also makes the copy built-in
slighty more general for generic arguments (the source argument may be
constrained by a slice or string simultaneously).
Change-Id: Ia329e96afc69a09d2ca3b1f82fe712d4f7ba1d9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/357413
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Since CL 282892, functions are always compiled before closures. To do
that, when walking the closure, it is added to its outer function queue
for scheduling compilation later. Thus, a closure may be added to queue
more than once, causing the ICE dues to being compiled twice.
To fix this, catching the re-walking of the closure expression and do
not add it to the compilation queue.
Fixes#49029
Change-Id: I7d188e8f5b4d5c4248a0d8e6389da26f1084e464
Reviewed-on: https://go-review.googlesource.com/c/go/+/357960
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The -asan option causes the linker to link against the runtime/asan
package in order to use the C/C++ address sanitizer.
This CL passes tests but is not usable by itself. The actual
runtime/asan package, and support for -asan in the go tool and the
compiler, and tests, are in separate CLs.
Updates #44853.
Change-Id: Ifc6046c1f75ba52777cbb3d937a4b66e91d5798d
Reviewed-on: https://go-review.googlesource.com/c/go/+/298610
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- slightly refactor convertibleTo and convertibleToImpl
- provide ability to return a conversion failure cause
- add detailed cause for generic conversions
For #47150.
Change-Id: Ie97d89be0234414ef4df22a6920e18acc944a102
Reviewed-on: https://go-review.googlesource.com/c/go/+/357249
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
There's no need to say "type parameter" for a type parameter. The
name is sufficient (they are always named), and the prose is followed
by "constrained by".
Change-Id: I98df8caa1432b8b7a874e58da6e3ed6be102b4a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/357410
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
CL 356254 fixed crawling of embeddable types during inline. However, we
are too agressive, since when we call markEmbed for every type seen
during inlining function body. That leads to false positive that for a
non-embedded type, its unexported methods are also marked inline.
Instead, we should only look at struct type that we seen during inlining
function body, and calling markEmbed for all of its embedded fields.
Fixes#49094
Change-Id: I6ef9a8bf1fc649ec6bf75e4883f6031ec8560ba1
Reviewed-on: https://go-review.googlesource.com/c/go/+/357232
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Add a new interface method, MarkImplicit, to allow marking interfaces as
implicit from outside the type-checker. This is necessary so that we can
capture the implicit bit in export data, and use it from importers.
For #48424
For #49040
Change-Id: I999aba2a298f92432326d7ccbd87fe133a2e1a72
Reviewed-on: https://go-review.googlesource.com/c/go/+/357796
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This introduces a number of new classifications which will make it
easier to generate functions to assemble the new instructions of
ISA 3.1, and potentially earlier versions.
No code generation changes should occur as a result of these. These
allow finer control over how an opcode is matched to an optab entry.
Literal values are now classified based on the smallest number of bits
needed to encode, and matching rules will accept a literal if it
can be zero/sign extended to fit a larger literal class.
Likewise, support classifying even register numbers for GPR, VSX, and
FPR instructions. Some instructions require and even/odd register pair,
and these are usually represented by specifying the even register, and
similarly encoded.
Likewise, add a unit test for the argument classifier function (aclass).
This caught an off-by-one bug in aclass which is also fixed.
Updates #44549
Change-Id: Ia03013aea8b56c4d59b7c3812cdd67ddb3b720b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/350152
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
There is already a mechanism using inlgen to rename labels insided
inlined functions so that they are unique and don't clash with loops in
the outer function. This is used for OLABEL and OGOTO. Now that we are
doing inlining of OFOR loops, we need to do this translation for OBREAK,
OCONTINUE, and OFOR. I also added the translation for ORANGE loops, in
anticipation of a CL that will allow inlining of ORANGE for loops.
Fixes#49100
Change-Id: I2ccddc3350370825c386965f4a1e4bc54d3c369b
Reviewed-on: https://go-review.googlesource.com/c/go/+/357649
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Currently gcController.gcPercent is read non-atomically by
gcControllerState.revise and gcTrigger.test, but these users may
execute concurrently with an update to gcPercent.
Although revise's results are best-effort, reading it directly in this
way is, generally speaking, unsafe.
This change makes gcPercent atomically updated for concurrent readers
and documents the complete synchronization semantics.
Because gcPercent otherwise only updated with the heap lock held or the
world stopped, all other reads can remain unsynchronized.
For #44167.
Change-Id: If09af103aae84a1e133e2d4fed8ab888d4b8f457
Reviewed-on: https://go-review.googlesource.com/c/go/+/308690
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Modified condition in the ASM implementation of indexbody to
determine if separator length crosses 16 bytes to BGT from BGE
to avoid incorrectly crossing a page.
Also fixed IndexString to invoke indexbodyp9 when on the POWER9
platform
Change-Id: I0602a797cc75287990eea1972e9e473744f6f5a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/356849
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Keith Randall <khr@golang.org>
This adds a few rules to PPC64 to eliminate some instructions:
- when an isel is used to generate a boolean value based on a
condition and followed by an xori to flip the result, it can
instead flip the operands in the isel and avoid the xori.
= when a neg follows a sub the operands to the sub can be
swapped and the neg avoided.
There are several opportunities in reflect.DeepEqual to omit
xori which improves some of its benchmarks by as much as
5%
Change-Id: I81bbc02c0f16995c65934b6f045867b731ab302b
Reviewed-on: https://go-review.googlesource.com/c/go/+/357509
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
[git-generate]
cd src/runtime
mv export_test.go export.go
GOROOT=$(dirname $(dirname $PWD)) rf '
add mheap.reclaimCredit \
// reclaimCredit is spare credit for extra pages swept. Since \
// the page reclaimer works in large chunks, it may reclaim \
// more than requested. Any spare pages released go to this \
// credit pool. \
reclaimCredit_ atomic.Uintptr
ex {
import "runtime/internal/atomic"
var t mheap
var v, w uintptr
var d uintptr
t.reclaimCredit -> t.reclaimCredit_.Load()
t.reclaimCredit = v -> t.reclaimCredit_.Store(v)
atomic.Loaduintptr(&t.reclaimCredit) -> t.reclaimCredit_.Load()
atomic.LoadAcquintptr(&t.reclaimCredit) -> t.reclaimCredit_.LoadAcquire()
atomic.Storeuintptr(&t.reclaimCredit, v) -> t.reclaimCredit_.Store(v)
atomic.StoreReluintptr(&t.reclaimCredit, v) -> t.reclaimCredit_.StoreRelease(v)
atomic.Casuintptr(&t.reclaimCredit, v, w) -> t.reclaimCredit_.CompareAndSwap(v, w)
atomic.Xchguintptr(&t.reclaimCredit, v) -> t.reclaimCredit_.Swap(v)
atomic.Xadduintptr(&t.reclaimCredit, d) -> t.reclaimCredit_.Add(d)
}
rm mheap.reclaimCredit
mv mheap.reclaimCredit_ mheap.reclaimCredit
'
mv export.go export_test.go
Change-Id: I2c567781a28f5d8c2275ff18f2cf605b82f22d09
Reviewed-on: https://go-review.googlesource.com/c/go/+/356712
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
[git-generate]
cd src/runtime
mv export_test.go export.go
GOROOT=$(dirname $(dirname $PWD)) rf '
add mheap.pagesInUse \
// Proportional sweep \
// \
// These parameters represent a linear function from gcController.heapLive \
// to page sweep count. The proportional sweep system works to \
// stay in the black by keeping the current page sweep count \
// above this line at the current gcController.heapLive. \
// \
// The line has slope sweepPagesPerByte and passes through a \
// basis point at (sweepHeapLiveBasis, pagesSweptBasis). At \
// any given time, the system is at (gcController.heapLive, \
// pagesSwept) in this space. \
// \
// It is important that the line pass through a point we \
// control rather than simply starting at a 0,0 origin \
// because that lets us adjust sweep pacing at any time while \
// accounting for current progress. If we could only adjust \
// the slope, it would create a discontinuity in debt if any \
// progress has already been made. \
pagesInUse_ atomic.Uint64 // pages of spans in stats mSpanInUse
ex {
import "runtime/internal/atomic"
var t mheap
var v, w uint64
var d int64
t.pagesInUse -> t.pagesInUse_.Load()
t.pagesInUse = v -> t.pagesInUse_.Store(v)
atomic.Load64(&t.pagesInUse) -> t.pagesInUse_.Load()
atomic.LoadAcq64(&t.pagesInUse) -> t.pagesInUse_.LoadAcquire()
atomic.Store64(&t.pagesInUse, v) -> t.pagesInUse_.Store(v)
atomic.StoreRel64(&t.pagesInUse, v) -> t.pagesInUse_.StoreRelease(v)
atomic.Cas64(&t.pagesInUse, v, w) -> t.pagesInUse_.CompareAndSwap(v, w)
atomic.Xchg64(&t.pagesInUse, v) -> t.pagesInUse_.Swap(v)
atomic.Xadd64(&t.pagesInUse, d) -> t.pagesInUse_.Add(d)
}
rm mheap.pagesInUse
mv mheap.pagesInUse_ mheap.pagesInUse
'
mv export.go export_test.go
Change-Id: I495d188683dba0778518563c46755b5ad43be298
Reviewed-on: https://go-review.googlesource.com/c/go/+/356549
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
In CL 327872, there's a fix for crawling of embeddable types directly
reached by the user, so all of its methods need to be re-exported. But
we missed the cased when an un-exported type may be reachable by
embedding in exported type. Example:
type t struct {}
func (t) M() {}
func F() interface{} { return struct{ t }{} }
We generate the wrapper for "struct{ t }".M, and when inlining call to
"struct{ t }".M makes "t.M" reachable.
It works well, and only be revealed in CL 327871, when we changed
methodWrapper to always call inline.InlineCalls, thus causes the crash
in #49016, which involve dot type in inlined function.
Fixes#49016
Change-Id: If174fa5575132da5cf60e4bd052f7011c4e76c5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/356254
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The "" stand-in for the current package needs to be substituted
in more places when importing, because of generics.
""..dict.conv4["".MyString]
when imported in main and then exported, this becomes
a..dict.conv4["".MyString]
and then the linker makes that into
a..dict.conv4[main.MyString]
Which isn't correct. We need to replace on import not just
function names, but also globals, which this CL does.
Change-Id: Ia04a23b5ffd60aeeaba72c807f69261105670f8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/356570
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
CL 350691 added Value.UnsafePointer and make Value.Pointer call it
internally. It has a downside that Value.Pointer can now eligible to be
inlined, thus making un-intentional side effect, like the test in
fixedbugs/issue15329.go becomes flaky.
This CL restore Value.Pointer original implementation, pre CL 350691,
with the deprecation TODO removed.
Fixes#49067
Change-Id: I735af182f8e729294333ca906ffc062f477cfc99
Reviewed-on: https://go-review.googlesource.com/c/go/+/356949
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Add support for replace directives in the go.work file. If there are
conflicting replaces in go.mod files, suggest that users add an
overriding replace in the go.work file.
Add HighestReplaced to MainModules so that it accounts for the
replacements in the go.work file.
(Reviewers: I'm not totally sure that HighestReplace is computed
correctly. Could you take a closer look at that?)
For #45713
Change-Id: I1d789219ca1dd065ba009ce5d38db9a1fc38ba83
Reviewed-on: https://go-review.googlesource.com/c/go/+/352812
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
errors.Is internally unwraps the error until the error matches the
target. Because of this, a user-authored Is method on an error type
need not call errors.Unwrap on itself or the target, because that would
make the unwrapping operation O(N^2). It is a subtle detail to remind
authors for resource efficiency reasons.
Change-Id: Ic1ba59a5bdbfe2c7cb51a2cba2537ab6de4a13ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/356789
Reviewed-by: Jean de Klerk <deklerk@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Jean de Klerk <deklerk@google.com>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Jean de Klerk <deklerk@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change adds support for the reg ABI to the Index and Count
functions for ppc64/ppc64le.
Most Index and Count benchmarks show improvement in performance on
POWER9 with this change. Similar numbers observed on POWER8 and POWER10.
name old time/op new time/op delta
Index/32 71.0ns ± 0% 67.9ns ± 0% -4.42% (p=0.001 n=7+6)
IndexEasy/10 17.5ns ± 0% 17.2ns ± 0% -1.30% (p=0.001 n=7+7)
name old time/op new time/op delta
Count/10 26.6ns ± 0% 25.0ns ± 1% -6.02% (p=0.001 n=7+7)
Count/32 78.6ns ± 0% 74.7ns ± 0% -4.97% (p=0.001 n=7+7)
Count/4K 5.03µs ± 0% 5.03µs ± 0% -0.07% (p=0.000 n=6+7)
CountEasy/10 26.9ns ± 0% 25.2ns ± 1% -6.31% (p=0.001 n=7+7)
CountSingle/32 11.8ns ± 0% 9.9ns ± 0% -15.70% (p=0.002 n=6+6)
Change-Id: Ibd146c04f8107291c55f9e6100b8264dfccc41ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/355509
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
uint64 is guaranteed by the compiler to be aligned on 64-bit archs.
By using uint64+uint32 instead of [3]uint32 we can make use of the
guaranteed alignment to avoid the run-time alignment check.
On linux/amd64:
name old time/op new time/op delta
WaitGroupUncontended-4 8.84ns ± 3% 7.62ns ± 4% -13.72% (p=0.000 n=17+18)
WaitGroupAddDone-4 66.8ns ± 3% 45.9ns ± 2% -31.31% (p=0.000 n=20+18)
WaitGroupAddDoneWork-4 79.2ns ± 1% 56.6ns ± 1% -28.54% (p=0.000 n=17+20)
WaitGroupWait-4 2.83ns ± 2% 2.58ns ± 2% -9.05% (p=0.000 n=18+20)
WaitGroupWaitWork-4 16.8ns ± 6% 16.5ns ± 6% ~ (p=0.072 n=20+18)
WaitGroupActuallyWait-4 263ns ± 2% 261ns ± 5% ~ (p=0.063 n=18+20)
Change-Id: I314340f2ed8a47d8b9c15f8a3b07e41f252f4831
Reviewed-on: https://go-review.googlesource.com/c/go/+/189837
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change also does some refactors around how
we prevent many (*F) methods from being called
inside (*F).Fuzz. Previously, there was a lot of
comment/code duplication, which was going to be
difficult to maintain and brittle. The refactor
lessens this duplication.
Previously, the methods Log, Logf, Failed, Name and
Skipped were the only (*common) methods that were
allowed to be called inside (*F).Fuzz. After this
change, Failed and Name are still allowed, but
Log, Logf, and Skipped are not (t.Log, t.Logf, or
t.Skipped should be used instead).
Fixes#48988
Change-Id: I4066247d551ea1908e8a2ca2889509fc68e3bb44
Reviewed-on: https://go-review.googlesource.com/c/go/+/356151
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This is an essentially clean port of CL 356489 from go/types to types2,
with minor adjustments due to the different AST packages and error
reporting.
Fixes#47990.
Change-Id: I52187872474bfc1fb49eb77905f22fc820b7295b
Reviewed-on: https://go-review.googlesource.com/c/go/+/356514
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL addresses the 2nd part of the issue below.
- For types2, now use the same error messages as the compiler in this case.
- Make the mechanism for reporting clarifying error messages handle the case
where we don't have additional position information.
- Provide context information (type assertion vs type switch).
Fixes#49005.
Change-Id: I4eeaf4f0c3f2f8735b63993778f58d713fef21ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/356512
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Findley <rfindley@google.com>
CL 322350 changed how to take address of assembly functions, using
abi.FuncPCABI0 intrinsic. But we forgot to update the code in
Value.UnsafePointer (was Value.Pointer) to reflect that change.
This CL fixes that bug, and also add a test to make sure the code
pointer is in sync.
Change-Id: I05ae7df31c706583a0f374d8af027066528f5ceb
Reviewed-on: https://go-review.googlesource.com/c/go/+/356809
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On riscv64, the JAL instruction is only capable of reaching +/-1MB. In the case where
a single function and its trampolines exceeds this size, it is possible that the JAL
is unable to reach the trampoline, which is laid down after the function text. In the
case of large functions, switch back to using a AUIPC+JALR pairs rather than using
trampolines.
Fixes#48791
Change-Id: I119cf3bc20ce4933a9b7ab41a8e514437c6addb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/356250
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Even after type-checking the RHS of a type declaration, we may not yet
be able to expand, if the RHS is itself an instance (see #49043).
We can instead rely on the mechanisms we have in place for delayed
expansion.
Fixes#49043
Change-Id: Ibffa4c1b1163c824b5c7e151aaac35f3e8c84ec7
Reviewed-on: https://go-review.googlesource.com/c/go/+/356533
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Rather than using Checker.later in newNamed, add a Checker.defTypes
field to track named types that have been created during type-checking,
and use this to expand named types as a final phase in type checking.
We have encountered several bugs related to infinite recursion while
expanding named types, because (I would argue) we have two conflicting
requirements in the type checker: ensuring that we eventually collapse
underlying chains, and yet allowing lazy substitution of the underlying
type in instances. The former is necessary for correctness, and to
ensure that we detect cycles during the type-checking pass. The latter
is necessary to allow infinitely expanding patterns of instances through
underlying or method definitions.
I believe this CL reconciles these conflicting requirements, by creating
a boundary between types that are encountered in the source during
type checking, and instances that are created by recursive evaluation.
At the end of the type checking pass, Checker.defTypes should contain
all possible origin types for instantiation. Once we compute the true
underlying for these origin types, any remaining instances that are
unresolved are guaranteed to have an origin with a valid underlying.
Therefore, we can return from the type-checking pass without calling
under() for these remaining instances.
Fixes#48703Fixes#48974
Change-Id: I1474f514e2ab71c1ad4c3704fe32bfba11d59394
Reviewed-on: https://go-review.googlesource.com/c/go/+/356490
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL avoids a useless follow-on error (that gets reported before the
actual error due to source position). This addresses the first part of
the issue below.
Thanks to @cuonglm for the suggestion for the fix.
For #49005.
Change-Id: Ifdd83072a05c32e115dc58a0233868a64f336f3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/356449
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The list of environments to support with wasm_exec.js was becoming too
large to maintain. With this change, wasm_exec.js expects that the
environment provides all necessary polyfills.
The standardized "globalThis" is used for accessing the environment.
wasm_exec.js now only provides stub fallbacks for globalThis.fs and
globalThis.process.
All code specific to Node.js is now in a separate file.
Change-Id: I076febbd94d4d7845260faad972f450f74a7b983
Reviewed-on: https://go-review.googlesource.com/c/go/+/347353
Trust: Richard Musiol <neelance@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
SetImplicit() has an explicit meaning and really shouldn't be used in
this way - its use is left over from early prototype of the dictionary
code. Convert from using SetImplicit to just using a map during
traversal.
Change-Id: I3d257c101a859f000e159d7ced307d1b7cf990d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/356310
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Both netpollblock and netpollunblock read gpp using a non-atomic load.
When consuming a ready event, netpollblock clears gpp using a non-atomic
store, thus skipping a barrier.
Thus on systems with weak memory ordering, a sequence like so this is
possible:
T1 T2
1. netpollblock: read gpp -> pdReady
2. netpollblock: store gpp -> 0
3. netpollunblock: read gpp -> pdReady
4. netpollunblock: return
i.e., without a happens-before edge between (2) and (3), netpollunblock
may read the stale value of gpp.
Switch these access to use atomic loads and stores in order to create
these edges.
For ease of future maintainance, I've simply changed rg and wg to always
be accessed atomically, though I don't believe pollOpen or pollClose
require atomics today.
Fixes#48925
Change-Id: I903ea667eea320277610b4f969129935731520c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/355952
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
The go command no longer reports an error when invoked in a repository
nested inside another. This check is still used by 'go get' in GOPATH
mode when locating a repository, but it's not needed when preparing
the build stamp.
Fixes#49004
Change-Id: I4ed4dcc04174d2d42da8651d47e52ab1d7d66e35
Reviewed-on: https://go-review.googlesource.com/c/go/+/356309
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This pulls in some code and tests from CL 353355.
This change makes some refactors for when we read
to and write from memory during minimization.
That fixes a bug when minimizing interesting inputs.
Now, if an error occurs while minimizing an interesting
input, that value will continue to be minimized as a
crash, and returned to the user.
This change also allows minimization of a crash that
occurred during the warmup phase. We don't want to
minimize failures in the seed corpus, but if an entry
in the cache causes a new failure, then there's no
compelling reason why we shouldn't try to minimize it.
Fixes#48731
Change-Id: I7262cecd8ea7ae6fdf932f3a36db55fb062a1f2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/355691
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This CL fixes the subtle issue that Elem can promote a
not-in-heap pointer, which could be any bit pattern, into an
unsafe.Pointer, which the garbage collector can see. If that
resulting value is bad, it can crash the GC.
Make sure that we don't introduce bad pointers that way. We can
make Elem() panic, because any such bad pointers are in the Go heap,
and not-in-heap pointers are not allowed to point into the Go heap.
Update #48399
Change-Id: Ieaf35a611b16b4dfb5e907e229ed4a2aed30e18c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350153
Trust: Keith Randall <khr@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add a simple mechanism to provide formatted descriptions for
delayed actions. The comment strings are printed when tracing
is enabled and the delayed action is executed. This results
in more easily decipherable tracing output.
Requires debug mode in order to minimize the overhead during normal
execution. Use the mechanism in a few places to show typical use.
Also cleaned up a few unrelated comments.
Change-Id: Ic273c380c3963341500396ec62b694d143c25de2
Reviewed-on: https://go-review.googlesource.com/c/go/+/355871
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Modify the phase for creating needed function/method instantiations and
modifying functions to use those instantiations, so that the phase is
self-contained and can be called again after inlining. This is to deal
with the issue that inlining may reveal new fully-instantiated types
whose methods must be instantiated.
With this change, we have an extra phase for instantiation after
inlining, to take care of the new fully-instantiated types that have
shown up during inlining. We call inline.InlineCalls() for any new
instantiated functions that are created.
Change-Id: I4ddf0b1907e5f1f7d45891db7876455a99381133
Reviewed-on: https://go-review.googlesource.com/c/go/+/352870
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Fixes a test failure in cmd/go TestScript/mod_outside.
make.bash (cmd/dist) builds everything with -gcflags=all= -ldflags=all=
by default. If those no-op flags aren't used, all GOROOT binaries
appear stale.
It's likely safe to omit those flags in cmd/dist if they're
empty. Checking out a new commit in GOROOT would always cause
staleness since the VCS info would change.
For #37475
Change-Id: Ic9aa0f3b7318e05fbb2f7d2c008ad07a4c61952f
Reviewed-on: https://go-review.googlesource.com/c/go/+/356014
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Test functions with type parameters cannot be invoked without type
arguments, so cmd/go would previously fail with a type-checking error in
the test harness.
Avoid this by producing an error explaining that test functions cannot
have type parameters.
Fixes#48953
Change-Id: I4e39c9b7a06c964fad5f12d74d262aa090c25d79
Reviewed-on: https://go-review.googlesource.com/c/go/+/355889
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When the go command builds a binary, it will now stamp the current
revision from the local Git or Mercurial repository, and it will also
stamp whether there are uncommitted edited or untracked files. Only
Git and Mercurial are supported for now.
If no repository is found containing the current working directory
(where the go command was started), or if either the main package
directory or the containing module's root directory is outside the
repository, no VCS information will be stamped. If the VCS tool is
missing or returns an error, that error is reported on the main
package (hinting that -buildvcs may be disabled).
This change introduces the -buildvcs flag, which is enabled by
default. When disabled, VCS information won't be stamped when it would
be otherwise.
Stamped information may be read using 'go version -m file' or
debug.ReadBuildInfo.
For #37475
Change-Id: I4e7d3159e1c270d85869ad99f10502e546e7582d
Reviewed-on: https://go-review.googlesource.com/c/go/+/353930
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
These functions provide access to module information stamped into Go
binaries. In the future, they'll provide access to other information
(like VCS info).
These functions are added in a new package instead of runtime/debug
since they use binary parsing packages like debug/elf, which would
make runtime/debug an unacceptably heavy dependency. The types in
runtime/debug are still used; debug/buildinfo uses them via type
aliases.
This information is already available for the running binary through
debug.ReadBuildInfo and for other binaries with 'go version -m', but
until now, there hasn't been a way to get it for other binaries
without installing cmd/go.
This change copies most of the code in cmd/go/internal/version. A
later CL will migrate 'go version -m' to use this package.
For #37475Fixes#39301
Change-Id: I0fbe0896e04f12ef81c6d79fb61b20daede86159
Reviewed-on: https://go-review.googlesource.com/c/go/+/353887
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Previously, modload.PackageBuildInfo returned a string containing
information about modules used to build an executable. This string is
embedded in the binary and can be read with debug.ReadBuildInfo or
'go version -m'.
With this change, debug.BuildInfo now has a MarshalText method that
returns a string in the same format as modload.PackageBuildInfo.
Package.load now calls Package.setBuildInfo, which constructs a
debug.BuildInfo, formats it with MarshalText, then sets
Package.Internal.BuildInfo. This is equivalent to what
modload.PackageBuildInfo did.
modload.PackageBuildInfo is deleted, since it's no longer used.
For #37475
Change-Id: I5875a98cb64737637fec2a450ab2ffa7f1805707
Reviewed-on: https://go-review.googlesource.com/c/go/+/353886
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
These tests are inherently nondeterministic: They exercise a racy
code path for up to one million iterations, and require that an
error occur at least once.
TestWaitGroupMisuse2 in particular is an ongoing source of trybot
flakiness.
Fixes#38163.
Change-Id: Ibbbda2c998c915333487ad262d3df6829de01c2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/340249
Trust: Damien Neil <dneil@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
The algorithm for detecting invalid recursive types that
expand indefinitely suffered from the exact problem is was
intended to detect: if the indefinite expansion is happening
through type parameters, the algorithm ended up in an infinite
sequence of instantiations. (This is only a problem for generic
types).
Changed the algorithm to always only consider the "original"
uninstantiated types. This avoids the problem but it will also
not detect some invalid recursive generic types anymore. That
requires a more sophisticated type flow analysis.
Opened #48962 to track.
Addressed with help from @findleyr.
For #48951.
Change-Id: Ie29cea8f810dae55153dbb1b17c9390cd823c2d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/355732
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Use fcntl(oldfd, F_DUP2FD_CLOEXEC, newfd) to duplicate the file
descriptor and mark is as close-on-exec instead of dup2 & fcntl.
FreeBSD implements dup3 like this in libc.
Change-Id: I36e37bc61c2e31561adb49001f287764125a74de
Reviewed-on: https://go-review.googlesource.com/c/go/+/355571
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before the 1.12 release the use of linkname did not prevent a compiler
error for an empty function body (see #23311). Add some build tags so
that cmd/link will build with earlier releases.
It's true that we currently require Go 1.16 as the bootstrap compiler (#44505).
But for this simple case keep things working with older compilers for now.
Change-Id: I67fe021406096c64c01d6e2c9adbcc4388988a6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/355690
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
On riscv5, apparently extra wrappers (trampolines) are created for some
functions with the suffix "-tramp". Modify inst_test.go to not match
these "-tramp" wrappers.
Change-Id: I754c724f03555c30f8e1b5cfc08152555bbbcf17
Reviewed-on: https://go-review.googlesource.com/c/go/+/355650
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
This reduces the number of branches to bounds check non-empty slices
from 5 to 3. It does also increase the number of branches to handle
empty slices from 1 to 3; but for non-panicking calls, they should all
be predictable.
Updates #48798.
Change-Id: I3ffa66857096486f4dee417e1a66eb8fdf7a3777
Reviewed-on: https://go-review.googlesource.com/c/go/+/355490
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change allows httputil.ReverseProxy to detect SSE (server-sent events)
content when the response's Content-Type header includes MIME parameters,
such as "text/event-stream;charset=utf-8".
Prior to this change the value of the Content-Type header was compared
directly to the literal "text/event-stream". This caused a false-negative
which failed to set the FlushInterval correctly when MIME parameters were
present.
Change-Id: If8bb43efb78787b6519d7fe7599ca018a0da0023
GitHub-Last-Rev: 224518c5eb
GitHub-Pull-Request: golang/go#48427
Reviewed-on: https://go-review.googlesource.com/c/go/+/350509
Trust: Alexander Rakoczy <alex@golang.org>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
This test seems only to be testing that Dial does not time out
immediately as a result of integer overflow; the precise time taken to
connect is immaterial. Replace naked loop with sub-tests.
Fixes#43069.
Change-Id: Ib5e38a1d8cd191b74c2bc7c26bef57b180e16f68
Reviewed-on: https://go-review.googlesource.com/c/go/+/355390
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
If sep does not appear in s, we return nil here
rather than the empty string. Presumably the docs
were copied from the strings package implementation
and brought that along.
Change-Id: I3706c94fe04abd9e2a2c8840f7cc6116386965c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/354969
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Corrections were only made to comments and can be reproduced with the
following sed.
sed -i 's/communciation/communication/g' src/internal/fuzz/sys_windows.go
sed -i 's/communciation/communication/g' src/internal/fuzz/sys_posix.go
sed -i 's/substitued/substituted/g' src/cmd/compile/internal/noder/irgen.go
Change-Id: I435aee2fdb41e73b694e6233d52742559d32cf7e
GitHub-Last-Rev: a471e3d123
GitHub-Pull-Request: golang/go#48932
Reviewed-on: https://go-review.googlesource.com/c/go/+/355494
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Go back to allowing spaces in types.(*Type).LinkSring().
Delve folks prefer that there are spaces in type names, if needed, since
DWARF expects type names to be "a string representing the name as it
appears in the source program". At this point, it doesn't necessarily
seem worth having a separate function that removes spaces, only for use
when printing the type names in a function/method instantiation.
Most names of function/method instantiations will still not have spaces,
since they most type args are named or builtin types. I confirmed that
we are back to the original definition of LinkString(), except for some
comment changes.
Change-Id: Iab7143f659ddea4f099c6230cb134edf8aaef868
Reviewed-on: https://go-review.googlesource.com/c/go/+/355354
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Changing type parameter names is not a breaking API change, so we should
not include these names in the output of cmd/api. Instead print a
placeholder '$<index>' wherever type parameters are referenced.
This is valid for cmd/api as there is at most one type parameter list in
scope for any exported declaration. If we ever support method type
parameters, we'll need to revisit this syntax.
Change-Id: I7e677b1dab6ffeb0b79afefdb8d2580bef93891c
Reviewed-on: https://go-review.googlesource.com/c/go/+/355389
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This should be a no-op, but if the sharded builders are for some
reason distributing stale snapshots — or testing them with mismatched
environments — this should catch them out at a relatively low cost
(#24300 notwithstanding).
Given the frequently at which (*tester).runPending already checks for
staleness, we do not expect the impact of this extra check to be
significant for most builders.
For #33598
Updates #24300
Change-Id: I197d6a69c72e2eec9e4563b459206de76c89e8a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/223755
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Add a test for a generic sort function, operating on several different
pointer types (across two packages), so they should all share the same
shape-based instantiation. Actually check that only one instantiation of
Sort is created using 'go tool nm', and also check that the output is
correct.
In order to do the test on the executable using 'go nm', added this as a
'go test' in cmd/compile/internal/test.
Added the genembed.go test that I meant to include with a previous CL.
Change-Id: I9962913c2f1809484c2b1dfef3b07e4c8770731c
Reviewed-on: https://go-review.googlesource.com/c/go/+/354696
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
T.Run uses a map[string]int64 to keep track of subtest names that may
be returned through T.Name. T.Name can't return duplicate names for
subtests started with T.Run.
If a fuzz target calls T.Run, this map takes a large amount of memory,
since there are a very large number of subtests that would
otherwise have duplicate names, and the map stores one entry per subtest.
The unique suffixes are not useful (and may be confusing) since the
full sequence of tests cannot be re-run deterministically.
This change deletes all entries in the map before each call to the
function being fuzzed. There is a slight change in the contract of
T.Name while fuzzing.
This change was discussed in CL 351452.
Fixes#44517
Change-Id: I3093a2e5568099ce54aca1006fac84a6fd2c3ddf
Reviewed-on: https://go-review.googlesource.com/c/go/+/354430
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
In the case in (*TSubster).Type() that we were running into an
incomplete underlying type (TFORW), we should just be immediately
returning the type returned by ts.SubstForwFunc(forw), since that call
returns a proper type node, and has set up any remaining work that has
to be done when we get done with the current top-level type definition.
(For import, that function is doInst, which does an Instantiate of the
new substituted type, with the delayed part via deferredInstStack.) We
should not continue doing the later parts of (*TSubster).Type(), since
the underlying type may not yet have its methods filled in, etc.
Also, in Instantiate(), we need to put the desired new type on
deferredInstStack, even if the base type node already exists, if the
type node is in TFORW state. This is now exactly the case when
Instantiate is called from (*TSubster).Type via doInst, since
(*TSubster).Type has already called NewIncompleteNamedType().
Fixes#48716Fixes#48889
Change-Id: Icd6be5721c4ac75bf8869b8bbdeca50069d632ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/355250
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This change resolves a TODO regarding a couple uncertain APIs for
types.TypeParam. In the case of TypeParam._Index, we've decided it is
worth exporting. In the case of TypeParam._SetId, we've decided it is
unnecessary.
This aligns go/types with types2 (a doc comment in types2 is also
updated).
Updates #47916
Change-Id: I705e8b3437d014775c473e2f8be6f32b1540bb0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354370
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In module-aware mode, 'go get' no longer builds or installs packages.
- 'go generate' explains build commands do not run generate
commands. 'go get' is no longer a build command, so this CL removes
mention of it.
- 'go get' will continue to accept build flags, but they're
ignored. The documentation no longer mentions them, though it does
mention -x for printing VCS commands.
For #43684
Change-Id: I1eea7241eecf72ba9f98238b729d91cc77ec7665
Reviewed-on: https://go-review.googlesource.com/c/go/+/355209
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change fixes some issues with -run, and
the subsequent command line output when running
in verbose mode. It replaces CorpusEntry.Name
with CorpusEntry.Path, and refactors the code
accordingly.
This change also adds a lot of additional tests
which check explicit command line output when
fuzz targets are run without fuzzing. This will
be important to avoid regressions.
Updates #48149
Change-Id: If34b1f51db646317b7b51c3c38ae53231d01f568
Reviewed-on: https://go-review.googlesource.com/c/go/+/354632
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Insert machine NOPs when a prefixed instruction crosses a 64B boundary.
ISA 3.1 prohibits prefixed instructions being placed across them. Such
instructions generate SIGILL if executed.
Likewise, adjust the function alignment to guarantee such instructions
can never cross one. And, don't pad the PC based on alignment. The
linker can fit these more optimally.
Likewise, include the function alignment when printing function debug
information. This is needed to verify function alignment happens.
Updates #44549
Change-Id: I434fb0ee4e984ca00dc4566f7569c3bcdf93f910
Reviewed-on: https://go-review.googlesource.com/c/go/+/347050
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
This is a port of CL 353139 to go/types, adjusted for error reporting
and for the different representation of field lists in go/ast. A TODO is
added to verify if types2 produces redundant error messages for type
parameters sharing a bound.
For #48424
Change-Id: I3549942be0328de616d1d87d0ba621311fc53576
Reviewed-on: https://go-review.googlesource.com/c/go/+/354989
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 353133 from cmd/compile/internal/syntax, with
significant adjustments for the mechanics of go/parser.
Some additional cleanup is made along the way: parseParameterList can
call parseParamDecl without indirection, and the tparams argument is
redundant with the closing token. Also, the error that "all type
parameters must be named" is positioned on the first unnamed type
parameter.
Error recovery in go/parser is notably worse here than the compiler
parser, so the test data had to be adjusted to synchronize positions.
Fixing this error recovery will have to wait for a later CL.
As with the compiler changes, these changes are guarded behind a flag so
that they may be easily removed if #48424 is not accepted.
For #48424
Change-Id: If87925d246f36aaab11a95442f75f659462d4286
Reviewed-on: https://go-review.googlesource.com/c/go/+/354870
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The docs say:
If the input is at EOF, Decode returns io.EOF and does not modify e.
However, the added test fails:
--- FAIL: TestDecodePartial (0.00s)
encoder_test.go:1263: 31/81: expected io.ErrUnexpectedEOF: EOF
encoder_test.go:1263: 51/81: expected io.ErrUnexpectedEOF: EOF
In particular, the decoder would return io.EOF after reading a valid
message for a type specification, and then hit EOF before reading a data
item message.
Fix that by only allowing a Decode call to return io.EOF if the reader
hits EOF immediately, without successfully reading any message.
Otherwise, hitting EOF is an ErrUnexpectedEOF, like in other cases.
Also fix a net/rpc test that, coincidentally, expected an io.EOF
as an error when feeding bad non-zero data to a gob decoder.
An io.ErrUnexpectedEOF is clearly better in that scenario.
Fixes#48905.
Change-Id: Ied6a0d8ac8377f89646319a18c0380c4f2b09b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/354972
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This changes debug/gosym so it can deal with instantiated
types/funcs/methods. I also added tests for instantiated names. My
assumption is that the concatenation of PackageName, ReceiverName, and
BaseName in order should cover the entire symbol name, so either the
ReceiverName or the BaseName should include any bracketed information
(either the instantiation of the receiver of a method or the
instantiation of function).
This can provide a model for how to parse instantiated functions and
method names.
Fixes#48032
Change-Id: I476781de2d6fc096efbb4be85c197d6f1cafac21
Reviewed-on: https://go-review.googlesource.com/c/go/+/354689
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This reverts CL 351851, which itself reverted CL 348991.
The problem with the original CL, as far as I can tell, was due to a
bug in the Go project's builder infrastructure (#33598) and not the
change itself. Once the build infrastructure is fixed, this change
can be resubmitted.
Fixes#48319
Updates #33598
Change-Id: I0fdbcc241eb2bdeb350944aad58bf58774fb591e
Reviewed-on: https://go-review.googlesource.com/c/go/+/353352
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
It turns out there is no real TODO here - things are working fine. If we
are generating a wrapper for a method on a generic type that is actually
the method on embedded type, then we should just just generate the
normal embedded wrapper, which calls the wrapper for the real receiver
type on that method. There is no need to do the generic path where we
add in the dictionary argument. So, just updated that TODO comment with
this explanation.
Added a new test case embedded.go, which specifically tests various
situations involving converting to empty and non-empty interfaces.
issue44688.go already tests a bunch of these situations as well.
Also made some other cleanups in reflect.go:
- The shape test (that I had added) at the top of imethods is useless
(never true), since it is always an interface type, so removed it.
- Added usual helper function deref() to make code clearer in several
places.
- The shape test in methodWrapper() doesn't have to check HasShape() on
each targ - it can just check HasShape() on the whole receiver.
- The comment about disabling the tail call optimization for RegABI is
no longer true.
- Simplified code in several places by using the value of existing
variable 'methodrcvr'.
Change-Id: I8b1a5dc518dad37585824a1f73ceebb7627a9f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/355129
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Now that x/tools/go/types/objectpath has been updates to support type
parameters, I ran the following commands to update x/tools inside the
cmd module:
go get -d golang.org/x/tools@18fa840216958359dc43466f3e70d96add38edbb # main branch
go mod tidy
go mod vendor
Updates #48588
Change-Id: Ibebc1ac2f721d6e2eb1a4f6c610918770d4879ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/355012
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Fix "MOVW CRx, Rx" and "MOVFL Rx, constant", The FXM field was not
encoded correctly.
Generate mtocrf instead of mtcrf when a CRx argument is used. This
form is much faster.
Simplify several conditional statements which test if the register
argument is REG_CR or one of REG_CRx if the tested argument is known
to be matched as C_CREG. Likewise, a4 is (the From3 arg) is always
TYPE_NONE in the existing optab entries for type_ 69.
Change-Id: I3a4749b1cbfdfab6a2616586ae59e932e01dae50
Reviewed-on: https://go-review.googlesource.com/c/go/+/352789
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
With multiple text sections, there may be holes (non-Go code) in
the PC range of Go code and covered by the functab. Previously, we
use a linear search with actual PCs to find the functab entry. We
need to use special entries to mark holes, so a PC in the hole can
be distinguished from the previous function.
Now, with the previous CL we find if the PC is in between of the
sections upfront in textOff. There is no need to mark holes in the
functab.
Change-Id: I22ff27279422bfc855c2ca35ba0fdfb63234c113
Reviewed-on: https://go-review.googlesource.com/c/go/+/354874
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
In findfunc, we first us the relative PC to find the function's
index in functab. When we split text sections, as the external
linker may shift the sections, and the PC may not match the
(virtual) PC we used to build the functab. So the index may be
inaccurate, and we need to do a (forward or backward) linear
search to find the actual entry.
Instead of using the PC directly, we can first compute the
(pre-external-link virtual) relative PC and use that to find the
index in functab. This way, the index will be accurate and we will
not need to do the special backward linear search.
Change-Id: I8ab11c66b7a5a3d79aae00198b98780e10db27b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/354873
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
What should it mean to run a regexp match on invalid UTF-8 bytes?
The coherent behavior options are:
1. Invalid UTF-8 does not match any character classes,
nor a U+FFFD literal (nor \x{fffd}).
2. Each byte of invalid UTF-8 is treated identically to a U+FFFD in the input,
as a utf8.DecodeRune loop might.
RE2 uses Rule 1.
Because it works byte at a time, it can also provide \C to match any
single byte of input, which matches invalid UTF-8 as well.
This provides the nice property that a match for a regexp without \C
is guaranteed to be valid UTF-8.
Unfortunately, today Go has an incoherent mix of these two, although
mostly Rule 2. This is a deviation from RE2, and it gives up the nice
property, but we probably can't correct that at this point.
In particular .* already matches entire inputs today, valid UTF-8 or
not, and I doubt we can break that.
This CL adopts Rule 2 officially, fixing the few places that deviate from it.
Fixes#48749.
Change-Id: I96402527c5dfb1146212f568ffa09dde91d71244
Reviewed-on: https://go-review.googlesource.com/c/go/+/354569
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The code generated when storing eight bytes loaded from memory in big
endian introduced two successive byte swaps that did not actually
modified the data.
The new rules match this specific pattern both for amd64 and for arm64,
eliminating the double swap.
Fixes#41684
Change-Id: Icb6dc20b68e4393cef4fe6a07b33aba0d18c3ff3
Reviewed-on: https://go-review.googlesource.com/c/go/+/320073
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
The illumos builder is using a Go 1.18 prerelease toolchain for
bootstrapping, which doesn't have ast.IndexListExpr. But we can
instead check for the "compiler_bootstrap" build tag that's already
used for distinguishing binaries built for toolchain1.
Fixes#48863.
Change-Id: I87b672322eee22a60ab8d0bb3be5f76cffc97545
Reviewed-on: https://go-review.googlesource.com/c/go/+/354695
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A stack object record may refer to the object's type's GC mask or
GC program (for very large types). For the latter, currently the GC
program symbol is named "type..gcprog.XXX" which is then laid out
along with type symbols at link time. When relro is used, the type
symbols end up in a different section.
As we now use relative addressing for stack object records to refer
to GC masks or GC programs, it is important that it is laid out in
the rodata section (not rodata.rel.ro). Move GC program symbols to
be along with GC masks, as they are similar and accessed the same
way. They don't have relocations so they don't need to be laid to a
relro section.
This fixes flaky failures like
https://build.golang.org/log/3bdbaaf786ec831b4393a64a959d2130edb5e050
Change-Id: I97aeac1234869da5b0f3a73a3010513d6a3156c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/354793
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This is a port of CL 354643 from go/types to types2 with adjustments:
- use of syntax rather than go/ast package as needed
- adjustments due to the different code for type parameter declarations
- rename of Checker.rparamMap to Checker.recvTParamMap, which seems clearer
Change-Id: I5311a0c05a13c6b87ea1422b250b90c3d05c5dce
Reviewed-on: https://go-review.googlesource.com/c/go/+/354693
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For this unusual case, where a constraint specifies exactly one type, we
can have a COMPLIT expression with a type that is/has typeparams.
Therefore, we add code to delay transformCompLit for generic functions.
We also need to break out transformAddr (which corresponds to tcAddr),
and added code for delaying it as well. Also, we now need to export
generic functions containing untransformed OCOMPLIT and OKEY nodes, so
added support for that in iexport.go/iimport.go. Untransformed OKEY
nodes include an ir.Ident/ONONAME which we can now export.
Had to adjust some code/asserts in transformCompLit(), since we may now
be transforming an OCOMPLIT from an imported generic function (i.e. from
a non-local package).
Fixes#48537
Change-Id: I09e1b3bd08b4e013c0b098b8a25d082efa1fef51
Reviewed-on: https://go-review.googlesource.com/c/go/+/354354
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
ParseDuration should handle minimum int64 (-1<<63) nanosecond
since type Duration is alias of int64
name old time/op new time/op delta
ParseDuration 91.4ns ± 0% 86.4ns ± 1% -5.49% (p=0.000 n=9+8)
Fixes: #48629
Change-Id: I81b7035b25cefb4c1e5b7801c20f2d335e29358a
Reviewed-on: https://go-review.googlesource.com/c/go/+/352269
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Receiver type parameters are the only type expressions allowed to be
blank. Previously this was handled by substitution of synthetic
non-blank names in the receiver type expression, but that introduced
problems related to AST mangling: the scope had extra elements,
Object.Name() was inaccurate, and synthetic nodes were recorded in
types.Info.
Fix this instead by recording a map of *ast.Ident->*TypeParam on the
Checker, which is read in Checker.ident to resolve blank identifiers
denoting receiver type parameters.
Change-Id: I6a7a86b823409f54778c0f141e8bd269a2cc85d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/354643
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
PNG images can be paletted, where each pixel value (a uint8) indexes a
slice of colors. In terms of wire format, the PLTE chunk explicitly
contains the palette length. However, in practice, some arguably
malformed images contain pixel values greater than or equal to the
explicit PLTE length.
Go's image/png decoder accomodates such images by lengthening the
decoded image's palette if the implicit maximum is larger than the
explicit maximum. This was already done, prior to this commit, by the
"if len(paletted.Palette) <= int(idx)" lines in decoder.readImagePass.
Separately, PNG images can also be interlaced, where the final image is
the result of merging multiple partial images, also called passes. Prior
to this commit, we applied the palette lengthening to the pass images
but not the final image. This commit fixes that.
Fixes#48612
Change-Id: I77606538cc9a504fbd726071756ebcd10c9da73f
Reviewed-on: https://go-review.googlesource.com/c/go/+/354709
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
When we have multiple text sections, we need to mark holes between
the sections in the functab. A hole is marked with an entry with
the end PC of the previous section. As we now use offsets instead
of (relocated) PCs, the end offset of a section may be the same of
the start of the next one. Distinguish it by using the end address
-1.
For #48837.
Change-Id: I121aac53b32a869378632cf151cb1b6f98ad3089
Reviewed-on: https://go-review.googlesource.com/c/go/+/354636
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
As the func table contains the end marker of the text section, we
sometimes need to get that address from an offset. Currently
textAddr doesn't handle that address, as it is not within any
text section. Instead of letting the callers not call textAddr
with the end offset, just handle it more elegantly in textAddr.
For #48837.
Change-Id: I6e97e455f6cb66e9680a7aac6152ba6f4cda2e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/354635
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Change to using types.(*Type).LinkString() for printing names of types
in function/method instantiations. (e.g. f[int] or Value[p.Myint].Set())
LinkString already generates a unique string description for t, using
package paths, except that it uses "" for the local package path. The ""
will be expanded in the linker, so the names in the executable will have
full package paths everywhere and de-duplication of function/method
instantiations will work properly. We do need to add an explicit
substitution of "" in ReadImports() for function/method names. We
previously were using NameString(), which doesn't use full package
paths, so is not fully unique.
We had also discussed that we would prefer to minimize spaces in
function/method instantiation names. So, I changed LinkString() to
eliminate all unneeded spaces. In the one case where we need a
separator, which is between field names and types, we use a "#" instead
of a space.
This change has the advantage of eliminating spaces in some existing
non-generic function name - mainly .type.eq functions for anonymous
types (e.g. "type..eq.struct { runtime.gList; runtime.n int32 }") shows
up in a hello-world executable (as Cherry pointed out).
We do not need an analogous function for types2 right now, since we
create all instantiations using types1 types. In the one case where we
need to create an instantiation during types2-to-types1 translation, we
convert the types to types1 first (see (*irgen).instTypeName2).
Change-Id: Iac4748fa0d0d6f89af59bd51076266986daee945
Reviewed-on: https://go-review.googlesource.com/c/go/+/353609
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previously, when fuzzing for a period of time, the
command line output would look something like this:
fuzz: minimizing 34995-byte crash input...
fuzz: elapsed: 3s, execs: 13821 (4604/sec), new interesting: 0 (total: 1)
fuzz: elapsed: 6s, execs: 13821 (2303/sec), new interesting: 0 (total: 1)
fuzz: elapsed: 9s, execs: 13821 (1535/sec), new interesting: 0 (total: 1)
--- FAIL: FuzzFoo (9.05s)
This is the same output it has while fuzzing, so if
minimization runs for a long time (default allows 1
minute), then it looks like minimization is hanging.
It's also confusing that the execs/sec would continually
decrease.
Now, when minimization is running, the command line
output will look something like this:
fuzz: minimizing 34995-byte crash input...
fuzz: elapsed: 3s, minimizing
fuzz: elapsed: 6s, minimizing
fuzz: elapsed: 9s, minimizing
fuzz: elapsed: 9s, minimizing
--- FAIL: FuzzFoo (9.05s)
The final "fuzz: elapsed: 6s, minimizing" could be
printed twice because we always print one final log
to the command line before we exit.
Updates #48820
Change-Id: Ie5b9fde48b8d4e36e13a81ae50a6d69bf4d0dbe3
Reviewed-on: https://go-review.googlesource.com/c/go/+/354371
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The existing implementation lacks consideration of running test on a
machine which has ipv6 address but no ipv4 address. Use net.IP.IsLoopback
and net.IP.IsUnspecified instead of hardcoded addresses.
Fixes: #48575
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
Change-Id: I9c3c26d2ba13c7a24065751b59a1e002098ed654
GitHub-Last-Rev: fc45adbf7b
GitHub-Pull-Request: golang/go#48850
Reviewed-on: https://go-review.googlesource.com/c/go/+/354609
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
On Wasm, wasm_exec.js puts command line arguments at the beginning
of the linear memory (following the "zero page"). Currently there
is no limit for this, and a very long command line can overwrite
the program's data section. Prevent this by limiting the command
line to 4096 bytes, and in the linker ensuring the data section
starts at a high enough address (8192).
(Arguably our address assignment on Wasm is a bit confusing. This
is the minimum fix I can come up with.)
Thanks to Ben Lubar for reporting this issue.
Fixes#48797
Fixes CVE-2021-38297
Change-Id: I0f50fbb2a5b6d0d047e3c134a88988d9133e4ab3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1205933
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/354571
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The old way of implementing it, float32(float64(x)), involves 2 roundings
which can cause accuracy errors in some strange cases. Implement a runtime
version of [u]int64tofloat32 which only does one rounding.
Fixes#48807
Change-Id: Ie580be480bee4f3a479e58ef8dce23032f231704
Reviewed-on: https://go-review.googlesource.com/c/go/+/354429
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is port of CL 354049 for types2 to go/type.
The change is identical, but for some tweaks to the error message/position
in tests, since when go/types reports the exact operation "cannot convert"
instead of the general "invalid operation" like types2.
Updates #48784
Change-Id: I3e99f2721501d23187fd0a8970eb1de28e0c41d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/354050
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In case of an invalid untyped nil conversion, the compiler's original
type checker leaves it to the caller to report a suitable error message.
But types2 does not, it always reports the invalid conversion.
CL 328053 made types2 report a better error message, and match the
original compiler behavior. But it ignored the case of untyped nil.
This CL adds that missing case, by checking whether the two operands can
be mixed when untyped nil is present.
Fixes#48784
Change-Id: Idc7d86eb0245aa18ca428e278f4416d6b3679058
Reviewed-on: https://go-review.googlesource.com/c/go/+/354049
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a port of CL 354432 from types2 to go/types
with minor adjustments:
- an error message has a different position
- the constraint literals are wrapped in interfaces
because the interface-free notation has not been
ported yet
Change-Id: I167094b57b39027566f2b7ce3aa97a071bae4da5
Reviewed-on: https://go-review.googlesource.com/c/go/+/354489
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For now, the underlying types of the the argument types' constraints
must be a single type that is a slice (the source operand may also
be a string).
Change-Id: I9e705e3349c9242f126b9c3e0af65e9ffb25fe6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354432
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The (*http.Cookie).String method used by SetCookie will silently discard
or sanitize any fields it deems invalid, making it difficult to tell
whether a cookie will be sent as expected.
This change introduces a new (*http.Cookie).Valid method which may be
used to check if any cookie fields will be discarded or sanitized prior
to calling (*http.Cookie).String.
Fixes#46370
Change-Id: I2db80078de190d267a9c675a9717c8be8acc8704
Reviewed-on: https://go-review.googlesource.com/c/go/+/338590
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
I've noticed for a while that there is some duplicated and some useful
information being put out in -W=3 mode after the comment marker (besides
the position).
dumpNodeHeader puts out a comment marker '#' before putting out the
position of a node (which is for almost all nodes). Therefore, we shouldn't
print out anything on the same line after calling dumpNodeHeader().
But we happen to be putting out a duplicate type of the node in some
cases. Also, we put out the Sym() associate with the node after
dumpNodeHeader(). So, I got rid of the duplicate type print-out, and moved
the print-out of n.Sym() to be inside dumpNodeHeader() before the
position information. Also, moved the tc flag to be right after the type
information, which seems like it makes more sense.
Change-Id: I05210fbf9f3b2d8e3b73fc0ceab26a7bce5dc104
Reviewed-on: https://go-review.googlesource.com/c/go/+/354355
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TestTicker is sensitive to overloaded or slow systems, where a 20ms
ticker running for 10 ticks has a total run time out of the range
[110ms, 290ms]. To counter this flakiness, it tries five times to
get a successful result. This is insufficient--an overloaded test
machine can introduce more than 100ms of delay across the test.
Reduce the five attempts to two, but use a 1s ticker for 8 ticks
in the second attempt.
Updates #46474.
Updates #35692.
Change-Id: Ibd5187b00ccceeb981b652f2af9a1c3766357b78
Reviewed-on: https://go-review.googlesource.com/c/go/+/339892
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The tree has package main files scattered around
in it for the purposes of running go generate.
They're all marked "// +build ignore",
which gets special handling in TestDependencies.
It would be nice to be able to use other build tags,
such as "generate", as suggested by the go generate
design doc. Plus the build tag syntax is changing.
This change skips all "package main" files.
By definition these aren't importable,
so they can't contribute to the dependency tree.
We can't quite eliminate the "// +build ignore"
check, as it is used by packages runtime and syscall.
But it's still a step in the right direction.
Change-Id: Ib9449acfdba75f570b87a4200afe944910d76222
Reviewed-on: https://go-review.googlesource.com/c/go/+/339592
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The encoding/binary little- and big-endian load and store routines are
frequently used in performance sensitive code. They look fairly complex
to the inliner. Though the routines themselves can be inlined,
code using them typically cannot be.
Yet they typically compile down to an instruction or two
on architectures that support merging such loads.
This change teaches the inliner to treat calls to these methods as cheap,
so that code using them will be more inlineable.
It'd be better to teach the inliner that this pattern of code is cheap,
rather than these particular methods. However, that is difficult to do
robustly when working with the IR representation. And the broader project
of which that would be a part, namely to model the rest of the compiler
in the inliner, is probably a non-starter. By way of contrast, imperfect
though it is, this change is an easy, cheap, and useful heuristic.
If/when we base inlining decisions on more accurate information obtained
later in the compilation process, or on PGO/FGO, we can remove this
and other such heuristics.
Newly inlineable functions in the standard library:
crypto/cipher.gcmInc32
crypto/sha512.appendUint64
crypto/md5.appendUint64
crypto/sha1.appendUint64
crypto/sha256.appendUint64
vendor/golang.org/x/crypto/poly1305.initialize
encoding/gob.(*encoderState).encodeUint
vendor/golang.org/x/text/unicode/norm.buildRecompMap
net/http.(*http2SettingsFrame).Setting
net/http.http2parseGoAwayFrame
net/http.http2parseWindowUpdateFrame
Benchmark impact for encoding/gob (the only package I measured):
name old time/op new time/op delta
EndToEndPipe-8 2.25µs ± 1% 2.21µs ± 3% -1.79% (p=0.000 n=28+27)
EndToEndByteBuffer-8 93.3ns ± 5% 94.2ns ± 5% ~ (p=0.174 n=30+30)
EndToEndSliceByteBuffer-8 10.5µs ± 1% 10.6µs ± 1% +0.87% (p=0.000 n=30+30)
EncodeComplex128Slice-8 1.81µs ± 0% 1.75µs ± 1% -3.23% (p=0.000 n=28+30)
EncodeFloat64Slice-8 900ns ± 1% 847ns ± 0% -5.91% (p=0.000 n=29+28)
EncodeInt32Slice-8 1.02µs ± 0% 0.90µs ± 0% -11.82% (p=0.000 n=28+26)
EncodeStringSlice-8 1.16µs ± 1% 1.04µs ± 1% -10.20% (p=0.000 n=29+26)
EncodeInterfaceSlice-8 28.7µs ± 3% 29.2µs ± 6% ~ (p=0.067 n=29+30)
DecodeComplex128Slice-8 7.98µs ± 1% 7.96µs ± 1% -0.27% (p=0.017 n=30+30)
DecodeFloat64Slice-8 4.33µs ± 1% 4.34µs ± 1% +0.24% (p=0.022 n=30+29)
DecodeInt32Slice-8 4.18µs ± 1% 4.18µs ± 0% ~ (p=0.074 n=30+28)
DecodeStringSlice-8 13.2µs ± 1% 13.1µs ± 1% -0.64% (p=0.000 n=28+28)
DecodeStringsSlice-8 31.9µs ± 1% 31.8µs ± 1% -0.34% (p=0.001 n=30+30)
DecodeBytesSlice-8 8.88µs ± 1% 8.84µs ± 1% -0.48% (p=0.000 n=30+30)
DecodeInterfaceSlice-8 64.1µs ± 1% 64.2µs ± 1% ~ (p=0.173 n=30+28)
DecodeMap-8 74.3µs ± 0% 74.2µs ± 0% ~ (p=0.131 n=29+30)
Fixes#42958
Change-Id: Ie048b8976fb403d8bcc72ac6bde4b33e133e2a47
Reviewed-on: https://go-review.googlesource.com/c/go/+/349931
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
They're only used in a single place.
Instead of calculating the end every time,
calculate it in the linker.
It'd be nice to recalculate baseaddr-vaddr,
but that generates relocations that are too large.
While we're here, remove some pointless uintptr -> uintptr conversions.
Change-Id: I91758f9bff11b365bc3a63fee172dbdc3d90b966
Reviewed-on: https://go-review.googlesource.com/c/go/+/354089
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This CL reverses the change in CL 284254 (which was ported
to types2) which originated in CL 240901 to address a crash
in a test created by a fuzzer (that crash appears to be
avoided in other ways, now).
This exposed another bug in typeset.go where we don't look
for the underlying type when testing if a type is an interface
or not. Fixed that as well.
Adjusted a test case that now doesn't report an error anymore
(which is good).
Fixes#48819.
Change-Id: I611d68e053d6b8a2f7176d0cd5a44da2df28ad21
Reviewed-on: https://go-review.googlesource.com/c/go/+/354329
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The type set notation has been accepted a while ago.
We're not going back to supporting the original
type list notation. Remove support for it in the
parser and type checker.
Change-Id: I860651f80b89fa43a3a5a2a02cf823ec0dae583c
Reviewed-on: https://go-review.googlesource.com/c/go/+/354131
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
With the removal of SSE2 runtime detection made in
golang.org/cl/344350 we can remove this mechanism as there
are no required features anymore.
For making sure CPUs running a go program support all
the minimal hardware requirements the go runtime should
do feature checks early in the runtime initialization
before it is likely any compiler emitted but unsupported
instructions are used. This is already the case for e.g.
checking MMX support on 386 arch targets.
Change-Id: If7b1cb6f43233841e917d37a18314d06a334a734
Reviewed-on: https://go-review.googlesource.com/c/go/+/354209
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Martin Möhrmann <martin@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
As we use relative addressing for text symbols in functab, it is
important that the offsets we computed stay unchanged by the
external linker, i.e. all symbols in Textp should not be removed
by the external linker. Most of them are actually referenced (our
deadcode pass ensures that), except go.buildid which is generated
late and not used by the program. Keep it alive.
Should fix AIX builder.
Change-Id: Ibc4a8951be997b9d8d870d75c54754977d9b8333
Reviewed-on: https://go-review.googlesource.com/c/go/+/354369
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
In GOPATH mode, source files may import other packages using relative
(“local”) paths. In module mode, relative imports are never allowed:
import paths must always be fully specified.
When local imports are allowed, we pass a local-import prefix to the
compiler using the '-D' flag. That could theoretically change the
compiler's output, so it must be included in the cache key even when
-trimpath is set. (TODO: when -trimpath is set, the local-import
prefix ought to be trimmed anyway, so it still shouldn't matter.)
However, when local imports are disallowed, we should not pass the
local-import prefix and it should not affect cmd/go's cache key or the
final build ID of any artifact.
For #48557
Change-Id: I2d627d67d13e5da2cac6d411cd4e2d87e510876c
Reviewed-on: https://go-review.googlesource.com/c/go/+/352810
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This change also fixes a bug with calculating the
total interesting count. When fuzzing with an empty
corpus, the fuzzing engine adds an starting corpus
value in that run in order to start fuzzing. That
meant that the interesting total count was off by one:
it would start at 1, even though the cache was empty.
Added some tests for this as well.
Fixes#48787
Change-Id: I47acf96f0a0797214ebb24a95366d8460bf303bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/354150
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Many uses of Index/IndexByte/IndexRune/Split/SplitN
can be written more clearly using the new Cut functions.
Do that. Also rewrite to other functions if that's clearer.
For #46336.
Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448
Reviewed-on: https://go-review.googlesource.com/c/go/+/351711
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL adds late expanded memequal(x, const, sz) inlining for 2, 4, 8
bytes size. This PoC is using the same method as CL 248404.
This optimization fires about 100 times in Go compiler (1675 occurrences
reduced to 1574, so -6%).
Also, added unit-tests to codegen/comparisions.go file.
Updates #37275
Change-Id: Ia52808d573cb706d1da8166c5746ede26f46c5da
Reviewed-on: https://go-review.googlesource.com/c/go/+/328291
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Trust: David Chase <drchase@google.com>
This adds a rule to avoid the zero extension after an AtomicLoad8
or AtomicLoad32 since the atomic load has already filled it with
zeros. This eliminates an instruction in a high use block in findObject
and the AtomicLoad8 appears many times within runtime.
Change-Id: I7e684bf73d3812110bd371e05b1aa44fa235fc9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/354029
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
The slowest thing that can happen in funcdata is a cache miss
on moduledata.gofunc. Move that memory load earlier.
Also, for better ergonomics when working on this code,
do more calculations as uintptrs.
name old time/op new time/op delta
StackCopyWithStkobj-8 10.5ms ± 5% 9.9ms ± 4% -6.03% (p=0.000 n=15+15)
Change-Id: I590f4449725983c7f8d274c4ac7ed384d9018d85
Reviewed-on: https://go-review.googlesource.com/c/go/+/354134
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
funcspdelta should be inlined: It is a tiny wrapper around another func.
The sanity check prevents that. Condition the sanity check on debugPcln.
While we're here, make the sanity check throw when it fails.
Change-Id: Iec022b8463b13a8e5a6d8479e7ddcb68909d6fe0
Reviewed-on: https://go-review.googlesource.com/c/go/+/354133
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL enables intrinsic support to emit the following prefetch
instructions for PPC64 platform that are already emitted on other
platforms
1. Prefetch - prefetches data from memory address to cache;
2. PrefetchStreamed - prefetches data from memory address, with a
hint that this data is being streamed.
Benchmarks picked from go/test/bench/garbage
Parameters tested with:
GOMAXPROCS=8
tree2 -heapsize=1000000000 -cpus=8
tree -n=18
parser
peano
Performance results with this change on POWER9
name old time/op new time/op delta
Tree2-8 75.3ms ± 2% 65.0ms ± 6% -13.61% (p=0.003 n=5+7)
Tree-8 576ms ± 2% 576ms ± 1% ~ (p=0.756 n=11+10)
Parser-8 3.60s ± 2% 3.59s ± 1% ~ (p=0.818 n=6+6)
Peano-8 84.8ms ± 1% 84.6ms ± 1% ~ (p=0.180 n=6+6)
Results on POWER8 and POWER10 are similar
Change-Id: If4ac95a85aaa7b2266014e1f8fb7cd7440cbf906
Reviewed-on: https://go-review.googlesource.com/c/go/+/353730
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
In the case of a nointerface method on an instantiated type, we still
have to call methodWrapper, because methodWrapper generates the actual
generic method on the type as well. Currently, we don't call
methodWrapper, so the method on the instantiated type never gets filled
in.
Adjusted the code to still call methodWrapper, but not use the result,
in the case of a nointerface method on an instantiated type.
Change-Id: I34bca58de2861aa772be04eb8dd7695c5b7f3a77
Reviewed-on: https://go-review.googlesource.com/c/go/+/353369
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Add a simple test with an exported generic function that does
recover/defer, to test that recover/defer are exported/imported
properly (and a generic function with recover/defer works fine).
Change-Id: Idc3af101cbb78fc96bf945f1f5eab2740dd8994b
Reviewed-on: https://go-review.googlesource.com/c/go/+/353883
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
This reverts commit golang.org/cl/352953.
Reason for revert: unsafe.Slice is considerably slower.
Part of this is extra safety checks (good), but most of it
is the function call overhead. We should consider open-coding it (#48798).
Impact of this change:
name old time/op new time/op delta
StackCopyWithStkobj-8 12.1ms ± 5% 11.6ms ± 3% -4.03% (p=0.009 n=10+8)
Change-Id: Ib2448e3edac25afd8fb55ffbea073b8b11521bde
Reviewed-on: https://go-review.googlesource.com/c/go/+/354090
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In case of amd64 the compiler issues checks if extensions are
available on a platform. With GOAMD64 microarchitecture levels
provided, some of the checks could be eliminated.
Change-Id: If15c178bcae273b2ce7d3673415cb8849292e087
Reviewed-on: https://go-review.googlesource.com/c/go/+/352010
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
When compiling with GOAMD64=v1, clobber all the >v1 instructions
with faulting instructions. Run the binary with the corresponding
feature flags off. We shouldn't try to execute any of the clobbered
instructions.
Change-Id: I295acaf9fd0eafd037192aa6f933365c794cc76e
Reviewed-on: https://go-review.googlesource.com/c/go/+/352831
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Every function has associated numbered extra funcdata to another symbol.
Prior to this change, a funcdata pointer was stored as a relocation.
This change alters this to be an offset relative to go.func.* or go.funcrel.*.
This reduces the number of relocations on darwin/arm64 by about 40%.
It also shrinks externally linked binaries. On darwin/arm64:
size before after Δ %
addr2line 3788498 3699730 -88768 -2.343%
api 5100018 4951074 -148944 -2.920%
asm 4855234 4744274 -110960 -2.285%
buildid 2500162 2419986 -80176 -3.207%
cgo 4338258 4218306 -119952 -2.765%
compile 22764418 22132226 -632192 -2.777%
cover 4583186 4432770 -150416 -3.282%
dist 3200962 3094626 -106336 -3.322%
doc 3680402 3583602 -96800 -2.630%
fix 3114914 3023922 -90992 -2.921%
link 6308578 6154786 -153792 -2.438%
nm 3754338 3665826 -88512 -2.358%
objdump 4124738 4015234 -109504 -2.655%
pack 2232626 2155010 -77616 -3.476%
pprof 13497474 13044066 -453408 -3.359%
test2json 2483810 2402146 -81664 -3.288%
trace 10108898 9748802 -360096 -3.562%
vet 6884322 6681314 -203008 -2.949%
total 107320836 104167700 -3153136 -2.938%
relocs before after Δ %
addr2line 33357 25563 -7794 -23.365%
api 31589 18409 -13180 -41.723%
asm 27825 18904 -8921 -32.061%
buildid 15603 9513 -6090 -39.031%
cgo 27809 17103 -10706 -38.498%
compile 114769 64829 -49940 -43.513%
cover 32932 19462 -13470 -40.902%
dist 18797 10796 -8001 -42.565%
doc 22891 13503 -9388 -41.012%
fix 19700 11465 -8235 -41.802%
link 37324 23198 -14126 -37.847%
nm 33226 25480 -7746 -23.313%
objdump 35237 26610 -8627 -24.483%
pack 13535 7951 -5584 -41.256%
pprof 97986 63961 -34025 -34.724%
test2json 15113 8735 -6378 -42.202%
trace 66786 39636 -27150 -40.652%
vet 43328 25971 -17357 -40.060%
total 687806 431088 -256718 -37.324%
It should also incrementally speed up binary launching
and may reduce linker memory use.
This is another step towards removing relocations so
that pages that were previously dirtied by the loader may remain clean,
which will offer memory savings useful in constrained environments like iOS.
Removing the relocations in .stkobj symbols will allow some simplifications.
There will be no references into go.funcrel.*,
so we will no longer need to use the bottom bit to distinguish offset bases.
Change-Id: I83d34c1701d6f3f515b9905941477d522441019d
Reviewed-on: https://go-review.googlesource.com/c/go/+/352110
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This change moves all symbols referred to by FUNCDATA
into go.func.* and go.funcrel.*.
Surprisingly (because it inhibits some content-addressability),
it shrinks binaries by a little bit, about 0.1%.
This paves the way for a subsequent change to change
FUNCDATA relocations to offsets.
Change-Id: I70e487205073699f442192b0791cc92da5663057
Reviewed-on: https://go-review.googlesource.com/c/go/+/352189
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
We don't need cmd/cgo for building go_bootstrap or toolchain2, so skip
building it as part of toolchain1.
This allows cmd/cgo to assume a current go/ast; e.g., that
ast.IndexListExpr exists (needed for next CL).
Change-Id: I642bba780bf273e6ea9c6e7c5d5d7ccfe86bf462
Reviewed-on: https://go-review.googlesource.com/c/go/+/353884
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use sort.Search instead of open-coding the binary search.
This makes the code a lot easier to work on.
As a bonus, it speeds it up.
name old time/op new time/op delta
115/LineToPC-8 57.4µs ± 5% 59.2µs ± 8% +3.19% (p=0.003 n=15+13)
115/PCToLine-8 255ns ± 1% 192ns ± 3% -24.63% (p=0.000 n=15+15)
Change-Id: I41da18bfb0e745c40d24e5b96e50dfdd0c3b79f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353879
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
runtime.no_pointers_stackmap is an odd beast.
It is defined in a Go file, populated by assembly,
used by the GC, and its address is magic used
by async pre-emption to ascertain whether a
routine was implemented in assembly.
A subsequent change will force all GC data into the go.func.* linker symbol.
runtime.no_pointers_stackmap is GC data, so it must go there.
Yet it also needs to go into rodata, for the runtime address trick.
This change eliminates it entirely.
Replace the runtime address check with the newly introduced asm funcflag.
Handle the assembly macro as magic, similarly to our handling of go_args_stackmap.
This allows the no_pointers_stackmap to be identical in all ways
to other gclocals stackmaps, including content-addressability.
Change-Id: Id2f20a262cfab0719beb88e6342984ec4b196268
Reviewed-on: https://go-review.googlesource.com/c/go/+/353672
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
There's no good way to ascertain at runtime whether
a function was implemented in assembly.
The existing workaround doesn't play nicely
with some upcoming linker changes.
This change introduces an explicit marker for routines
implemented in assembly.
This change doesn't use the new bit anywhere,
it only introduces it.
Change-Id: I4051dc0afc15b260724a04b9d18aeeb94911bb29
Reviewed-on: https://go-review.googlesource.com/c/go/+/353671
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Go exchanges siginfo and sigevent structures with the kernel. They
contain unions, but Go's use is limited to the first few fields. Pad out
the rest so the size Go sees is the same as what the Linux kernel sees.
This is a follow-up to CL 342052 which added the sigevent struct without
padding. It updates the siginfo struct as well so there are no bad
examples in the defs_linux_*.go files.
Change-Id: Id991d4a57826677dd7e6cc30ad113fa3b321cddf
Reviewed-on: https://go-review.googlesource.com/c/go/+/353136
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
This change updates the log lines to clarify that the printed
interesting count is only for newly discovered cache entries, and prints
the total cache size. It only prints information about interesting
entries when coverageEnabled is true.
Fixes#48669
Change-Id: I2045afc204764c1842d323e8ae42016fb21b6fb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/353172
Trust: Michael Knyszek <mknyszek@google.com>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Otherwise the type checker defaults to amd64, which can break
type-checking for definitions using unsafe.Sizeof.
This has the side effect of changing the API output: constants with
different values across architectures (e.g., MaxInt) are now
individually listed per-arch. This actually makes the API file more
accurate, but does introduce a one-time discontinuity. These changes
have been integrated into the API files where the constants were added.
Change-Id: I4bbb0b7a7f405d3adda2d83869475c8bacdeb6a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/353331
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
I've manually reviewed all uses of ctxt.Flag_shared for concurrency safety.
And I manually tested with the race detector and found no issues.
Allow -shared to be used with compiler concurrency,
thereby re-enabling concurrent compilation on darwin/arm64.
Fixes#48496
Change-Id: I8a084cb08e6050950e404ceb9bd7e3a20e07e9c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353871
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
CALL and JMP on riscv64 are currently implemented as an AUIPC+JALR pair. This means
that every call requires two instructions and makes use of the REG_TMP register,
even when the symbol would be directly reachable via a single JAL instruction.
Add support for call trampolines - CALL and JMP are now implemented as a single JAL
instruction, with the linker generating trampolines in the case where the symbol is
not reachable (more than +/-1MiB from the JAL instruction), is an unknown symbol or
does not yet have an address assigned. Each trampoline contains an AUIPC+JALR pair,
which the relocation is applied to.
Due to the limited reachability of the JAL instruction, combined with the way that
the Go linker currently assigns symbol addresses, there are cases where a call is to
a symbol that has no address currently assigned. In this situation we have to assume
that a trampoline will be required, however we can patch this up during relocation,
potentially calling directly instead. This means that we will end up with trampolines
that are unused. In the case of the Go binary, there are around 3,500 trampolines of
which approximately 2,300 are unused (around 9200 bytes of machine instructions).
Overall, this removes over 72,000 AUIPC instructions from the Go binary.
Change-Id: I2d9ecfb85dfc285c7729a3cd0b3a77b6f6c98be0
Reviewed-on: https://go-review.googlesource.com/c/go/+/345051
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The golang.org/x/net/route package can't parse the RIB returned
by NET_RT_IFLISTL. Use the route.RIBTypeInterface constant
instead, leaving the choice of syscall up to the route package.
Fixes#48553.
Change-Id: Ida4bd6e332c0dc6dc871d3a93cfb56c0fbc93e1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/353611
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Now that gofmt knows how to format many files in parallel,
there's no need for "go fmt" to have its own parallelism.
Instead of running "gofmt -l -w $file" in parallel with GOMAXPROCS,
simply collect a large list of files and hand it to "gofmt -l -w $files".
The benchmark below was obtained via:
benchcmd -n 10 FmtGorootCmd go fmt cmd
We can see a drastic improvement in system time per call.
This makes sense, as we used to fork+exec one gofmt program per file,
and now we only do that for every thousand or so files.
We also see an increase in peak memory usage and user CPU time.
This seems to be because each gofmt process was very short lived before.
This meant that there was a limit to the total amount of allocations
produced by go/parser and go/printer before the process stopped,
and thus the GC probably didn't kick in most of the time.
Now that each gofmt process formats hundreds or thousands of files,
a lot of those allocations pile up in the same process,
making peak-RSS go higher and piling on garbage for the GC to clean up.
Finally, note that time/op seems largely unchanged.
I did many benchmark runs; some ended up in noise like the one below,
and others gave small wall time speed-ups of 3-4%.
It seems like we get very little wall time benefit,
possibly due to the factors mentioned earlier cancelling each other out.
Overall, it seems worthwhile to not let "go fmt" do its own parallelism,
to keep the tool simpler to understand and maintain going forward.
Plus, the sys-time savings do seem to be the biggest change here.
name old time/op new time/op delta
FmtGorootCmd 850ms ± 4% 842ms ± 6% ~ (p=0.529 n=10+10)
name old user-time/op new user-time/op delta
FmtGorootCmd 7.30s ± 4% 7.67s ± 3% +5.07% (p=0.000 n=10+10)
name old sys-time/op new sys-time/op delta
FmtGorootCmd 1.66s ± 7% 0.43s ±24% -74.08% (p=0.000 n=10+10)
name old peak-RSS-bytes new peak-RSS-bytes delta
FmtGorootCmd 30.1MB ± 4% 199.4MB ±21% +563.03% (p=0.000 n=10+10)
To make use of the already-present "maximum exec arg length limit"
constant in cmd/go/internal, move it to cmd/internal.
Fixes#43566.
Change-Id: If864151d0c851a40bf7138f9864640f15a066d48
Reviewed-on: https://go-review.googlesource.com/c/go/+/353309
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In types1 and for the export format, we were using type param subscripts
coming from types2 (originally for debugging) to provide unique names.
We need unique full-names for type params in types1 to ensure consistent
references to type params in function/method bodies and type params
derived from translation from types2. We also currently need unique
names for type params in importer/iimport.go and gcimporter/iimport.go,
because there are no levels of scoping in the package symbol lookup and
pkgIndex table.
As a step to eliminate the typeparam subscripts (which have no
relation to the source code), we change so that the typeparams' unique
name is just prefixing the type param name with the name of the
enclosing generic function, type, or method.
We now no longer use types2.TypeString in types2-to-types1 translation,
so Typestring can be changed to eliminate the subscript, as needed.
Also, types2.TypeParam.SetId() is no longer needed and is eliminated.
We can decide later if we want to do the further step of adding scoping
to the importer/iimport.go and gcimporter/iimport.go, which could be
used to eliminate the type param "path" prefix from the export format.
Change-Id: I0e37795664be2c2e1869b8f9e93393b83fc56409
Reviewed-on: https://go-review.googlesource.com/c/go/+/353135
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Discard is not really a read operation, and in theory it could
Seek the underlying Reader without actually reading anything,
so an UnreadByte following a Discard is disallowed.
Similarly, although WriteTo usually does end up calling Read on the
underlying buffer, if the underlying Reader implements io.WriterTo it
may instead terminate in a call to WriteTo, without ever buffering or
even seeing the last byte written. (It is conceptually read-like, but
not strictly “a read operation”.)
Fixes#48446
Change-Id: Ide6f2b157332b423486810399f66140c914144e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/351810
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
This change enables the relaxed syntax for constraint literals
as proposed in issue #48424 and adds a simple smoke test for
the compiler. (Most of the relevant changes are in the syntax
and types2 package which have more extensive tests for this.)
This makes it possible to experiment with the new syntax while
we contemplate the fate of #48424.
If #48424 is accepted, this change can remain. If #48424 is
not accepted, reverting this CL will remove this feature in
the compiler.
For #48424.
Change-Id: I624fbb37c2f616ee9ad692e17e4fc75c9d5b06e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353389
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
When collecting type parameters, wrap constraint literals of the
form ~T or A|B into interfaces so the type checker doesn't have
to deal with these type set expressions syntactically anywhere
else but in interfaces (i.e., union types continue to appear
only as embedded elements in interfaces).
Since a type constraint doesn't need to be an interface anymore,
we can remove the respective restriction. Instead, when accessing
the constraint interface via TypeParam.iface, wrap non-interface
constraints at that point and update the constraint so it happens
only once. By computing the types sets of all type parameters at
before the end of type-checking, we ensure that type constraints
are in their final form when accessed through the API.
For #48424.
Change-Id: I3a47a644ad4ab20f91d93ee39fcf3214bb5a81f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/353139
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL permits an arbitrary type as well as the type sets ~T and A|B
in constraint position, without the need of a surrrounding interface.
For instance, the type parameter list
[P interface{ ~map[K]V }, K comparable, V interface{ ~string }]
may be written as
[P ~map[K]V, K comparable, V ~string]
The feature must be enabled explicitly with the AllowTypeSets mode
and is only available if AllowGenerics is set as well.
For #48424.
Change-Id: Ic70bb97a49ff75e67e040853eac10e6aed0fef1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/353133
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The linker specially handles go.importpath symbols. But the
compiler doesn't actually generate such symbols. Instead, it
generates type..importpath symbols. It is already in the type
section as the name starts with "type.". Also set its alignment
to 1, as it is string data.
Change-Id: I771f5529a0ff41a5bb476b3a02c8cc75729792de
Reviewed-on: https://go-review.googlesource.com/c/go/+/353489
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Set alignment for string symbols in symtab pass, so we don't need
to look at symbol name in symalign in dodata pass. (Ideally we
should not use symbol name like this in symtab pass either, but
we already use the names there anyway.)
Change-Id: I9fd61e0dd0824c50e3d0d7c07f75b967c8654796
Reviewed-on: https://go-review.googlesource.com/c/go/+/353470
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Funcdata like opendefer info and traceback arginfo are varints or
bytes. There is no need to align them.
GC liveness map and inline tree have 32-bit fields, so continue
align them to 4 bytes.
Change-Id: I9d5dd750a926c65a910efe5817f9f5c473019bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/353469
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
When building for macOS with external linking, we currently use
"xcrun" to invoke "dsymutil" and "strip" tools. That doesn't work
well for cross compilation. Use "CC --print-prog-name" to find the
tool path instead.
Fixes#47316.
Change-Id: Ib30c6494c48bfb6a505dc26fe644ef543d777076
Reviewed-on: https://go-review.googlesource.com/c/go/+/336769
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
On Darwin/ARM64 when external linking, for very large text we
split it into multiple sections. For each section (other than the
first) we create runtime.text.N marker symbols. In CL 316050 I
forgot to add those symbols to the symbol table. This CL does it.
It doesn't actually matter for program execution. But we add them
on ELF when splitting text sections, so we do it here as well.
Also, this makes it easier to tell if we split text sections.
Change-Id: Ida7f8e9431867881e5ee2bc1a2129eeaf83cb878
Reviewed-on: https://go-review.googlesource.com/c/go/+/353209
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently TestPCLine is skipped in short mode. The test builds a
Linux/AMD64 binary, so it makes sense to skip it if we're cross
compiling, as building the runtime takes a while. But if we are
on Linux/AMD64, it will only build a small amount of code, which
isn't really slow. The test runs in 0.14 second on my machine.
I think it is acceptable to run in short mode. Then we'll have
trybot coverage for this test.
Change-Id: If682f88c28050f7daafde35b4f9e59c03b764a35
Reviewed-on: https://go-review.googlesource.com/c/go/+/353330
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Add doc comment about the time/tzdata package to the time.LoadLocation
function. The time.LoadLocation function was changed in Go 1.15 to add an extra
source that it considers for the time zone database. That location is the
time/tzdata package. It is not easy to discover this behavior because the
documentation for the time package doesn't mention it in the discussion on the
time.LoadLocation function when discussing the different sources. It would be helpful to
describe all possible sources that time.LoadLocation considers when loading the
time zone database, and so I think it would be worthwhile to mention
time/tzdata.
Change-Id: I408fbe188bf9d4ba797e59ec17eb677136d6a9c2
GitHub-Last-Rev: 3dac204326
GitHub-Pull-Request: golang/go#48673
Reviewed-on: https://go-review.googlesource.com/c/go/+/352830
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
The current Go assembler encodes "MOVK $(0<<16|32|48), Rd" as the
same binary with "MOVK $0, Rd", but for arm64 move constant instructions
MOVK, MOVN and MOVZ, "op $0, Rd" and "op $(0<<16|32|48), Rd" have
different semantics. In order not to change the way the assembler
frontend parses constants, this patch adds a check for the zero shifts.
Change-Id: Ia844c419ce49f63605b549e3a2e98d9075dd1cf1
Reviewed-on: https://go-review.googlesource.com/c/go/+/275812
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The first field of the func data stored by the linker is the
entry PC for the function. Prior to this change, this was stored
as a relocation to the function. Change this to be an offset
relative to runtime.text.
This reduces the number of relocations on darwin/arm64 by about 10%.
It also slightly shrinks binaries:
file before after Δ %
addr2line 3803058 3791298 -11760 -0.309%
api 5140114 5104242 -35872 -0.698%
asm 4886850 4840626 -46224 -0.946%
buildid 2512466 2503042 -9424 -0.375%
cgo 4374770 4342274 -32496 -0.743%
compile 22920530 22769202 -151328 -0.660%
cover 4624626 4588242 -36384 -0.787%
dist 3217570 3205522 -12048 -0.374%
doc 3715026 3684498 -30528 -0.822%
fix 3148226 3119266 -28960 -0.920%
link 6350226 6313362 -36864 -0.581%
nm 3768850 3757106 -11744 -0.312%
objdump 4140594 4127618 -12976 -0.313%
pack 2227474 2218818 -8656 -0.389%
pprof 13598706 13506786 -91920 -0.676%
test2json 2497234 2487426 -9808 -0.393%
trace 10198066 10118498 -79568 -0.780%
vet 6930658 6889074 -41584 -0.600%
total 108055044 107366900 -688144 -0.637%
It should also incrementally speed up binary launching.
This is the first step towards removing enough relocations
that pages that were previously dirtied by the loader may remain clean,
which will offer memory savings useful in constrained environments.
Change-Id: Icfba55e696ba2f9c99c4f179125ba5a3ba4369c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/351463
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This was useful for debugging while we were developing
the feature, but is now causing extraneous prints that
make the command output difficult to read.
This change also prevents the go command from printing
an extraneous "FAIL" when fuzzing is enabled.
Fixes#48633Fixes#46631
Change-Id: I636e65f305a20f6dcd843e62090ae228741a3725
Reviewed-on: https://go-review.googlesource.com/c/go/+/352892
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
There are special flags that must be passed to the
compiler at build time in order to instrument the
testing binary for fuzzing.
One potential option would be to add these flags to
p.Internal.Gcflags inside cmd/go/internal/test. However,
future calls to setToolFlags can cause these flags to
get cleared about before the build starts, removing
virtually all coverage guidance. This change moves the
logic to add the flag deeper down the call stack,
preventing it from being cleared.
Change-Id: I40eadb0cacc18f29cee75379cd9380f9e73bb8da
Reviewed-on: https://go-review.googlesource.com/c/go/+/352511
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Replace the name Environment with Context, as discussed in #47916. Along
the way, fix some stale or inaccurate comments.
The Environment type remains temporarily as an alias for Context, to
allow the x/tools Trybot to pass until dependency on types.Environment
can be removed.
Updates #47916
Change-Id: Iffd069ab0e8adebf4207c8f8891468a64d32b7cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/353089
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
debug/gosym assumes throughout that bogus input means a malformed file.
That's generally true, but not when you're changing the package.
In that case, the panic usually indicates a newly introduced bug,
and seeing the panic is really useful.
Add a manually-enabled way to make panics panic.
Change-Id: I07af6c7b982c4cf61180db29f07aa63576ba7837
Reviewed-on: https://go-review.googlesource.com/c/go/+/352949
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The computation for determining the shapes to use at the top of
getInstantation was not always creating shapes with the proper indexes.
If an instantiation is being called from another instantiated function,
we cannot just copy the shape types unchanged, because their indexes may
have changed. So, for type args that already shapes, we still call
Shapify() with the correct index.
Fixes#48645
Change-Id: Ibb61c6f9a3c317220fb85135ca87eb5ad4dcff9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/353030
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is an almost clean port of CL 352832 from types2 to go/types:
The nest files and unify.go where copied verbatim; unify.go was
adjusted with correct package name, a slightly different comment
was restored to what it was. The test files got adjustments for
error position. infer.go got a missing _Todo error code.
For #48619.
For #48656.
Change-Id: Ia1a2d09e8bb37a85032b4b7e7c7a0b08e8c793a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353029
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
If the type T inferred for a type parameter P is P itself (or a derived
type containing P), a subsequent unification step leads to infinite
recursion: at each encounter of P with the already inferred type T
(which is or contains P), P stands for that T and the recursive matching
process continues with T, which inevitably contains P again and recursion
never terminates.
This CL introduces a set of masks, one for each type parameter.
When a type parameter is encountered for which a type has already
been inferred, the type parameter is "masked" for the recursive
matching of the inferred type. Masking makes the type parameter
"invisible" such that it will be handled like any other type and
not unpacked further.
Fixes#48619.
For #48656.
Change-Id: Ic1d938322be51fd44323ea14f925303f58b27c97
Reviewed-on: https://go-review.googlesource.com/c/go/+/352832
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This adds the regabi support needed for reflect including:
- implementation of the makeFuncSub and methodValueCall for
reflect
- implementations of archFloat32FromReg and archFloat32ToReg
needed for PPC64 due to differences in the way float32 are
represented in registers as compared to other platforms
- change needed to stack.go due to the functions that are
changed above
Change-Id: Ida40d831370e39b91711ccb9616492b7fad3debf
Reviewed-on: https://go-review.googlesource.com/c/go/+/352429
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
This is a port of CL 352616 from go/types to types2. It also removes
Interface.IsConstraint and adjusts all uses to use IsMethodSet. The
dual changes are made to the (unexported) type set implementation.
Change-Id: I292b741d1f7cdbaefb483eed75faf7b85a8d2792
Reviewed-on: https://go-review.googlesource.com/c/go/+/352872
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
There's no go.mod file for 'go get' to update, so it has no effect,
other than checking arguments and filling the module cache. That might
be useul in some cases, but it seems better to fail loudly in case the
user hasn't seen the deprecation warning, for example, inside a
script.
For #43684
Change-Id: I6e67c782e3a1cb7046eac5c9df17eda7a31c7bce
Reviewed-on: https://go-review.googlesource.com/c/go/+/352149
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
As part of #40267, 'go install' is now fully responsible for building
and installing executables. 'go get' will only be used to change
versions in go.mod. The -d flag no longer has any effect; its behavior
is the default.
When 'go get' is invoked inside a module on a main package outside of
the main module, it no longer prints any warning. In 1.16-1.17, we
suggested using -d in this situation, but we want
'go get example.com/cmd' to be able to upgrade a tool dependency
without needing -d to suppress the warning.
For #43684
Change-Id: I9daf29c123a5a0e382aa326d62721cb26fc26c19
Reviewed-on: https://go-review.googlesource.com/c/go/+/349997
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Do not require the byte or rune unread by the call to match the last
return from ReadByte or ReadRune, since in practice the
implementations of these methods (especially ReadByte) may also unread
bytes from other Read-style methods without reporting an error.
Explicitly allow the Seek-like behavior implemented by bytes.Reader
and bufio.Reader, which can “unread” bytes that were never actually
read.
Explicitly allow ReadByte or ReadRune to return an error after a call
to a non-ReadByte or non-ReadRune operation respectively.
(In practice, implementations today allow very liberal calls to
ReadByte and tend to be more strict about ReadRune, but it seems
simpler to keep the two definitions completely parallel.)
Like CL 349054, this is techincally a breaking change, but given the
long-standing behavior of the implementations in the Go standard
library (such as strings.Reader, bytes.Buffer, and bufio.Reader),
I believe it falls under the “specification errors” exception to the
Go 1 compatibility policy.
Fixes#48449
Change-Id: I61696a59770fe83c667377ba25a072762d3f6f19
Reviewed-on: https://go-review.googlesource.com/c/go/+/351809
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
When writing an object file, most symbols are indexed in
NumberSyms. Currently, pcdata symbols are indexed late and
separately. This is not really necessary, as pcdata symbols
already exist at the time of NumberSyms. Just do it there.
As pcdata symbols are laid out in the pclntab in a special way at
link time, distinguish them from other symbols in the content
hash. (In the old code this was partly achieved by indexing them
late.)
Change-Id: Ie9e721382b0af2cfb39350d031e2e66d79095a3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/352611
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
As pointed out in #47916, the IsConstraint method becomes ambiguously
named if ever we allow interfaces with structural restrictions outside
of constraint position.
Add instead an IsMethodSet method, which has the opposite sense and
avoids this ambiguity. In a subsequent CL the IsConstraint method will
be removed, once x/tools has been updated to use the IsMethodSet API.
Updates #47916
Change-Id: I82ad16b111464b0cd2f354b8ecdd4b3f14796cd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/352616
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In #47916, consensus has emerged that adding a new constructor is
preferable to using setters for type parameters. This is more consistent
with the rest of the type API, which is immutable except in cases where
mutation is necessary to break cycles (such as Named.SetUnderlying).
This CL adds a new constructor NewSignatureType that accepts type
parameters and receiver type parameters, deprecating the existing
NewSignature constructor. SetTypeParams and SetRecvTypeParams are not
yet removed: this will be done in a follow-up CL once x/tools no longer
has a dependency on the old APIs.
Updates #47916
Change-Id: I9d04dcfd304344d2aa08e527b371c3faa9d738e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/352615
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The goal of this change is to improve the documentation
and make it easier to keep Link.NumberSyms and writer.contentHash aligned.
No functional changes.
A subsequent change will add conditions to contentHashSection.
Change-Id: I0a274f6974459d34d5a8553081f33ea4cd87f248
Reviewed-on: https://go-review.googlesource.com/c/go/+/352669
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
We were putting type descriptor funcdata,
such as type..eq.[2]interface {}.arginfo1
in type.* or typerel.* instead of go.func.*.
Fix that.
Change-Id: I779e6be3dd91c8029f2c3dc0e10a7d597c16678f
Reviewed-on: https://go-review.googlesource.com/c/go/+/352071
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
As discussed in #47658, Value already has CanAddr and CanInterface to
test if a call to Addr or Inteface, respectively, does not result in a
panic.
Therefore we add CanInt, CanUint, CanFloat and CanComplex to ease the
test for a possible panic in calling, respectively, Int, Uint, Float and
Complex.
Fixes#47658
Change-Id: I58b77d77e6eec9f34234e985f631eab72b5b935e
Reviewed-on: https://go-review.googlesource.com/c/go/+/352131
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This will be required when we change from storing entry PCs in _func
to entry PC offsets, which are relative to the containing module.
Notably, almost all uses of the entry method were already called
on a funcInfo. Only Func.Entry incurs the additional module
lookup cost.
This makes Entry considerably slower, but it is probably
still fast enough in absolute terms that it is OK.
name old time/op new time/op delta
Func/Name-8 8.86ns ± 0% 8.33ns ± 2% -5.92% (p=0.000 n=12+13)
Func/Entry-8 0.64ns ± 0% 2.62ns ±36% +310.07% (p=0.000 n=14+15)
Func/FileLine-8 24.5ns ± 0% 25.0ns ± 4% +2.21% (p=0.015 n=14+13)
Change-Id: Ia2d5de5f2f83fab334f1875452b9e8e87651d340
Reviewed-on: https://go-review.googlesource.com/c/go/+/351461
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
_func and funcinl are type-punned.
We distinguish them at runtime by inspecting the first word.
Prior to this change, we used 0 as the sentinel value
that means that a Func is a funcinl.
That worked because _func's first word is the functions' entry PC,
and 0 is not a valid PC. I plan to make *_func's entry PC relative
to the containing module. As a result, 0 will be a valid value,
for the first function in the module.
Switch to ^0 as the new sentinel value, which is neither a valid
entry PC nor a valid PC offset.
Change-Id: I4c718523a083ed6edd57767c3548640681993522
Reviewed-on: https://go-review.googlesource.com/c/go/+/351459
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
runtime.Func.{Name,FileLine} need to be able to
go from a *_func to a funcInfo. The missing bit of
information is what module contains that *_func.
The existing implementation looked up the module
using the *_func's entry PC. A subsequent change will
store *_func's entry PC relative to the containing module.
Change the module lookup to instead for the module
whose pclntable contains the *_func,
cutting all dependencies on the contents of the *_func.
Change-Id: I2dbbfec043ebc2e9a6ef19bbdec623ac84353b10
Reviewed-on: https://go-review.googlesource.com/c/go/+/351458
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Instead of growing 2x for < 1024 elements and 1.25x for >= 1024 elements,
use a somewhat smoother formula for the growth factor. Start reducing
the growth factor after 256 elements, but slowly.
starting cap growth factor
256 2.0
512 1.63
1024 1.44
2048 1.35
4096 1.30
(Note that the real growth factor, both before and now, is somewhat
larger because we round up to the next size class.)
This CL also makes the growth monotonic (larger initial capacities
make larger final capacities, which was not true before). See discussion
at https://groups.google.com/g/golang-nuts/c/UaVlMQ8Nz3o
256 was chosen as the threshold to roughly match the total number of
reallocations when appending to eventually make a very large
slice. (We allocate smaller when appending to capacities [256,1024]
and larger with capacities [1024,...]).
Change-Id: I876df09fdc9ae911bb94e41cb62675229cb10512
Reviewed-on: https://go-review.googlesource.com/c/go/+/347917
Trust: Keith Randall <khr@golang.org>
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <martin@golang.org>
We currently make dictionaries contain a relocation pointing to
methods that generic code might use, so that those methods are not
deadcode eliminated. However, with inlining we can end up not using
the dictionary, making the reference from the dictionary to the method
no longer keep the method alive.
Fix this by keeping the dictionary alive at generic interface call sites.
It's a bit of overkill, as we only need to keep the dictionary statically
alive. We don't actually need it dynamically alive, which is what KeepAlive
does. But it works. It ends up generating a LEAQ + stack spill that aren't
necessary, but that's pretty low overhead.
To make this work, I needed to stop generating methods on shape types.
We should do this anyway, as we shouldn't ever need them. But currently
we do use them! issue44688.go has a test that only works because it calls
a method on a shape type. I've disabled that test for now, will work on it
in a subsequent CL.
Fixes#48047
Change-Id: I78968868d6486c1745f51b8b43be0898931432a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/349169
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
In a previous change, I was too aggressive in substInstType() in not
generating methods for shape types during import. We do actually want to
generate the method nodes - we just don't want to generate method bodies
(which we would never use). We may need the method nodes for checking
types later in the compile (especially with inlining).
So, we do generate method nodes for shape types during import. In
order to avoid the name collision we previously had, we now add
".nofunc." to the method nodes for shape types (during import and in the
type substituter). We do that by passing in a 'isMethodNode' arg to
MakeInstSym. We keep the normal name (without ".nofunc") for any other
method nodes, and for the instantiated functions that help with
implementing the methods of fully-instantiated types. The ".nofunc"
names will never appear in the executable, since we don't generate any
method bodies for the method nodes of shape types.
Change-Id: I3e57e328691214140ca5f48d32011552d2a0d45d
Reviewed-on: https://go-review.googlesource.com/c/go/+/352470
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
They tend to be things like ".shape.int" which are noisy, if not
otherwise confusing.
It would be nice to somehow print the real instantiations here, but that
requires keeping track of the dictionary argument so the instantiating
types could be found. One day, maybe, but not today.
Fixes#48578
Change-Id: I0968d24e110b6d47c9468c45372a6979575a8d29
Reviewed-on: https://go-review.googlesource.com/c/go/+/352118
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The sigprofNonGo and sigprofNonGoPC functions are only used on unix-like
platforms. In preparation for unix-specific changes to sigprofNonGo,
move it (plus its close relative) to a unix-specific file.
Updates #35057
Change-Id: I9c814127c58612ea9a9fbd28a992b04ace5c604d
Reviewed-on: https://go-review.googlesource.com/c/go/+/351790
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: David Chase <drchase@google.com>
Using setitimer on Linux to request SIGPROF signal deliveries in
proportion to the process's on-CPU time results in under-reporting when
the program uses several goroutines in parallel. Linux calculates the
process's total CPU spend on a regular basis (often every 4ms); if the
process has spent enough CPU time since the last calculation to warrant
more than one SIGPROF (usually 10ms for the default sample rate of 100
Hz), the kernel is often able to deliver only one of them. With these
common settings, that results in Go CPU profiles being attenuated for
programs that use more than 2.5 goroutines in parallel.
To avoid in effect overflowing the kernel's process-wide CPU counter,
and relying on Linux's typical behavior of having the active thread
handle the resulting process-targeted signal, use timer_create to
request a timer for each OS thread that the Go runtime manages. Have
each timer track the CPU time of a single thread, with the resulting
SIGPROF going directly to that thread.
To continue tracking CPU time spent on threads that don't interact with
the Go runtime (such as those created and used in cgo), keep using
setitimer in addition to the new mechanism. When a SIGPROF signal
arrives, check whether it's due to setitimer or timer_create and filter
as appropriate: If the thread is known to Go (has an M) and has a
timer_create timer, ignore SIGPROF signals from setitimer. If the thread
is not known to Go (does not have an M), ignore SIGPROF signals that are
not from setitimer.
Counteract the new bias that per-thread profiling adds against
short-lived threads (or those that are only active on occasion for a
short time, such as garbage collection workers on mostly-idle systems)
by configuring the timers' initial trigger to be from a uniform random
distribution between "immediate trigger" and the full requested sample
period.
Updates #35057
Change-Id: Iab753c4e5101bdc09ef9132eec84a75478e05579
Reviewed-on: https://go-review.googlesource.com/c/go/+/324129
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This adds the changes for the register ABI in the runtime
functions for ppc64x:
- Add spill functions used by runtime
- Add ABIInternal to functions
Some changes were needed to the stubs files
due to vet issues when compiling for linux/ppc64.
Change-Id: I010ddbc774ed4f22e1f9d77833bd55b919d95c99
Reviewed-on: https://go-review.googlesource.com/c/go/+/351590
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This should have been part of https://golang.org/cl/340049 but I
overlooked it. That commit added fast path code when the destination
image was *not* an *image.RGBA. This commit edits func drawRGBA.
name old time/op new time/op delta
RGBA1-4 5.11ms ± 1% 1.12ms ± 1% -78.01% (p=0.008 n=5+5)
RGBA2-4 8.69ms ± 1% 2.98ms ± 1% -65.77% (p=0.008 n=5+5)
Updates #44808.
Updates #46395.
Change-Id: I899d46d985634fc81ea47ff4f0d436630e8a961c
Reviewed-on: https://go-review.googlesource.com/c/go/+/351852
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Deal correctly with a blank local variable with type param type. This is
a special case, because a blank local variable is not in the fn.Dcl
list. In this case, we must explicitly create a new blank node with the
correct substituted type, so we have correct types if the blank local
variable has an initializing assignment.
Fixes#48602
Change-Id: I903ea44b29934e180404e32800773b7309bf297b
Reviewed-on: https://go-review.googlesource.com/c/go/+/352117
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
gofmt is pretty heavily CPU-bound, since parsing and formatting 1MiB
of Go code takes much longer than reading that amount of bytes from
disk. However, parsing and manipulating a large Go source file is very
difficult to parallelize, so we continue to process each file in its
own goroutine.
A Go module may contain a large number of Go source files, so we need
to bound the amount of work in flight. However, because the
distribution of sizes for Go source files varies widely — from tiny
doc.go files containing a single package comment all the way up to
massive API wrappers generated by automated tools — the amount of
time, work, and memory overhead needed to process each file also
varies. To account for this variability, we limit the in-flight work
by bytes of input rather than by number of files. That allows us to
make progress on many small files while we wait for work on a handful
of large files to complete.
The gofmt tool has a well-defined output format on stdout, which was
previously deterministic. We keep it deterministic by printing the
results of each file in order, using a lazily-synchronized io.Writer
(loosly inspired by Haskell's IO monad). After a file has been
formatted in memory, we keep it in memory (again, limited by the
corresponding number of input bytes) until the output for all previous
files has been flushed. This adds a bit of latency compared to
emitting the output in nondeterministic order, but a little extra
latency seems worth the cost to preserve output stability.
This change is based on Daniel Martí's work in CL 284139, but using a
weighted semaphore and ephemeral goroutines instead of a worker pool
and batches. Benchmark results are similar, and I find the concurrency
in this approach a bit easier to reason about.
In the batching-based approach, the batch size allows us to "look
ahead" to find large files and start processing them early. To keep
the CPUs saturated and prevent stragglers, we would need to tune the
batch size to be about the same as the largest input files. If the
batch size is set too high, a large batch of small files could turn
into a straggler, but if the batch size is set too low, the largest
files in the data set won't be started early enough and we'll end up
with a large-file straggler.
One possible alternative would be to sort by file size instead of
batching: identify all of the files to be processed, sort from largest
to smallest, and then process the largest files first so that the
"tail" of processing covers the smallest files. However, that approach
would still fail to saturate available CPU when disk latency is high,
would require buffering an arbitrary amount of metadata in order to
sort by size, and (perhaps most importantly!) would not allow the
`gofmt` binary to preserve the same (deterministic) output order that
it has today.
In contrast, with a semaphore we can produce the same deterministic
output as ever using only one tuning parameter: the memory footprint,
expressed as a rough lower bound on the amount of RAM available per
thread. While we're below the memory limit, we can run arbitrarily
many disk operations arbitrarily far ahead, and process the results of
those operations whenever they become avaliable. Then it's up to the
kernel (not us) to schedule the disk operations for throughput and
latency, and it's up to the runtime (not us) to schedule the
goroutines so that they complete quickly.
In practice, even a modest assumption of a few megabytes per thread
seems to provide a nice speedup, and it should scale reasonably even
to machines with vastly different ratios of CPU to disk. (In practice,
I expect that most 'gofmt' invocations will work with files on at most
one physical disk, so the CPU:disk ratio should vary more-or-less
directly with the thread count, whereas the CPU:memory ratio is
more-or-less independent of thread count.)
name \ time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 11.9s ± 2% 2.7s ± 3% 2.8s ± 5%
name \ user-time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 13.5s ± 2% 14.4s ± 1% 14.7s ± 1%
name \ sys-time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 465ms ± 8% 229ms ±28% 232ms ±31%
name \ peak-RSS-bytes baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 77.7MB ± 4% 162.2MB ±10% 192.9MB ±15%
For #43566
Change-Id: I4ba251eb4d188a3bd1901039086be57f0b341910
Reviewed-on: https://go-review.googlesource.com/c/go/+/317975
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
'go mod why -m' works by listing modules matching command line
arguments, then loading "all" packages and finding which of the listed
modules provide packages imported by the main module.
If go.mod is inconsistent (that is, a requirement has a lower version
than MVS would select when the module graph is loaded) and pruned
(that is, the module graph is only loaded when necessary), then
modload.ListModules may return modules with different versions than
would be selected in modload.LoadPackages.
'go mod why -m' was too strict about this, mapping module paths and
versions to packages. With this fix, it maps module paths without
versions to packages.
Fixes#48613
Change-Id: I836c46289bb647d6c46ec65e7589531da532d5e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/352115
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The delayTransform only checks whether ir.CurFunc is generic function or
not. but when compiling a non-generic closure inside a generic function,
we also want to delay the transformation, which delayTransform fails to
detect, since when ir.CurFunc is the closure, not the top level function.
Instead, we must rely on irgen.topFuncIsGeneric field to decide whether
to delay the transformation, the same logic with what is being done for
not adding closure inside a generic function to g.target.Decls list.
Fixes#48609
Change-Id: I5bf5592027d112fe8b19c92eb906add424c46507
Reviewed-on: https://go-review.googlesource.com/c/go/+/351855
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
In markType() in crawler.go, mark the type of a unexported field if it
is a fully-instantiated type, since we create and instantiate the
methods of any fully-instantiated type that we see during import. As
before, we still do not mark the type of an unexported field if that
type is not generic. Fixes#48454 and most recent issue described in
48337. The included test is similar to the case in 48454.
Fixes#48454Fixes#48337
Change-Id: I77a2a62b9e2647876facfa6f004201e8f699c905
Reviewed-on: https://go-review.googlesource.com/c/go/+/351315
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
When I separate out the dictionary transformations to dictPass, I missed
duplicating a conditional that deals with OMETHVALUE nodes that are
actually called. We create the OMETHVALUE when transforming bounds
function reference (before we know whether that reference will be
called), and we need to call transformDot() again to convert the
OMETHVALUE to ODOTMETH if the reference is actually called (the usual
case). Without this change, we leave the OMETHVALUE in, and extra *-fm
are created and used unncessarily.
Also, fixed a few places where we were missing ir.MarkFunc(), which sets
the class of a function node properly.
Change-Id: I6b02613039b16b507b44525faa2cd7031afb6982
Reviewed-on: https://go-review.googlesource.com/c/go/+/352069
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Subcommands may now set the global flag modload.ExplicitWriteGoMod
instead of calling {Allow,Disallow}WriteGoMod.
When ExplicitWriteGoMod is false (default), modload.LoadPackages and
ListModules will either update go.mod and go.sum or report an error if
they need to be updated, depending on cfg.BuildMod.
When ExplicitWriteGoMod is true, commands must explicitly call
modload.WriteGoMod to update go.mod and go.sum or report an
error. Commands that perform some operation after loading the build
list (like downloading zips or building packages) and commands that
load packages multiple times should set this. For now, only 'go get'
and 'go mod download' set this.
This CL is a pure refactor: no change in behavior is expected.
There are some other minor changes in here, too: commitRequirements no
longer sets the global requirements: that should be done separately first.
Change-Id: I69942a808bb177faf7904a53aaf2d4ac68500e82
Reviewed-on: https://go-review.googlesource.com/c/go/+/349600
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
They should also not report an error if these files need to be
updated. These commands are used for debugging, so it's important that
they still work when go.mod and go.sum are incomplete.
For #40775
Change-Id: I1b731599e5a4510f47827b9812525636a7402bf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/351468
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
m.vdsoSP should be set to the SP of the caller of nanotime1,
instead of the SP of nanotime1 itself, which matches m.vdsoPC.
Otherwise the unmatched vdsoPC and vdsoSP would make the stack
trace look like recursive.
We already do it correctly on AMD64, 386, and RISCV64. This CL
fixes the rest.
Fixes#47324.
Change-Id: I98b6fcfbe9fc6bdd28b8fe2a1299b7c505371dd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/337590
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Instructions with immediates can be precomputed when operating on a
constant - do so for SLTI/SLTIU, SLLI/SRLI/SRAI, NEG/NEGW, ANDI, ORI
and ADDI. Additionally, optimise ANDI and ORI when the immediate is
all ones or all zeroes.
In particular, the RISCV64 logical left and right shift rules
(Lsh*x*/Rsh*Ux*) produce sequences that check if the shift amount
exceeds 64 and if so returns zero. When the shift amount is a
constant we can precompute and eliminate the filter entirely.
Likewise the arithmetic right shift rules produce sequences that
check if the shift amount exceeds 64 and if so, ensures that the
lower six bits of the shift are all ones. When the shift amount
is a constant we can precompute the shift value.
Arithmetic right shift sequences like:
117fc: 00100513 li a0,1
11800: 04053593 sltiu a1,a0,64
11804: fff58593 addi a1,a1,-1
11808: 0015e593 ori a1,a1,1
1180c: 40b45433 sra s0,s0,a1
Are now a single srai instruction:
117fc: 40145413 srai s0,s0,0x1
Likewise for logical left shift (and logical right shift):
1d560: 01100413 li s0,17
1d564: 04043413 sltiu s0,s0,64
1d568: 40800433 neg s0,s0
1d56c: 01131493 slli s1,t1,0x11
1d570: 0084f433 and s0,s1,s0
Which are now a single slli (or srli) instruction:
1d120: 01131413 slli s0,t1,0x11
This removes more than 30,000 instructions from the Go binary and
should improve performance in a variety of areas - of note
runtime.makemap_small drops from 48 to 36 instructions. Similar
gains exist in at least other parts of runtime and math/bits.
Change-Id: I33f6f3d1fd36d9ff1bda706997162bfe4bb859b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/350689
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Michael Munday <mike.munday@lowrisc.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The test checks that two packages aren't non-test dependencies.
There's a copy-paste typo, however.
When net/http is unexpectedly found as a dependendency,
we instead mention the other package in the error message.
Change-Id: I3232c6252255c839e08efa048f2232c192d0fb85
Reviewed-on: https://go-review.googlesource.com/c/go/+/351372
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Agressively mark all LHS variables in assignments as used if there
is any error in the (entire) assignment. This reduces the number of
spurious "declared but not used" errors in programs that are invalid
in the first place. This behavior is closer to the behavior of the
compiler's original type checker (types1) and lets us remove lines
of the form "_ = variable" just to satisfy test cases. It also makes
more important errors visible by not crowding them out.
Remove the Checker.useLHS function and use Checker.use instead:
useLHS didn't evaluate top-level variables, but we actually want
them to be evaluated in an error scenario so that they are getting
used (and thus we don't get the "declared but not used" error).
Fixes#42937.
Change-Id: Idda460f6b81c66735bf9fd597c54188949bf12b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/351730
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a partial port of CL 351669 from types2 to go/types; it
only copies the fix for variable usage.
Eventually we may want to use the compiler error messages for assignment
errors everywhere, but that doesn't need to happen now.
Change-Id: I62b024b1b29cc27c29d919de3de44f944f6e2b4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/351670
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When used with the compiler, types2 will report assignment error
messages that closely match what the compiler type checker (types1)
produces.
Also, mark lhs variables as used in invalid variable initializations
to avoid a class of follow-on errors.
Fixes#48558.
Change-Id: I92d1de006c66b3a2364bb1bea773a312963afe75
Reviewed-on: https://go-review.googlesource.com/c/go/+/351669
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For architectures without a specialized implementation (e.g. arm),
the generic implementation allocates because it does:
var block = blockGeneric
which causes the compiler to give up trying to analyze block
even though it is technically only ever one implementation.
Instead of a variable, declare a function that wraps blockGeneric.
We apply this fix to md5, sha1, and sha256,
while sha512 already had the equivalent change.
We add a test to all hashing packages to ensure no allocations.
Credit goes to Cuong Manh Le for more specifically identifying
the problem and Keith Randal for suggesting a concrete solution.
Fixes#48055
Change-Id: I1a6a2e028038e051c83fd72b10a8bf4d210df57d
Reviewed-on: https://go-review.googlesource.com/c/go/+/346209
Trust: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
There are some absolute paths in the object file of the packages include C files. The path in C objects file can't be rewritten by linker. The goroot must be used as input for the hash when the packages include C files. So that the debug_info of the binary is correctly.
Fixes#48319
Change-Id: I659a3d6d71c4e49fff83f5bcf53a0a417e552a93
Reviewed-on: https://go-review.googlesource.com/c/go/+/348991
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
Trust: Jay Conrod <jayconrod@google.com>
Break and continue for range loops was accepted as a proposal in June 2017.
It was implemented in CL 66410 (Oct 2017)
but then rolled back in CL 92155 (Feb 2018)
because html/template changes had not been implemented.
This CL reimplements break and continue in text/template
and then adds support for them in html/template as well.
Fixes#20531.
Change-Id: I05330482a976f1c078b4b49c2287bd9031bb7616
Reviewed-on: https://go-review.googlesource.com/c/go/+/321491
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Like other builtin functions, unsafe.Add's len operand is allowed to
be variable sized. However, unlike other builtins, it doesn't get
lowered to a runtime function call, so we never end up coercing it to
a specific type. As a result, we could end up constructing an OpAddPtr
value but with a less-than-ptr-sized addend operand.
This CL fixes this by always coercing the second operand to uintptr
during SSA construction.
Theoretically, we could do this during walk instead, but the frontend
doesn't allow converting negative constants to uintptr.
Fixes#48536.
Change-Id: Ib0619ea79df58b256b250fec967a6d3c8afea631
Reviewed-on: https://go-review.googlesource.com/c/go/+/351592
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Create constant LocalDictName for the pname/refix for dictionary
parameters or local variables, and constant GlobalDictPrefix for the
prefix for names of global dictionaries. I wanted to make sure these
constants were set up as we add more reference to dictionaries for
debugging, etc.
Change-Id: Ide801f842383300a2699c96943ec06decaecc358
Reviewed-on: https://go-review.googlesource.com/c/go/+/351450
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
In go test vet=x, x should be off, all, or one of the analyses supported
by vet. All other flags should not be passed to vet. This CL maintains a
list of supported vet analyzers by running go tool vet -flags and
parsing the flag info to figure out the names of the supported analyzers
and their aliases.
Fixes#47309
Change-Id: I16ade8024301ad4aee5ad45aa92cf63b63dbc2d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/341334
Trust: Zvonimir Pavlinovic <zpavlinovic@google.com>
Run-TryBot: Zvonimir Pavlinovic <zpavlinovic@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Adjust types2 and go/types and some test cases.
Because `any` is not treated specially anymore in constraint
position we get additional errors in constraints if `any` is
used before Go1.18 (in addition to the error that type parameter
lists are not permitted before Go1.18).
Fixes#33232.
Change-Id: I85590c6094b07c3e494fef319e3a38d0217cf6f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/351456
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reduce the number of instructions in the short loop of
ppc64SlicingUpdateBy8 function by combining MOVWZ and SRD into a SRD
with appropriate parameters performing the same operation and remove
MOVWZ R7,R7 from the loop
This change produces the following improvements on POWER9. None of the
other tests regress. Improvments on other POWERPC platforms similar.
name old time/op new time/op
delta
CRC32/poly=IEEE/size=15/align=0 80.5ns ± 0% 70.6ns ± 0%
-12%
CRC32/poly=IEEE/size=15/align=1 80.5ns ± 0% 70.6ns ± 0%
-12%
CRC32/poly=IEEE/size=512/align=1 151ns ± 0% 139ns ± 0%
-7%
CRC32/poly=IEEE/size=1kB/align=1 167ns ± 0% 155ns ± 0%
-7%
CRC32/poly=Castagnoli/size=15/align=0 80.2ns ± 0% 70.5ns ± 0%
-12%
CRC32/poly=Castagnoli/size=15/align=1 80.2ns ± 0% 70.5ns ± 0%
-12%
CRC32/poly=Castagnoli/size=512/align=1 150ns ± 0% 139ns ± 0%
-7%
CRC32/poly=Castagnoli/size=1kB/align=1 166ns ± 0% 155ns ± 0%
-6%
Change-Id: I424709041c30d1c637b595d0845e3ae78dc3e0a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/350989
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is CL 312669, for PPC64.
cgocallback calls cgocallbackg after switching the stack. Call it
indirectly to bypass the linker's nosplit check. The nosplit check
fails after CL 351271, which removes ABI aliases. It would have
been failing before but the linker's nosplit check didn't resolve
ABI alias (it should) so it didn't catch that. Removing the ABI
aliases exposes it. For this partuclar case it is benign as there
is actually a stack switch in between.
Should fix PPC64 build.
Change-Id: I49617aea55270663a9ee4692c54c070c5ab85470
Reviewed-on: https://go-review.googlesource.com/c/go/+/351469
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This adds some initial support for spilling and reloading
registers in the new ABI for PPC64.
- Code has been added to allow argument registers
to be spilled around the morestack call in the prolog.
- Functions for loadRegResult and spillRegArg have been
added and set in the arch config for PPC64.
Change-Id: I4ede3c61468857aaf06f804b5e7c3dd9da9cf36b
Reviewed-on: https://go-review.googlesource.com/c/go/+/351189
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
In the past we introduced ABI aliases, in preparation for ABI
wrappers. Now that we have ABI wrappers implemented, we don't
need ABI aliases. If ABI wrappers are not enabled, ABI0 and
ABIInternal are actually identical, so we can resolve symbol
references without distinguish them. This CL does so by
normalizing ABIInternal to ABI0 at link time. This way, we no
longer need to generate ABI aliases.
This CL doesn't clean up everything related to ABI aliases, which
will be done in followup CLs.
Change-Id: I5b5db43370d29b8ad153078c70a853e3263ae6f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/351271
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Invalid code may produce instances where the number of type arguments
does not match the number of type parameters. Such code will cause an
error, but should not cause a panic when substituting in those invalid
instances.
Fixes#48529
Change-Id: Ie5ff5ace55921540a7224cc5022ef9ff7649361a
Reviewed-on: https://go-review.googlesource.com/c/go/+/351337
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
CL 344909 fixed the bug in the order of passing gcflags from cmd/go to
cmd/compile. In that process, we merged the flags passed by cmd/go and
the flags specified by "-gcflags" to one variable. That causes the
gcBackendConcurrency function fails to detect concurrency level, since
when it expects only the latter flags.
To fix this, just don't merge those two variables, so we can now
correctly detect the concurrency level and passing the right -c to
the compiler.
Fixes#48490
Change-Id: I1293a7d6b946b7fccdd5cd34a38452bf6306e115
Reviewed-on: https://go-review.googlesource.com/c/go/+/351049
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This CL makes a few changes to the new ArgumentError type to be more
idiomatic:
- Use a pointer receiver for methods.
- Export fields, similarly to Error. ArgumentError has a clear meaning
(an error associated with an index), so there is no need to hide its
representation.
- Add an Unwrap method to access the underlying error.
- Say explicitly that the error returned from Instantiate may wrap
*ArgumentError. There is no need to commit to an API that always
returns an error with dynamic type *ArgumentError.
Updates #47916
Change-Id: Ib1a43e921f247794e7155280ccbf5a6775ed3978
Reviewed-on: https://go-review.googlesource.com/c/go/+/351335
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently, GroupIds (a method that returns supplementary group IDs
for a user) is not implemented when cgo is not available, or osusergo
build tag is set, or the underlying OS lacks getgrouplist(3).
This adds a native Go implementation of GroupIds (which parses
/etc/group) for such cases, together with some tests.
This implementation is used:
- when cgo is not available;
- when osusergo build tag is set;
- on AIX (which lacks getgrouplist(3));
- on Illumos (which only recently added getgrouplist(3)).
This commit moves listgroups_unix.go to cgo_listgroups_unix.go, and adds
listgroups_unix.go which implements the feature.
NOTE the +build equivalent of go:build expression in listgroups_unix.go
is not provided as it is going to be bulky. Go 1.17 already prefers
go:build over +build, and no longer fail if a file contains go:build
without +build, so the absence of +build is not a problem even with Go
1.17, and this code is targeted for Go 1.18.
Updates #14709
Updates #30563
Change-Id: Icc95cda97ee3bcb03ef028b16eab7d3faba9ffab
Reviewed-on: https://go-review.googlesource.com/c/go/+/330753
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
We should never use or need methods on non-interface shape types. We do
have corresponding functions instantiated with the appropriate
shape types that take the dictionary and the shape-based receiver as the
first two arguments. Each such function has the same name as what the
corresponding method would be, so it's best not to create the methods
(which would create confusion for import/export). This fixes issue
48414, which happened because of the confusion between these two
functions/methods.
Fixes#48414
Change-Id: I401fbdad791bdb5792617449cad68aa8df1d9911
Reviewed-on: https://go-review.googlesource.com/c/go/+/351114
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is a clean port of CL 351310 from types2 to go/types
with the necessary changes to methodset.go which doesn't
exist in types2.
Change-Id: Ifdac820d3be14c7bfa778b7bca3f6ba58d220b2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/351311
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reading the Func.hasPtrRecv field directly (without consulting a
possibly existing signature) caused some issues in an earlier CL.
The function ptrRecv (in lookup.go) does the right thing but is
not easily discoverable.
Rename ptrRecv to hasPtrRecv and make it a method of Func; rename
Func.hasPtrRecv field to Func.hasPtrRecv_ to avoid name collisions.
Make it clear in field comment that it must not be read through the
hasPtrRecv method.
Change-Id: Ida9856c4789e499538eb34377be781655958fd5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/351310
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The importer tests are exact copies of the corresponding test files in
$GOROOT/src/go/internal/gcimporter/testdata/. With these changes, diff
applied recursively doesn't show any differences anymore among the
existing files between the directories
src/cmd/compile/internal/importer/testdata
src/go/internal/gcimporter/testdata
Change-Id: I1fdd70a3d4d5e55f1fc580892d1d38cabbdab81b
Reviewed-on: https://go-review.googlesource.com/c/go/+/351309
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is an adjusted port of CL 349990 from types2 to go/types:
typeHash remains unexported but is adjusted to not contain blanks.
Change-Id: I37fa826b8a185e3c275ae9bea29a3b0ed386d2c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/351171
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
- Skip test_fuzz_cache and test_fuzz_seed_corpus on 386.
- Skip worker benchmarks when race mode is enabled.
- Stub coverage function on platforms we haven't tested yet. It's
causing package initialization to panic on aix/ppc64.
For #48504
Change-Id: I79318b52b11a33fca66476b5050445d07422ef36
Reviewed-on: https://go-review.googlesource.com/c/go/+/351117
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
This change modifies the way we record instance information. It changes
the Info.Inferred map to use the instantiated *ast.Ident as its key, and
record information for all instances, not just those that were produced
via function type inference. Accordingly, Info.Inferred is renamed to
Info.Instances, and the Inferred type is renamed to Instance, with its
Sig field changed to Type.
This was largely motivated by suggestions from mdempsky on the go/types
API proposal (#47916). In our analysis, always using the *ast.Ident as
key and recording all instances makes the API easier to understand and
use.
Instance.TArgs is also renamed to TypeArgs, consistent with other name
changes.
Updates #47916
Change-Id: Ic25ad0cfd65fee6b05e513843c3866ee7a77cfe3
Reviewed-on: https://go-review.googlesource.com/c/go/+/349629
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL removes 'go help fuzz' but expands the testing package
documentation with much of the same information. It also removes
documentation for the unimplemented -keepfuzzing flag and makes a
number of other clarifications.
Addressing comments in CL 348469.
Updates #46629
Change-Id: I12ab5971c900c2e43f2c2d83c6705e8cd642388b
Reviewed-on: https://go-review.googlesource.com/c/go/+/351113
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Katie Hockman <katie@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
With print, the output all runs together.
Take this opportunity to clean up and label all the fields.
Print pluginpath unilaterally; no reason not to.
Wrap long lines. Remove pointless newline from throw.
Change-Id: I37af15dc8fcb3dbdbc6da8bbea2c0ceaf7b5b889
Reviewed-on: https://go-review.googlesource.com/c/go/+/350734
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Making the builtin and and or functions use short-circuit
evaluation was accepted as a proposal in April 2019,
but we never got around to implementing it. Do that.
Fixes#31103.
Change-Id: Ia43d4a9a6b0ab814f2dd3471ebaca3e7bb1505cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/321490
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Use “or” instead of “and” to describe error behavior.
On error, nearly all Seeker implementations in the Go repo return
0 instead of “the new offset”. (Arguably on error “the new offset”
is the same as the previous offset, but some Seeker implementations
don't have that offset readily available.)
Don't claim that “any positive offsite is legal”.
In practice, most of the Seeker implementations within the Go standard
library do not allow “[s]eeking to any [arbitrary] positive offset”:
some reject all out-of-bounds offsets, and some reject only a subset
that happen to overflow some underlying representation. Since some
positive offsets may be rejected, we cannot claim that seeking to
those offsets “is legal”. However, to avoid invalidating existing
Seeker implemetations we must not require an implementation to reject
invalid positive offsets either.
This is technically a breaking change, since callers of Seek are no
longer allowed to assume that a Seek resulting in an arbitrary
positive offset will succeed. However, since basically none of the
existing implementations actually conformed to the documented behavior
I believe this falls under the “specification errors” exception to the
Go 1 compatibility policy.
Fixes#48316
Change-Id: Ib1b478599b20ad5361bcc97fe8ceb84f74e6d971
Reviewed-on: https://go-review.googlesource.com/c/go/+/349054
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This is a port of CL 349412 from go/types to types2 with
minor adjustments for types2 names, plus CL 350143 (slightly
simplified) to make sure we always get a new signature in
instantiated methods, plus CL 350810 to take care of pointer
receivers. It also contains adjustments to the compiler (provided
by Dan Scales) make it work with the types2 changes.
Change-Id: Ia683a3a8adba3c369701c411d786092f02e77efe
Reviewed-on: https://go-review.googlesource.com/c/go/+/349998
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
about: Request a package be removed from the documentation site (pkg.go.dev)
title: "x/pkgsite: package removal request for [type path here]"
labels: pkgsite
---
<!--
Please answer these questions before submitting your issue. Thanks!
-->
### What is the path of the package that you would like to have removed?
<!---
We can remove packages with a shared path prefix.
For example, a request for "github.com/author" would remove all pkg.go.dev pages with that package path prefix.
--->
### Are you the owner of this package?
<!---
Only the package owners can request to have their packages removed from pkg.go.dev.
--->
### What is the reason that you could not retract this package instead?
<!---
If you would like to have your module removed from pkg.go.dev, we recommend that you retract them, so that they can be removed from the go command and proxy.golang.org as well.
Retracting a module version involves adding a retract directive to your go.mod file and publishing a new version. For example: https://github.com/jba/retract-demo/blob/main/go.mod#L5-L8
See https://pkg.go.dev/about#removing-a-package for additional tips on retractions.
// Copyright 2021 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
packagetar
import(
"bytes"
"io"
"testing"
)
funcFuzzReader(f*testing.F){
b:=bytes.NewBuffer(nil)
w:=NewWriter(b)
inp:=[]byte("Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.")
err:=w.WriteHeader(&Header{
Name:"lorem.txt",
Mode:0600,
Size:int64(len(inp)),
})
iferr!=nil{
f.Fatalf("failed to create writer: %s",err)
}
_,err=w.Write(inp)
iferr!=nil{
f.Fatalf("failed to write file to archive: %s",err)
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.
