For #41315
Change-Id: I3989bcb051ae57dd2d8f89759d241d4cdce49659
Reviewed-on: https://go-review.googlesource.com/c/go/+/255969
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>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This flag, like the -e flag to 'go list', instructs the command to
make a best effort to continue in spite of errors for specific packages.
Fixes#26603
Change-Id: I5ee2f50c71870ae8ef3f9b3e5b045474adcca525
Reviewed-on: https://go-review.googlesource.com/c/go/+/255960
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>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This change replaces ImportPaths, ImportPathsQuiet, LoadALL, and
LoadVendor with a single LoadPackages function, with a LoadOpts struct
that more clearly documents the variations in behavior.
It also eliminates the cmd/go/internal/load.ImportPaths function,
which was undocumented and had only one call site (within its own
package).
The modload.LoadTests global variable is subsumed by a field in the
new LoadOpts struct, and is no longer needed for callers that invoke
LoadPackages directly. It has been (temporarily) replaced with a
similar global variable, load.ModResolveTests, which can itself be
converted to an explicit, local argument.
For #37438
For #36460
Updates #40775Fixes#26977
Change-Id: I4fb6086c01b04de829d98875db19cf0118d40f8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/255938
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>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Functions that require holding sched.lock now have an assertion.
A few places with missing locks have been fixed in this CL:
Additionally, locking is added around the call to procresize in
schedinit. This doesn't technically need a lock since the program is
still starting (thus no concurrency) when this is called, but lock held
checking doesn't know that.
Updates #40677
Change-Id: I198d3cbaa727f7088e4d55ba8fa989cf1ee8f9cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/250261
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When lock ranking is enabled, we can now assert that lock preconditions
are met by checking that the caller holds required locks on function
entry.
This change adds the infrastructure to add assertions. Actual assertions
will be added for various locks in subsequent changes.
Some functions are protected by locks that are not directly accessible
in the function. In that case, we can use assertRankHeld to check that
any lock with the rank is held. This is less precise, but it avoids
requiring passing the lock into the functions.
Updates #40677
Change-Id: I843c6874867f975e90a063f087b6e2ffc147877b
Reviewed-on: https://go-review.googlesource.com/c/go/+/245484
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Avoid leaking fd in case fd.Stat() fails in the fall back implementation
of Getwd.
Change-Id: I8656d42e8dbc8893b7159873f173d6bf0d4febe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/256221
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
While at it, make "typekind" awares of "types.Ideal*" types.
Passes toolstash-check.
Change-Id: I092fa8c57ab6b8d9ba0f25d8e1ea44fba48675e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/256438
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The Go 1.16 development cycle has started. This is the 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.
Those versions have already gone through code review, and now they
will undergo additional testing during the development period.
If there are new issues in these dependencies discovered, we have
development period to deal with that. We will do this update once
more at the end of the development cycle, by the code freeze, and
so doing it now will make that update smaller and safer.
Overall, this change will help us build confidence that the
Go 1.16 release and its selected dependencies will be robust.
Also increment the Go language version to 1.16 in standard library
go.mod files.
This change was created with a program from CL 256357 patch set 1
(which updates golang.org/x modules only) and the bundle tool at
CL 255053 patch set 1:
$ updatestd -goroot=$HOME/gotip -branch=master
> go version
go version devel +eda1d40544 Mon Sep 21 16:50:07 2020 +0000 darwin/amd64
> go env GOROOT
/Users/dmitshur/gotip
> go version -m /Users/dmitshur/go/bin/bundle
/Users/dmitshur/go/bin/bundle: go1.15.2
path golang.org/x/tools/cmd/bundle
mod golang.org/x/tools (devel) # CL 255053 PS 1
dep golang.org/x/mod v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
dep golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
updating module cmd in /Users/dmitshur/gotip/src/cmd
skipping github.com/chzyer/logex (out of scope, it's not a golang.org/x dependency)
skipping github.com/chzyer/readline (out of scope, it's not a golang.org/x dependency)
skipping github.com/chzyer/test (out of scope, it's not a golang.org/x dependency)
skipping github.com/google/pprof (out of scope, it's not a golang.org/x dependency)
skipping github.com/ianlancetaylor/demangle (out of scope, it's not a golang.org/x dependency)
skipping github.com/yuin/goldmark (out of scope, it's not a golang.org/x dependency)
skipping rsc.io/pdf (out of scope, it's not a golang.org/x dependency)
> go mod edit -go=1.16
> go get -d golang.org/x/arch@b19915210f009e139b20abfd6a6052c7acc1f445 golang.org/x/crypto@5c72a883971a4325f8c62bf07b6d38c20ea47a6a golang.org/x/mod@ce943fd02449f621243c9ea6e64098e84752b92b golang.org/x/net@62affa334b73ec65ed44a326519ac12c421905e3 golang.org/x/sync@6e8e738ad208923de99951fe0b48239bfd864f28 golang.org/x/sys@af09f7315aff1cbc48fb21d21aa55d67b4f914c5 golang.org/x/text@a8b4671254579a87fadf9f7fa577dc7368e9d009 golang.org/x/tools@d647fc2532668b2b75a92f468487b8085e6ed58b golang.org/x/xerrors@5ec99f83aff198f5fbd629d6c8d8eb38a04218ca
go: golang.org/x/sys af09f7315aff1cbc48fb21d21aa55d67b4f914c5 => v0.0.0-20200918174421-af09f7315aff
go: golang.org/x/text a8b4671254579a87fadf9f7fa577dc7368e9d009 => v0.3.4-0.20200826142016-a8b467125457
go: golang.org/x/tools d647fc2532 => v0.0.0-20200918232735-d647fc253266
go: golang.org/x/net 62affa334b73ec65ed44a326519ac12c421905e3 => v0.0.0-20200904194848-62affa334b73
go: golang.org/x/crypto 5c72a883971a4325f8c62bf07b6d38c20ea47a6a => v0.0.0-20200820211705-5c72a883971a
go: golang.org/x/arch b19915210f009e139b20abfd6a6052c7acc1f445 => v0.0.0-20200826200359-b19915210f00
go: golang.org/x/xerrors 5ec99f83aff198f5fbd629d6c8d8eb38a04218ca => v0.0.0-20200804184101-5ec99f83aff1
> go mod tidy
> go mod vendor
updating module std in /Users/dmitshur/gotip/src
> go mod edit -go=1.16
> go get -d golang.org/x/crypto@5c72a883971a4325f8c62bf07b6d38c20ea47a6a golang.org/x/net@62affa334b73ec65ed44a326519ac12c421905e3 golang.org/x/sys@af09f7315aff1cbc48fb21d21aa55d67b4f914c5 golang.org/x/text@a8b4671254579a87fadf9f7fa577dc7368e9d009 golang.org/x/tools@d647fc2532668b2b75a92f468487b8085e6ed58b
go: golang.org/x/crypto 5c72a883971a4325f8c62bf07b6d38c20ea47a6a => v0.0.0-20200820211705-5c72a883971a
go: golang.org/x/text a8b4671254579a87fadf9f7fa577dc7368e9d009 => v0.3.4-0.20200826142016-a8b467125457
go: golang.org/x/sys af09f7315aff1cbc48fb21d21aa55d67b4f914c5 => v0.0.0-20200918174421-af09f7315aff
go: golang.org/x/tools d647fc2532 => v0.0.0-20200918232735-d647fc253266
> go mod tidy
> go mod vendor
updating bundles in /Users/dmitshur/gotip/src
> go generate -run=bundle std cmd
Other non-golang.org/x module dependencies (pprof and demangle)
still need to be updated in a future CL.
For #36905.
Change-Id: I83a350bf8714ebc249284c0d69abe4941700565e
Reviewed-on: https://go-review.googlesource.com/c/go/+/255860
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Adds deprecation warning for -insecure flag on go get in both modules
and GOPATH mode.
Updates #37519.
Change-Id: Ie2efeeb4a91e6dda92955295969e9715314ae50e
GitHub-Last-Rev: a9ebe21fe0
GitHub-Pull-Request: golang/go#41497
Reviewed-on: https://go-review.googlesource.com/c/go/+/255882
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
For a common pattern of iterating only over top-level compilation units (CU)
Reader.SkipChildren has decode and meterialize all CU subentries just
to skip them, because DW_TAG_compile_unit does not have DW_AT_sibling.
However, CUs have total size encoded before the unit and we already parse them
and know all unit sizes.
Optimize Reader.SkipChildren to use that size when skipping CUs children.
This speeds up iteration over a 1.3GB object file from 7.5s to 0.73s.
Change-Id: I2a8f00955159b4bd13571409f4817805f934cb69
Reviewed-on: https://go-review.googlesource.com/c/go/+/256217
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Than McIntosh <thanm@google.com>
Currently, if make.bash is run with a GOOS or GOARCH that the
bootstrap toolchain doesn't support, it will print an ominous but
harmless warning like:
2020/09/21 09:05:27 unsupported GOARCH arm64
This comes from the invocation of "go version" to get the exact
bootstrap toolchain version.
Since the GOOS and GOARCH don't matter for this purpose, this CL
simply clears them on the invocation of the bootstrap toolchain's "go
version".
Fixes#41525.
Change-Id: I17d44eaafed9999b9fa7dcb9fb100b5fd5e554d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/256297
Trust: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
unlockf is called after the G is put into _Gwaiting, meaning another G
may have readied this one before unlockf is called.
This is implied by the current doc, but add additional notes to call out
this behavior, as it can be quite surprising.
Updates #40641
Change-Id: I60b1ccc6a4dd9ced8ad2aa1f729cb2e973100b59
Reviewed-on: https://go-review.googlesource.com/c/go/+/256058
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>
Currently activeStackChans is set before a goroutine blocks on a channel
operation in an unlockf passed to gopark. The trouble is that the
unlockf is called *after* the G's status is changed, and the G's status
is what is used by a concurrent mark worker (calling suspendG) to
determine that a G has successfully been suspended. In this window
between the status change and unlockf, the mark worker could try to
shrink the G's stack, and in particular observe that activeStackChans is
false. This observation will cause the mark worker to *not* synchronize
with concurrent channel operations when it should, and so updating
pointers in the sudog for the blocked goroutine (which may point to the
goroutine's stack) races with channel operations which may also
manipulate the pointer (read it, dereference it, update it, etc.).
Fix the problem by adding a new atomically-updated flag to the g struct
called parkingOnChan, which is non-zero in the race window above. Then,
in isShrinkStackSafe, check if parkingOnChan is zero. The race is
resolved like so:
* Blocking G sets parkingOnChan, then changes status in gopark.
* Mark worker successfully suspends blocking G.
* If the mark worker observes parkingOnChan is non-zero when checking
isShrinkStackSafe, then it's not safe to shrink (we're in the race
window).
* If the mark worker observes parkingOnChan as zero, then because
the mark worker observed the G status change, it can be sure that
gopark's unlockf completed, and gp.activeStackChans will be correct.
The risk of this change is low, since although it reduces the number of
places that stack shrinking is allowed, the window here is incredibly
small. Essentially, every place that it might crash now is replaced with
no shrink.
This change adds a test, but the race window is so small that it's hard
to trigger without a well-placed sleep in park_m. Also, this change
fixes stackGrowRecursive in proc_test.go to actually allocate a 128-byte
stack frame. It turns out the compiler was destructuring the "pad" field
and only allocating one uint64 on the stack.
Fixes#40641.
Change-Id: I7dfbe7d460f6972b8956116b137bc13bc24464e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/247050
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
In the current implementation, we can observe crashes after calling
debug.SetMaxStack and allocating a stack larger than 4GB since
stackalloc works with 32-bit sizes. To avoid this, we define an upper
limit as the largest feasible point we can grow a stack to and provide a
better error message when we get a stack overflow.
Fixes#41228
Change-Id: I55fb0a824f47ed9fb1fcc2445a4dfd57da9ef8d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/255997
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Keith Randall <khr@golang.org>
Document the way EncodeRune currently handles runes which are
out of range. Also add an example showing that behaviour.
Change-Id: I0f8e7645ae053474ec319085a2bb6d7f73bc137c
Reviewed-on: https://go-review.googlesource.com/c/go/+/255998
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Trust: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Use the const variable Ln2 in math/const.go for function acosh.
Change-Id: I5381d03dd3142c227ae5773ece9be6c8f377615e
Reviewed-on: https://go-review.googlesource.com/c/go/+/232517
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
According to POSIX, there are three formats for TZ variable. When
it refers to timezone file, it should starts with a colon. This commit
removes the colon if it exists, so that it keeps compatible with both
the spec and the old behavior.
Change-Id: I30cfeaea530d24e174de309952338cb1146694a5
GitHub-Last-Rev: 11d83d11ca
GitHub-Pull-Request: golang/go#27570
Reviewed-on: https://go-review.googlesource.com/c/go/+/134217
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>
Change-Id: I61a13f7d6410e4931efaa20307bdf1cc0037afc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/255200
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Change-Id: I2233a6a157ec8feffaefd6a8ee65b1c38778c1cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/255238
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
In the common case (<1KB types), no allocation is required
by reflect.Zero.
Also use memclr instead of memmove in Set when the source
is known to be zero.
Fixes#33136
Change-Id: Ic66871930fbb53328032e587153ebd12995ccf55
Reviewed-on: https://go-review.googlesource.com/c/go/+/192331
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
In CL 231397, we stopped marking symbols' GoType reachable in
general, but not when -linkshared. It was left as a TODO. This CL
addresses it.
The problem was that the type names are mangled in the shared
library, so we need to mangle the name consistently in the
executable as well (regardless of whether the symbol is reachable
or not), so that the GCProg generation code can find the
corresponding symbol from the shared library.
Change-Id: I1040747402929a983ec581109f1681a77893682e
Reviewed-on: https://go-review.googlesource.com/c/go/+/255964
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When we're building a panic that's triggered by a memory fault when
SetPanicOnFault has been called, include an Addr method. This
method reports the address at which the fault occurred.
Fixes#37023
RELNOTE=yes
Change-Id: Idff144587d6b75070fdc861a36efec76f4ec7384
Reviewed-on: https://go-review.googlesource.com/c/go/+/249677
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This is testing for the limited case of zero or one SSA-able results.
One regression is that the later expansion of "Dereference" into
Move into argument slots thwarts the
MOVE A -> B, MOVE B -> C
replaced-by
MOVE A -> B, MOVE A -> C
optimization; the second move is written instead as a Dereference at the
phase where the optimization occurs, and because the target of the
dereference is not visible in the dereference, it's not possible to verify
that A and B or A and C don't overlap in some peculiar way (and for results
fed to args, they can).
Regression is repaired in a later CL by changing when calls are expanded.
Change-Id: Ia0f48a9d483d5a54a99657a24b12b25b8edde55f
Reviewed-on: https://go-review.googlesource.com/c/go/+/242782
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Still needs to generate the calls that will need lowering.
Change-Id: Ifd4e510193441a5e27c462c1f1d704f07bf6dec3
Reviewed-on: https://go-review.googlesource.com/c/go/+/242359
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When we load module retractions from the latest version of a module,
it's possible that the latest version has a different module path than
the version we're loading. This can happen when a module is renamed or
a go.mod file is added for the first time.
We should not report an error in this case. Retractions should still
apply to old aliases of a module.
Fixes#41350
Change-Id: If1bc0b6b2b26fc7023e02fc211aa0cd8eb00796e
Reviewed-on: https://go-review.googlesource.com/c/go/+/255961
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>
The linker prunes methods that are not directly reachable if the
receiver type is never converted to interface. A type can be
converted to interface using reflection through other types.
The linker already takes this into consideration but it missed
the case that the intermediate is a method descriptor. Handle
this case.
Change-Id: I590efc5da163c326db8d43583908a2ef67f65d9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255858
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
defaultlit2 and typecheck use the same logic for getting mixing untyped
type, so move that logic to a function.
This is a followup of CL 255217.
Passes toolstash-check.
Change-Id: Ic0eadb7ed27a2f0f72e2d28fd5438500bf4c79e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/255897
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>
retsigerr was used to create error message for both wrong function
arguments and return arguments, so change its name to sigerr to reflect
that.
While at it, also add documentation for the wrong function arguments
case.
Passes toolstash-check.
Change-Id: I740c717ad38d4afab9e8c20f2e94579c8bca67ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/255240
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 revised test now checks that unsafe-uintptr correctly works for
variadic uintptr parameters too, and the CL corrects the code so this
code compiles again.
The pointers are still not kept alive properly. That will be fixed by
a followup CL. But this CL at least allows programs not affected by
that to build again.
Updates #24991.
Updates #41460.
Change-Id: If4c39167b6055e602213fb7522c4f527c43ebda9
Reviewed-on: https://go-review.googlesource.com/c/go/+/255877
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
reloads
use pushState with updated state and read it on page load,so that state
can survive across reloads.
Change-Id: I6c5e80e9747576245b979a62cb96d231d8f27d57
Reviewed-on: https://go-review.googlesource.com/c/go/+/248687
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bradford Lamson-Scribner <brad.lamson@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
CL 254400 makes typecheck set untyped type correctly. We now have enough
information to check valid operators for a type in typecheck.
Passes toolstash-check.
Change-Id: I01a7606ee6ce9964ec52430d53eaa886442bd17f
Reviewed-on: https://go-review.googlesource.com/c/go/+/255617
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>
When -S=2 is in effect for the compiler/assembler, include symbol ABI
values for defined symbols and relocations. This is intended to help
make it easier to distinguish between a symbol and its ABI wrapper.
Change-Id: Ifbf71372392075f15363b40e882b2132406b7d6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255718
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Change things so that the -S command line option for the assembler
works the same as -S in the compiler, e.g. you can use -S=2 to
get additional detail.
Change-Id: I7bdfba39a98e67c7ae4b93019e171b188bb99a2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255717
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Test this behavior incidentally in a test for ambiguous import errors.
(I rediscovered the error when writing the new test.)
For #32567
Updates #28806
Change-Id: I323f05145734e5cf99818b9f04d65075f7c0f787
Reviewed-on: https://go-review.googlesource.com/c/go/+/255046
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>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Previously, modload imported load, but it mainly just did so in order
to install callbacks to the modload API. This was important during vgo
development, but there's no longer a strong reason to do this. Nothing
modload imports strongly depends on load, so there's little danger of
a dependency cycle.
This change deletes the callbacks in load and instead, makes load call
exported functions in modload directly. In the future, these functions
may have different signatures than their GOPATH counterparts.
Change-Id: Ifde5c3ffebd190b5bd184924ec447d272b936f27
Reviewed-on: https://go-review.googlesource.com/c/go/+/255719
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>
All necessary IFF_* consts are available in the syscall package. Use
them in linkFlags instead of duplicating them.
Change-Id: Ibd2b0f6f39f98bfad2a0c8c55d1eb64167aeee03
Reviewed-on: https://go-review.googlesource.com/c/go/+/255497
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
//go:notinheap
type T int
type U T
We already correctly propagate the notinheap-ness of T to U. But we
have an assertion in the typechecker that if there's no explicit
//go:notinheap associated with U, then report an error. Get rid of
that error so that implicit propagation is allowed.
Adjust the tests so that we make sure that uses of types like U
do correctly report an error when U is used in a context that might
cause a Go heap allocation.
Fixes#41451
Update #40954
Update #41432
Change-Id: I1692bc7cceff21ebb3f557f3748812a40887118d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255637
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Fixes#41447
Change-Id: I4460c1c7962d02c41622a5ea1a3c4bc3714a1873
Reviewed-on: https://go-review.googlesource.com/c/go/+/255477
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>
