This new TCPConn method returns whether the connection is using MPTCP or
if a fallback to TCP has been done, e.g. because the other peer doesn't
support MPTCP.
When working on the new E2E test linked to MPTCP (#56539), it looks like
the user might need to know such info to be able to do some special
actions (report, stop, etc.). This also improves the test to make sure
MPTCP has been used as expected.
Regarding the implementation, from kernel version 5.16, it is possible
to use:
getsockopt(..., SOL_MPTCP, MPTCP_INFO, ...)
and check if EOPNOTSUPP (IPv4) or ENOPROTOOPT (IPv6) is returned. If it
is, it means a fallback to TCP has been done. See this link for more
details:
https://github.com/multipath-tcp/mptcp_net-next/issues/294
Before v5.16, there is no other simple way, from the userspace, to check
if the created socket did a fallback to TCP. Netlink requests could be
done to try to find more details about a specific socket but that seems
quite a heavy machinery. Instead, only the protocol is checked on older
kernels.
The E2E test has been modified to check that the MPTCP connection didn't
do any fallback to TCP, explicitely validating the two methods
(SO_PROTOCOL and MPTCP_INFO) if it is supported by the host.
This work has been co-developed by Gregory Detal
<gregory.detal@tessares.net> and Benjamin Hesmans
<benjamin.hesmans@tessares.net>.
Fixes#59166
Change-Id: I5a313207146f71c66c349aa8588a2525179dd8b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/471140
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This new function wraps the getsockopt network call with an integer
argument, similar to SetsockoptInt.
This will be used in MPTCP in the following commit.
This work has been co-developed by Gregory Detal
<gregory.detal@tessares.net>.
Updates #59166
Change-Id: I8f6aa00ea2535683d9bbf436993c23e9c6ca2af3
Reviewed-on: https://go-review.googlesource.com/c/go/+/471139
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Ia3174d079e84cf874c2f2f3093a7c6337af32b02
Reviewed-on: https://go-review.googlesource.com/c/go/+/485015
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
A //go:debug line mentioning an unknown or retired setting
should be diagnosed as making the program invalid. Do that.
We agreed on this in the proposal but I forgot to implement it.
Change-Id: Ie69072a1682d4eeb6866c02adbbb426f608567c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/476280
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For proposal #57001, add code to reinvoke a different Go toolchain
based on $GOTOOLCHAIN. The toolchain is searched for in $PATH
first and otherwise downloaded. The download is a standard module
download, so the toolchain is validated using the checksum database
before being executed or even stored in the file system.
Followup CLs will refine the exact toolchain selection and implement
other parts of the proposal. This is only the download+reinvoke code.
For #57001.
Change-Id: I44363cbd916dac01342b1bfce6a487fe7166be4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/475955
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This reverts CL 481061.
Reason for revert: When built with C TSAN, x_cgo_getstackbound triggers
race detection on `g->stacklo` because the synchronization is in Go,
which isn't instrumented.
For #51676.
For #59294.
For #59678.
Change-Id: I38afcda9fcffd6537582a39a5214bc23dc147d47
Reviewed-on: https://go-review.googlesource.com/c/go/+/485275
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This reverts CL 482975.
Reason for revert: CL 481061 causes C TSAN failures and must be
reverted. See CL 485275. This CL depends on CL 481061.
For #59678.
Change-Id: I4599e93d536149bcec94a5a1542533107699514f
Reviewed-on: https://go-review.googlesource.com/c/go/+/485317
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This reverts CL 481075 (a re-apply of previously reverted CL 478917).
Reason for revert: CL 481061 causes C TSAN failures and must be
reverted. See CL 485275. This CL depends on CL 481061.
For #59678.
Change-Id: I4bf7f43d9df1ae28e04cd4065552bcbee82ef13f
Reviewed-on: https://go-review.googlesource.com/c/go/+/485316
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This reverts CL 481795.
Reason for revert: CL 481061 causes C TSAN failures and must be
reverted. See CL 485275. This CL depends on CL 481061.
For #59678.
Change-Id: I5ec1f495154205ebdf19cd44c6e6452a7a3606f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/485315
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This patch generalizes the code in the inliner that marks unreferenced
hidden closure functions as dead. Rather than doing the marking on the
fly (previous approach), this new approach does a single pass at the
end of inlining, which catches more dead functions.
Fixes#59638.
Updates #59404.
Updates #59547.
Change-Id: I54fd63e9e37c9123b08a3e7def7d1989919bba91
Reviewed-on: https://go-review.googlesource.com/c/go/+/484859
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Preparation for reverse type inference where there is no need
to rename all type parameters supplied to type inference when
passing generic functions as arguments to (possibly generic)
function calls.
This also leads to a better separation of concerns.
Change-Id: Id487a5c1340b743519b9053edc43f8aa99408522
Reviewed-on: https://go-review.googlesource.com/c/go/+/484655
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Its docs went stale in Go 1.12 when the build cache became required.
Signed-off-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: Icb7b06dc5147a858f00460e7cfe85b79b6b6f0eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/465555
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
types2 has already done most of the constant folding parts. The only
case left is unsafe.{Alignoff,Offsetof,Sizeof} with variable size
argument, which is handled separately during typecheck.
Change-Id: I8050b7613a16b19b91751726ac07253333177f73
Reviewed-on: https://go-review.googlesource.com/c/go/+/469595
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Match the structure of cycleFinder. Removes a TODO.
Change-Id: Iec0abfc809cd522f64db8900a1f8a70cbba504ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/484615
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Also set GOROOT explicitly in case it is set to something else in the
caller's environment.
Fixes#59598.
Change-Id: I5599ed1183b23187fc3b976786f3c320d42ef4f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/484756
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
The Go arm64 assembler places constants into the text section of a binary.
OpenBSD 7.3 enabled xonly by default on OpenBSD/arm64. This means that any
externally linked Go binary now segfaults. Disable execute-only when invoking
the external linker on openbsd/arm64, in order to work around this issue.
Updates #59615
Change-Id: I1a291293da3c6e4409b21873d066ea15e9bfe280
Reviewed-on: https://go-review.googlesource.com/c/go/+/484555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Aaron Bieber <deftly@gmail.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Than McIntosh <thanm@google.com>
Due to reverse type inference, we may not have an index expression when
type-checking a function instantiation. Fix a panic when the index expr
is nil.
Fixes#59639
Change-Id: Ib5de5e49cdb7b339653e4fb775bf5c5fdb3c6907
Reviewed-on: https://go-review.googlesource.com/c/go/+/484757
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
This adds benchmarks for division and modulus of 64 bit signed and unsigned
integers.
Updates #59089
Change-Id: Ie757c6d74a1f355873e79619eae26ece21a8f23e
Reviewed-on: https://go-review.googlesource.com/c/go/+/482656
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
CL 405094 removed the only caller of markBreak/setHasBreak and
isTermNodes/isTermNode.
importlist variable is only used in old frontend.
Change-Id: I9472f2c0017b6200847999f2cea0e9021a1b14e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/484435
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
The code is using typecheck.ConvNop to convert from untyped int to
uintptr. However, that left the literal node untyped. It often does not
matter, because typecheck.EvalConst will see the OCONVNOP, and replace
the node with a new constant node.
This CL changes the code to construct the constant node directly using
typecheck.DefaultLit, so the last dependecy of typecheck.EvalConst will
go away, next CL can safely remove it from the code base.
Change-Id: Ie5a3d1ff6d3b72be7b8c43170eaa4f6cbb3206fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/484317
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 399694 added constant-fold switch early in compilation. So function:
func f() string {
switch intSize {
case 32:
return "32"
case 64:
return "64"
default:
panic("unreachable")
}
}
will be constant-fold to:
func f() string {
switch intSize {
case 64:
return "64"
}
}
When this function get inlined, there is a check whether we can delay
declaring the result parameter until the "return" statement. For the
original function, we can't delay the result, because there's more than
one return statement. However, the constant-fold one can, because
there's on one return statement in the body now. The result parameter
~R0 ends up declaring inside the switch statement scope.
Now, when walking the switch statement, it's re-written into if-else
statement. Without typecheck.EvalConst, the if condition "if 64 == 64"
is passed as-is to the ssa generation pass. Because "64 == 64" is not a
constant, the ssagen creates normal blocks for branching the results.
This confuses the liveness analysis, because ~R0 is only live inside the
if block. With typecheck.EvalConst, "64 == 64" is evaluated to "true",
so ssagen can branch the result without emitting conditional blocks.
Instead, the constant-fold can be re-written as:
switch {
case true:
// Body
}
So it does not depend on the delay results check during inlining. Adding
a test, which will fail when typecheck.EvalConst is removed, so we can
do the cleanup without breaking things.
Change-Id: I638730bb147140de84260653741431b807ff2f15
Reviewed-on: https://go-review.googlesource.com/c/go/+/484316
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
So future CLs can get rid of EvalConst entirely.
Change-Id: Ic8e147fd76e53c002a6ceda2fb3be979459bf865
Reviewed-on: https://go-review.googlesource.com/c/go/+/484315
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Static init inliner is using typecheck.EvalConst to handle string
concatenation expressions. But static init inliner may reveal constant
expressions after substitution, and the compiler needs to evaluate those
expressions in non-constant semantic. Using typecheck.EvalConst, which
always evaluates expressions in constant semantic, is not the right
choice.
For safety, this CL fold the logic to handle string concatenation to
static init inliner, so there won't be regression in handling constant
expressions in non-constant semantic. And also, future CL can simplify
typecheck.EvalConst logic.
Updates #58293
Updates #58339Fixes#58439
Change-Id: I74068d99c245938e576afe9460cbd2b39677bbff
Reviewed-on: https://go-review.googlesource.com/c/go/+/466277
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
(This is a retry of CL 462035 which was reverted at 474976.
The only change from that CL is the aix fix SRODATA->SNOPTRDATA
at inittask.go:141)
As described here:
https://github.com/golang/go/issues/31636#issuecomment-493271830
"Find the lexically earliest package that is not initialized yet,
but has had all its dependencies initialized, initialize that package,
and repeat."
Simplify the runtime a bit, by just computing the ordering required
in the linker and giving a list to the runtime.
Update #31636Fixes#57411
RELNOTE=yes
Change-Id: I28c09451d6aa677d7394c179d23c2c02c503fc56
Reviewed-on: https://go-review.googlesource.com/c/go/+/478916
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
I noticed that https://go.dev/cl/479401 called both methods MarshalText
in the godoc, so fix that.
While here, add more godoc links for better usability.
Change-Id: I8f10bafeca6a1ca1c1ed9be7a7dd9fdecfe991a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484335
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
For #57001, enforce the go line as declaring the minimum required
version of Go that can compile a module.
Modules that maintain compatibility with old versions of Go
but want to make use of new features in //go:build-constrained files
will be able to do so: the //go:build constraint will be interpreted
as changing the minimum Go version for that file and will unlock
the Go features allowed in that version.
Change-Id: Ibeeb7c93ce7ea2e5187d78af0757cbfac19484a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/476279
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
For #57001, compilers and others tools will need to understand that
a different Go version can be used in different files in a program,
according to the //go:build lines in those files.
Update go/types and cmd/compile/internal/types2 to track and
use per-file Go versions. The two must be updated together because
of the files in go/types that are generated from files in types2.
The effect of the //go:build go1.N line depends on the Go version
declared in the 'go 1.M' line in go.mod. If N > M, the file gets go1.N
semantics when built with a Go 1.N or later toolchain
(when built with an earlier toolchain the //go:build line will keep
the file from being built at all).
If N < M, then in general we want the file to get go1.N semantics
as well, meaning later features are disabled. However, older Go 1.M
did not apply this kind of downgrade, so for compatibility, N < M
only has an effect when M >= 21, meaning when using semantics
from Go 1.21 or later.
For #59033.
Change-Id: I93cf07e6c687d37bd37a9461dc60cc032bafd01d
Reviewed-on: https://go-review.googlesource.com/c/go/+/476278
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
This reverts commit http://go.dev/cl/c/482356.
Reason for revert: Reverting this change again, since it is causing additional failures in google-internal testing.
Change-Id: I9234946f62e5bb18c2f873a65e8b298d04af0809
Reviewed-on: https://go-review.googlesource.com/c/go/+/484735
Reviewed-by: Florian Zenker <floriank@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
"placeholder" (no space) is already used in the spec and seems to be
the preferred option.
Removed space from "place holder".
Change-Id: I9b98f62f0e3f5adb019b99f5271cc9d19abf505e
GitHub-Last-Rev: ed5aaf9d02
GitHub-Pull-Request: golang/go#59626
Reviewed-on: https://go-review.googlesource.com/c/go/+/484576
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
load.TestPackagesAndErrors is given an optional done func() argument.
If set, load.TestPackagesAndErrors will perform part of its work
asynchronously and call done when done. This allows go list to run
testPackagesAndErrors so that the parallelizable parts of
TestPackagesAndErrors run in parallel, making go list -e faster.
Fixes#59157
Change-Id: I11f45bbb3ea4ceda928983bcf9fd41bfdcc4fbd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/484496
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Changes the set of types supported in functions declared with the
go:wasmimport directive to only allow 32 bits and 64 bits integers
and floats, as well as unsafe.Pointer in parameters only. Both the
compiler code and the standard library are updated because the new
restrictions require modifying the use of go:wasmimport in the
syscall and runtime packages.
In preparation of enabling packages outside of the standard library
to use the go:wasmimport directive, the error messages are modified
to carry more context and use ErrorfAt instead of Fatalf to avoid
printing the compiler stack trace when a function with an invalid
signature is encountered.
Fixes#59156
Change-Id: Ied8317f8ead9c28f0297060ac35a5b5255ab49db
Reviewed-on: https://go-review.googlesource.com/c/go/+/483415
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
For #57001, compilers and others tools will need to understand that
a different Go version can be used in different files in a program,
according to the //go:build lines in those files.
Update go/parser to populate the new ast.File.GoVersion field.
This requires running the go/scanner in ParseComments mode
always and then implementing discarding of comments in the
parser instead of the scanner. The same work is done either way,
since the scanner was already preparing the comment result
and then looping. The loop has just moved into go/parser.
Also make the same changes to cmd/compile/internal/syntax,
both because they're necessary and to keep in sync with go/parser.
For #59033.
Change-Id: I7b867f5f9aaaccdca94af146b061d16d9a3fd07f
Reviewed-on: https://go-review.googlesource.com/c/go/+/476277
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Fixes#54948
Change-Id: I467afb940b539b100dcce687b05914a9da7b9ed2
Reviewed-on: https://go-review.googlesource.com/c/go/+/484159
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Valentin Deleplace <deleplace@google.com>
The "double link with slash" test is skipped on darwin due to an
apparent kernel / libc bug. If the bug is present on other platforms
too, I'd like to know about it.
For #59586.
Change-Id: I4bdd6a80a3ed7b0960ea6da30f91a655f317d512
Reviewed-on: https://go-review.googlesource.com/c/go/+/484395
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This reverts commit 4c49d52439.
Reason for revert: it is trickier than expected to enforce an invariant that x.typ == Typ[Invalid] => x.mode == invalid. For example, builtins have invalid type until their call is evaluated.
I think it is better to keep this defensive code for now. My bad for suggesting this strictness. I will send a follow-up CL with a test that exercises the panic discovered inside Google, and a bit more commentary about what 'invalid' means in both contexts.
Fixes#59603
Change-Id: If291f7268e7ef7ae6cd9bb861bb9af349a729cb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/484375
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
This filename was inconsistent with all others.
Change-Id: I5abd3792a96c5137f45d02ac51ffe3d8d05bb164
Reviewed-on: https://go-review.googlesource.com/c/go/+/484415
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
I wrote this code a couple of years back,
and it's unnecessarily verbose for sure.
Change-Id: I684376bf81a995594d90e4faf4deaa2cf51181c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/483296
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
