Change-Id: Ibf51c0687197c0d791916b21cba7f8408aa5300a
Reviewed-on: https://go-review.googlesource.com/c/go/+/383216
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Kevin Burke <kevin@burke.dev>
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>
GCC 9 warns about a change in the ABI of passing structs with bitfields,
but we don't care.
Fixes#50987
Change-Id: Ica658d04172a42a7be788f94d31a714bb8c4766f
Reviewed-on: https://go-review.googlesource.com/c/go/+/382956
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Trust: Benny Siegert <bsiegert@gmail.com>
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>
Otherwise, the failure mode for these subcommands refers to an empty file path:
go: open : no such file or directory
Fixes#50964
Change-Id: I8776431a294d2b2246d7d147b6059054f31bc255
Reviewed-on: https://go-review.googlesource.com/c/go/+/382246
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>
It has moved to golang.org/x/exp/constraints. Perhaps it will move
back to the standard library in a future release.
For golang/go#45458Fixesgolang/go#50792
Change-Id: I93aa251a7afe7b329a3d3faadc0c5d6388b1f0e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/382460
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
crypto/ecdsa was long overdue a cleanup. Bump the FIPS 186 version, and
make sure we consistently reference that and SEC 1, not the paywalled
ANSI standard.
Change-Id: Idd90bd6c14b334941fdcd829d89b796a60a8b174
Reviewed-on: https://go-review.googlesource.com/c/go/+/352529
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
CL 339669 changed freedefer to not mention every field of _defer,
so no need to call it out in the _defer comment.
Change-Id: Id8b67ba2298685f609bf901b5948fd30666bd6e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/382251
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
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>
Make some small edits for clarification of important concepts.
Change-Id: I1f78f2a59489ac71e3948dc924641540508613ce
GitHub-Last-Rev: 1819140ee6
GitHub-Pull-Request: golang/go#50980
Reviewed-on: https://go-review.googlesource.com/c/go/+/382458
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
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>
For #47694.
For #50912.
For #50937.
Change-Id: I3fae6c8dbbd61a45e669b8fb0c18ac76f2183963
Reviewed-on: https://go-review.googlesource.com/c/go/+/381967
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 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>
We can type-check these fine but the API implications are unclear.
Fixes#50912.
For #50937.
Change-Id: If29bbb4a257ff6a85e3bfcd4755fd8f90c80fb87
Reviewed-on: https://go-review.googlesource.com/c/go/+/382116
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>
For #45713
Change-Id: Ia55a96702b99cccaf5d96c2125ee513700658444
Reviewed-on: https://go-review.googlesource.com/c/go/+/381874
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Michael Matloob <matloob@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>
Change-Id: Ic338788d6410ed0d09ad129811377ee9ce5ed496
Reviewed-on: https://go-review.googlesource.com/c/go/+/367954
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
