The existing implementation ignores module info if there is any error loading the package.
Fixes#44287
Change-Id: I24142e4c7256517292fc654e29d759871b80bc09
GitHub-Last-Rev: 28e9bf85e8
GitHub-Pull-Request: golang/go#45777
Reviewed-on: https://go-review.googlesource.com/c/go/+/313549
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Matloob <matloob@golang.org>
The external linker uses R12. Do the same. We previously use R11,
the temp register in Go ABI. This does not really matter if the
caller is Go code, because all registers are clobbered at call.
But it the caller is C code, it may assume R11 live across a call.
Using R11 may clobber live value. On the callee side, R12 is not
an argument register in both Go and C calling convention.
Change-Id: I958c5dad52aa51bb282a7ad420f5423863e69c14
Reviewed-on: https://go-review.googlesource.com/c/go/+/314454
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>
In external linking mode the external linker may insert
trampolines, which use R12 as a scratch register. So a call could
potentially clobber R12 if the target is laid out too far. Mark
R12 clobbered.
Also, we will use R12 for trampolines in the Go linker as well.
CL 310731 updated the generated rewrite files so imports are
grouped, but the generator was not updated to do so. Grouped
imports are nice. But as those are generated files, for
simplicity and my laziness, just regenerate with the current
generator (which makes imports not grouped).
Change-Id: Iddb741ff7314a291ade5fbffc7d315f555808409
Reviewed-on: https://go-review.googlesource.com/c/go/+/314453
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>
TOOLEXEC_IMPORTPATH is useful for the toolexec program to know what
package is currently being built. This is otherwise tricky to figure out.
Unfortunately, for test packages it was lacking. In the added test case,
we have a total of four packages in 'go list -test':
test/main
test/main.test
test/main [test/main.test]
test/main_test [test/main.test]
And, when running with -toolexec, one would get the following values:
# test/main_test [test/main.test]
compile TOOLEXEC_IMPORTPATH="test/main_test"
# test/main [test/main.test]
compile TOOLEXEC_IMPORTPATH="test/main"
# test/main.test
compile TOOLEXEC_IMPORTPATH="test/main.test"
Note how the " [test/main.test]" suffixes are missing. Because of that,
when one sees TOOLEXEC_IMPORTPATH="test/main", it is ambiguous whether
the regular "test/main" package is meant, or its test variant, otherwise
known as "test/main [test/main.test]" and including foo_test.go
To fix this, we need unambiguous strings to identify the packages
involved, just like one can do with "go list -test". "go list" already
has such a field, ImportPath, which is also used when printing output
from each build "action" as seen above.
That string is not really an import path - internally, it's
load.Package.Desc, and called a "description". However, it makes sense
to be consistent with "go list -json", because it's the source of truth
for practically all tools interacting with the Go toolchain.
To keep cmd/go more consistent, "go list -f {{.ImportPath}}" now calls
Package.Desc as well, instead of having its own copy of the string
concatenation for ForTest.
Fixes#44963.
Change-Id: Ibce7fbb5549209dac50526043c0c7daa0beebc08
Reviewed-on: https://go-review.googlesource.com/c/go/+/313770
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Add support for cgo on openbsd/mips64.
Fixes#43005
Change-Id: I2386204f53fa984a01a9d89f0b6c96455768f326
Reviewed-on: https://go-review.googlesource.com/c/go/+/275896
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The current code lacks a check on whether the register and shift/extension
combination is valid, for example the follow instructions also compiles.
ADD F1<<1, R1, R3
ADD V1<<1, R1, R3
MOVW (R9)(F8.SXTW<<2), R19
VST1 R4.D[1], (R0)
Actually only general registers can perform shift operations, and element
and arrangement extensions are only applicable to vector registers. This
CL adds a check for the register and shift/extension combination on arm64.
Change-Id: I93dd9343e92a66899cba8eaf4e0ac5430e94692b
Reviewed-on: https://go-review.googlesource.com/c/go/+/312571
Trust: eric fang <eric.fang@arm.com>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
The error message of checking whether the offset value of load/store
instruction is out of range is wrong. The right range is [-256, 255], not
[-255, 254]. The CL fixes it.
Change-Id: Ia342957f1f6bcec65eceb45944221d3972641bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/313891
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
In CL 255899, we added code to make clearer error when non-bool used
as operand to logical operators. The code is safe, because node type
is guaranteed to be non-nil.
In CL 279442, we refactored typechecking arith, including moving
typechecking logical operators to separate case. Now we have to
explicitly check if operand type is not nil, because calling Expr can
set operand type nil for non-bool operands.
Fixes#45804
Change-Id: Ie2b6e18f65c0614a803b343f60e78ee1d660bbeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/314209
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>
Functional plugin support requires cgo to be enabled. Disable
it if the environment has disabled cgo.
This prevents unexpected linker failures when linking large
binaries with cgo disabled which use the plugin package.
Fixes#45564
Change-Id: Ib71f0e089f7373b7b3e3cd53da3612291e7bc473
Reviewed-on: https://go-review.googlesource.com/c/go/+/314449
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
This is a port of CL 308370 to go/types. There are some differences in
the index checking code, but the methodology for moving the code was the
same: replace `goto Error` with `x.mode = invalid; return`.
Change-Id: I880f577a7720e6ad8a5b096207001fcf7620396d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312095
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>
According to the code comment, \ should be treated as a path separator.
See fileNameOK in golang.org/x/mod/module/module.go.
Change-Id: I05e05246005191ecccfecf46848aba5cb1359956
Reviewed-on: https://go-review.googlesource.com/c/go/+/310429
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Robert Findley <rfindley@google.com>
Also sleep a bit each time it fails, in case the system is overloaded.
Fixes#37332
Change-Id: Iabf3d0a27b5834c1e2a87c826b6206146b4f62c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/313849
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Ensure that formal parameter Names are correctly copied and marked
with the correct Curfn. We need to ensure this even when the underlying
closure has no type parameters.
(Aside: it is strange that the types of things contain formal
parameter names that need to be copied. Maybe that's an underlying
larger problem that needs to be fixed.)
Fixes#45738
Change-Id: Ia13d69eea992ff7080bd44065115bc52eb624e73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313652
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
For some reason, the go.mod file added to this test in CL 147281 lists
'go 1.20' instead of the version that was actually current when the
go.mod file was added.
That causes the test's behavior to change under lazy loading, because
1.20 is above the threshold to trigger lazy-loading invariants (1.17).
For #36460
Change-Id: I92400996cb051ab30e99bfffafd91ff32a1e7087
Reviewed-on: https://go-review.googlesource.com/c/go/+/314049
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
That way the skip takes effect.
Also ignore the result of calling TIOCSPGRP when cleaing up TestForeground.
It has started to fail for some reason, and the result doesn't matter.
Also call TIOCSPGRP to clean up in TestForegroundSignal.
For #37217
Change-Id: I2e4282d7d91ad9a198eeb12cef01c2214c2a98c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/314271
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Block profiles were biased towards infrequent long events over frequent
short events. This fix corrects the bias by aggregating shorter events
as longer but less frequent in the profiles. As a result their
cumulative duration will be accurately represented in the profile
without skewing their sample mean (duration/count).
Credit to @dvyukov for suggesting to adjust the count in the
saveblockevent function.
Fixes#44192.
Change-Id: I71a99d7f6ebdb2d484d44890a2517863cceb4004
Reviewed-on: https://go-review.googlesource.com/c/go/+/299991
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
If a package declares 'package main' but for some reason we fail to
read its name (for example, due to a permission or checksum error),
we may be tempted to drop the package from the output of
mainPackagesOnly. However, that leads to a confusing
"no packages loaded from …" error message.
Instead, we will treat packages with errors as potentially-main
packages, and print the error. At least if we print why the package is
broken, the user will understand that the weird behavior is due to the
broken package rather than, say, a typo on their part in the command
arguments.
Updates #42088
For #36460
Change-Id: I033c0d28ac7d105d9df3ba5f9327e5c0c2a29954
Reviewed-on: https://go-review.googlesource.com/c/go/+/314050
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>
Go commands show a warning message any time a pattern is expanded and a
symlink to a directory is encountered. For monorepo with non Go projects
using symlinks underneath, the output of go commands could be spammed by
this warning.
This commit includes the behavior change to only print this warning when
there's a pattern containing ... .
Fixes#35941
Change-Id: I094da2628bcd47b86fee8c6529d1066aa013a43b
Reviewed-on: https://go-review.googlesource.com/c/go/+/311890
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Michael Matloob <matloob@golang.org>
ptrace1 must be nosplit because it is called from
forAndExecInChild. It was marked nosplit in the generated code
but not in the generator. CL 313230 regenerated the code and lost
the nosplit mark. This CL restores it.
Change-Id: I4645d83650f1818bed3cb650328bba97074b6b2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314249
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
While profiling parsing, I noticed that scanIdentifier was extremely
hot, and could be optimized: it is responsible for a significant
fraction of scanning and had a lot of unnecessary branching, bounds
checks, and function calls.
This CL implements some of those optimizations, while trying to strike a
balance between optimization and readability. It achieves this by
optimizing for the common case of ASCII identifiers, falling back on the
slower scan when encountering the first non-ASCII character.
Benchmark results:
name old time/op new time/op delta
Scan-12 16.9µs ± 4% 15.8µs ± 5% -6.92% (p=0.000 n=20+18)
ScanFiles/go/types/expr.go-12 793µs ± 4% 672µs ± 6% -15.23% (p=0.000 n=20+20)
ScanFiles/go/parser/parser.go-12 1.08ms ± 6% 0.90ms ± 4% -16.68% (p=0.000 n=20+20)
ScanFiles/net/http/server.go-12 1.44ms ± 4% 1.23ms ± 5% -14.58% (p=0.000 n=18+20)
ScanFiles/go/scanner/errors.go-12 40.7µs ± 2% 32.6µs ± 3% -20.01% (p=0.000 n=19+20)
Change-Id: If78380004248e3ea75cfc78eb7f38f528124dced
Reviewed-on: https://go-review.googlesource.com/c/go/+/308611
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The transform functions (specifically transformArgs, which is used from
transformCall/transformReturn) require that ir.CurFunc is set correctly.
Since transformCall() is used on the call of an instantiated generic
function, we need to set ir.CurFunc correctly in stencil(). Also,
correctly save/restore ir.CurFunc in genericSubst().
Without this fix, ir.CurFunc can be nil when we call TransformCall()
from stencil(), which leads to some temp variables being added
incorrectly to ir.TodoFunc (which leads to the fatal panic in the
issue).
Fixes#45722
Change-Id: Iddf4a67d28f2100dde8cde5dbc9ca1e00dad6089
Reviewed-on: https://go-review.googlesource.com/c/go/+/313869
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Change-Id: Ibce07f8f36f7c64f7022ce656f8efbec5dff3f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/313829
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
BenchmarkScanFile was scanning scanner.go, which makes comparison
difficult for a CL modifying that file. That file is also is not
necessarily representative syntax.
Add a few additional files as subtests to provide a larger variety of
metrics.
Change-Id: Ib78303c2546debd84a0b5478ae438ba891d9e6e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/308610
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>
Change-Id: I73d1b2d18ab4051443d66c60df493d1163d0ba3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/306150
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>
Change-Id: I398d324723025b559fdca783fc334de9be68f2d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/314030
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Currently tiny allocations are not represented in either MemStats or
runtime/metrics, but they're represented in MemStats (indirectly) via
Mallocs. Add them to runtime/metrics by first merging
memstats.tinyallocs into consistentHeapStats (just for simplicity; it's
monotonic so metrics would still be self-consistent if we just read it
atomically) and then adding /gc/heap/tiny/allocs:objects to the list of
supported metrics.
Change-Id: Ie478006ab942a3e877b4a79065ffa43569722f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312909
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Fixes#37217
Change-Id: I0151bb77fc4c4552d1b19c31d784943b72f84b80
Reviewed-on: https://go-review.googlesource.com/c/go/+/313653
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
As an alternative to CL 312149, add a catch-all error message in
exprInternal when encountering a ListExpr, rather than panicking.
We still might want something like CL 312149 to improve the error
message or recovery from bad indexing.
Change-Id: I865f7cc4eefa4a3b7bd8f3100df96d0144e1712f
Reviewed-on: https://go-review.googlesource.com/c/go/+/313909
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When laying out, we lazily increase the alignment for text sections
as symbols are found requiring more. This works if the start of
the virtual address (VA) for the section is greater than or equal
to the alignment required by any symbols placed in this section.
The minimum alignment of the section is only known after all
symbols are placed. The starting VA of this section is adjusted
upwards in ld.(*Link).address to meet the requested alignment.
This is a problem if the starting VA of the text section is not
already aligned. This can happen when the final symbol placed
into the previous section results in an insufficiently aligned
start VA of the next text section.
To workaround this, additional text sections are split, and both
the starting VA, and alignment of the section are aligned up to
match the known worst case alignment.
64B is chosen as the worst case alignment for all ppc64 targets,
as it will respect PCALIGN and eventually prefixed instructions
which will be introduced in the future.
Likewise, the xcoff size calculations need to be improved to
handle padding bytes when function symbols have been aligned.
This is done by tracking the largest valid VA offset encountered
when placing symbols.
Change-Id: Iefef09a1ee7c963fb8dfce2288a084a95cb77fca
Reviewed-on: https://go-review.googlesource.com/c/go/+/307431
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
The code for generating a long constant versus generating an address
(either via a relocation, or known offset) should be handled in the
same place.
Resolve this by classifying memory arguments as C_LACON (a long
address constant) instead of C_LCON (a long constant).
Likewise, reorder AMOVD/AMOVW optab entries to keep similar
classifications near each other. An extra optab entry for
DWORD is also added to continue handling C_LACON arguments
correctly.
Change-Id: I5ce28400492a071f615125a9b8d260826f1600d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/312296
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
While debugging issue #45638, I discovered that some tests were using
--buildmode command line parameter instead of -buildmode.
The --buildmode parameter is handled properly by the flag package - it
is read as -buildmode. But we should correct code anyway.
Updates #45638
Change-Id: I75cf95c7d11dcdf4aeccf568b2dea77bd8942352
Reviewed-on: https://go-review.googlesource.com/c/go/+/313351
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 211139 added TestLibraryCtrlHandler. But the CL left out import "C"
line in the test file that is supposed to be build with Cgo.
While debugging issue #45638, I discovered that the DLL built during
TestLibraryCtrlHandler does not have Dummy function. Adding import "C"
makes Dummy function appear in DLL function list.
TestLibraryCtrlHandler does not actually calls Dummy function. So I
don't see how this change affects issue #45638, but still let's make
this code correct.
Updates #45638
Change-Id: Ibab8fed29ef2ae446d0815842cf0bd040a5fb943
Reviewed-on: https://go-review.googlesource.com/c/go/+/313350
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
It always takes an *ir.Name and would panic given anything else
anyway, so tighten the signature to match.
Change-Id: I44fec5c5cc6d7f0b9c59eb91c9f9633137485360
Reviewed-on: https://go-review.googlesource.com/c/go/+/314009
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>
• Consolidate 'if ld.AllowErrors' conditions into an 'ld.errorf'
method.
• Rename SilenceErrors to SilencePackageErrors and clarify its
documentation. (There is currently no way to silence errors in the
module graph. Perhaps we should add one, but for now let's at least
clarify the existing behavior.)
• Move 'tidy -v' verbose logging into LoadPackages, where other
logging happens.
• Make checkMultiplePaths a loader method (since it only matters
during package loading anyway).
• Check package and module-graph errors in loadFromRoots instead of
LoadPackages. These checks were previously omitted on the
ImportFromFiles path, which seems likely to be a bug. (We now
suppress package errors explicitly in ImportFromFiles, which at
least makes the bug more explicit.)
This somewhat simplifies the code structure in preparation for
the lazy-mode tidy implementation.
For #36460
Change-Id: I3ce3586c6934989d5194f00f99e7cc4423cf767f
Reviewed-on: https://go-review.googlesource.com/c/go/+/313229
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>
For #36460
Change-Id: I40194bb1ebab77459e5c9d43bdac4d9c1b826ac2
Reviewed-on: https://go-review.googlesource.com/c/go/+/312449
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>
As discussion in CL 313289, Name.Defn is also be set for variables
declared in type switch, or name function.
Change-Id: I3deb3d79fca269356e4432b77df7c7720a523674
Reviewed-on: https://go-review.googlesource.com/c/go/+/313889
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
CL 209578 disambiguated paths among imported packages, but as
demonstrated in #43119, formatted types may reference packages that are
not directly imported.
Fix this by recursively walking all imports to determine whether there
is any ambiguity in the import graph. This might result in
over-qualification of names, but it is straightforward and should
eliminate any ambiguity.
In general this should be fine, but might introduce risk of infinite
recursion in the case of an importer bug, or performance problems for
very large import graphs. Mitigate the former by tracking seen packages,
and the latter by only walking the import graph once an error has been
produced.
Fixes#43119
Change-Id: If874f050ad0e808db8e354c2ffc88bc6d64fd277
Reviewed-on: https://go-review.googlesource.com/c/go/+/313035
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
It's not a predeclared type, but a type defined in "unsafe" package.
Fixes#44830
Change-Id: If39815b1070059b608be8231dfac9b7f3307cb15
Reviewed-on: https://go-review.googlesource.com/c/go/+/313349
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>
Android seems to block the accept syscall in newer versions. Use accept4
instead on kernel versions that support it (Linux 2.6.28 and newer) and
fall back to accept on ENOSYS.
Fixes#45767
Change-Id: If190ace0e0213207fdaf6eeb79a5543ef18456de
Reviewed-on: https://go-review.googlesource.com/c/go/+/313769
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Within clovar, n.Defn can also be *ir.TypeSwitchGuard. The proper fix
here would be to populate m.Defn and have it filled in too, but we
already leave it nil in inlvar. So for consistency, this CL does the
same in clovar too.
Eventually inl.go should be rewritten to fully respect IR invariants.
Fixes#45743.
Change-Id: I8b38e5d8b2329ad242de97670f2141f713954d28
Reviewed-on: https://go-review.googlesource.com/c/go/+/313289
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The (*loadPkg).mod field normally indicates the module from which the
package was loaded. However, if the package was missing, we previously
used the mod field to instead store the module from which we intend to
load the package next time around.
That sort of dual use makes the semantics (and synchronization) of the
mod field much more complex to reason about. For example, it would be
nice to have the invariant that the mod field is always one of the
modules in the overall build list, or one of the modules selected in
the overall module graph. Similarly, it would be nice to have the
invariant that the version indicated by the mod field can coexist with
(without upgrading) all of the other versions indicated in the mod
fields of other packages.
This repurposing of the mod field appears to be solely in the service
of storing the module when resolving missing imports. To keep
conceptually-separate fields separate, I have changed
resolveMissingImports to store a slice of package–module pairs,
instead of just packages that need to be revisited.
This may increase allocation pressure slightly if we have many
unresolved packages, but most packages are not unresolved, and it
seems worth the cost to use a little extra memory if it means we can
reason more clearly about the (quite complex) behaviors of the module
loader.
For #36460
Change-Id: Ic434df0f38185c6e9e892c5e9ba9ff53b3efe01f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312930
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.
As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.
Change-Id: I50645af74883e2d5dfcd67a5e8c739222c6f645b
Reviewed-on: https://go-review.googlesource.com/c/go/+/313250
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
