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>
RuneReader is fine with UTF16 or any other character encoding
Fixes#49178
Change-Id: I08a5ac205e095349d451d3b60411eaeebc3aa563
Reviewed-on: https://go-review.googlesource.com/c/go/+/359334
Trust: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
to avoid a crash on a nil pointer as an embedded field.
Fixes#48215
Change-Id: I214faa6e3cf08cdec1c01035e4bbca0900c6a408
Reviewed-on: https://go-review.googlesource.com/c/go/+/357963
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>
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>
Update many generators, also handle files that were not part of the
standard build during 'go fix' in CL 344955.
Fixes#41184.
Change-Id: I1edc684e8101882dcd11f75c6745c266fccfe9e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/359476
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
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>
The upstream cmd/bundle tool does not yet omit it,
and the longtest builders test that the generated
file is not modified.
For #41184.
Change-Id: Ib68f532139ed1436cbaf3a756f300fe60f520cab
Reviewed-on: https://go-review.googlesource.com/c/go/+/359484
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@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>
This was added in CL 339990.
Change-Id: I4b0f97bf1a3926e37a42f77e149dcab3b7b75a63
Reviewed-on: https://go-review.googlesource.com/c/go/+/359255
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 339990 made this test more strict, exposing pre-existing issues on
these OSes. Skip for now until they can be resolved.
Updates #49182
Change-Id: I3ac400dcd21b801bf4ab4eeb630e23b5c66ba563
Reviewed-on: https://go-review.googlesource.com/c/go/+/359254
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a port of CL 357413 to go/types. Some test constraints are also
updated to remove 'interface', to coincide with the corresponding test
data file in types2.
Change-Id: I5248190501c2e4381eb7625f8d4fb269301d6e16
Reviewed-on: https://go-review.googlesource.com/c/go/+/359138
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>
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 port of CL 355871 to go/types.
Change-Id: I2dbc3c625c16b545a271a19606ef34ce04a4a6df
Reviewed-on: https://go-review.googlesource.com/c/go/+/359136
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>
Fixes#49187
Change-Id: I4d8c87af8a709f1b909dd4fae3734d422eb36900
Reviewed-on: https://go-review.googlesource.com/c/go/+/359194
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: Ian Lance Taylor <iant@golang.org>
For #48538.
Change-Id: I258b0c8af5801692ad238e47397dde0b4e3c44c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/359275
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
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>
Now that we permit arbitrary types as constraints, we no longer need them.
For #48424
Change-Id: I15fef26a563988074650cb0801895b002c44148a
Reviewed-on: https://go-review.googlesource.com/c/go/+/359258
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: I032791a3cda1916099b0fd2955dcca4e69763660
Reviewed-on: https://go-review.googlesource.com/c/go/+/357958
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
For #37475
Change-Id: I728b7aeee5c38ec337e9a5b073050c3b0afc720d
Reviewed-on: https://go-review.googlesource.com/c/go/+/357956
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>
Fixes#49110
Change-Id: I32c2cb26cca067a4a676ce4bbc3e51f1e0cdb259
Reviewed-on: https://go-review.googlesource.com/c/go/+/357959
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Reviewed-by: Sebastien Binet <s@sbinet.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For #37475
Change-Id: I09fa1344051088ce37727176d9ec6b38891d1a9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/357955
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
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>
A cgo file with "//export" declarations is not permitted to have function
definitions in the cgo comments.
Fixes#49188
Change-Id: I5c24b62b259871473ee984cea96a0edd7d42d23a
Reviewed-on: https://go-review.googlesource.com/c/go/+/359195
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>
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>
The position computation was needed for type list support.
With that gone, we don't need this code anymore.
Change-Id: I3f36b3d108a1fae9947fd259d4892e0287cb78ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/358701
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 renames the toT converters back to their asT names.
Change-Id: If4bda5a78525f9722f044f5544f400fa8bb6f437
Reviewed-on: https://go-review.googlesource.com/c/go/+/358774
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>
