The path /bin/bash is not available on all operating systems.
Use /usr/bin/env bash to find the system bash interpreter.
Change-Id: I493e462a8e261b7fbbd3f3c0b1d10e55c5ed783b
Reviewed-on: https://go-review.googlesource.com/c/go/+/463977
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Evan Phoenix <evan@phx.io>
The upgrade to NodeJS 18 introduces various library
updates that mean we can no longer override the global
performance package. Instead, rely on the performance
library provided by the NodeJS runtime.
Fixes#57516
Change-Id: Ic8ed902c696ad154f676e0b74b42efb84f02f8db
Reviewed-on: https://go-review.googlesource.com/c/go/+/463234
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Evan Phoenix <evan@phx.io>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The purpose of building the host toolchain is so that we can use it to
build and test the target configuration.
The host configuration should already be tested separately (with its
own builder), so we do not need to build the parts of that
configuration that are not relevant to the task of building and
testing the target configuration.
Updates #47257.
Change-Id: I814778d2d65b1f2887c9419232b5bfd4068f58af
Reviewed-on: https://go-review.googlesource.com/c/go/+/461676
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Since packages in "std" no longer have install targets, checking them
for staleness is somewhat meaningless: if they are not cached they
will be rebuilt anyway, and without installed archives against which
we can compare them the staleness check will not detect builder skew.
It would still be meaningful to check "cmd" for staleness, but
(especially on sharded VM-based builders) that is a fairly expensive
operation relative to its benefit. If we are really interested in
detecting builder skew and/or build reproducibility, we could instead
add a "misc" test (similar to "misc/reboot", or perhaps even a part of
that test) that verifies that bootstrapped binaries are reproducible.
For #57734.
Updates #47257.
Updates #56896.
Change-Id: I8683ee81aefe8fb59cce9484453df9729bdc587c
Reviewed-on: https://go-review.googlesource.com/c/go/+/452775
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Austin Clements <austin@google.com>
go get golang.org/x/tools@ff9bea528a4d (CL 462817, 2023-01-19)
go mod tidy
go mod vendor
This sets up for using passes/directive in cmd/vet
(that CL will add those actual files, with a new go mod vendor).
Note that it also brings in golang.org/x/sys@17fce3a (CL 463675, 2023-01-26),
to get v0.4.0 with the bug fixed in that CL to keep the build working.
The update of x/sys is in both std and cmd to keep them in sync.
Change-Id: If8528f4667d14e674b986830abd41a7c733a3969
Reviewed-on: https://go-review.googlesource.com/c/go/+/462200
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
PutAbstractFunc doesn't use FnState.Filesym, so it isn't needed, but
more importantly it is misleading. DwarfAbstractFunc is frequently used
on inlined functions from outside the current compilation unit. For
those function, ctxt.fileSymbol returns nil, meaning it probably isn't
safe to use if the original compilation unit could also generate an
abstract func with the correct file symbol.
Change-Id: I0e6c76e41d75ac9ca07e0f775e49d791249e1c5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/458198
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
This test set is a bit hard to follow due to trying to test both
variable and function declaration location information.
Now that we have additional helpers to avoid duplication, it isn't too
much work to split them up into individually more understandable tests.
Change-Id: I619ac82ac3b5d00683e22a4a2064e2a5b15e8ce9
Reviewed-on: https://go-review.googlesource.com/c/go/+/458197
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Many tests build a program just to analyze it with dwtest.Examiner. Add
gobuildAndExamine, a helper that returns Examiner directly to reduce
duplication in these tests.
Many tests also lookup the DIE for a specific subprogram, which includes
several verification steps. Package those up in findSubprogramDIE.
Change-Id: I72202ba289ae8389b682be525ff7e6cfbfc00ff3
Reviewed-on: https://go-review.googlesource.com/c/go/+/458196
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The two crypto modules are both named "asm". If both are included in a
single go.work (e.g., from `go work use -r .` in the repo), builds break
from "module asm appears multiple times in workspace".
Give these modules fully-qualified names to avoid conflicts. While we
are here, also expand the name of two other testdata modules. Those
modules don't currently conflict, but they have vague names at risk of
future conflicts.
Fixes#57769.
Change-Id: I2bd8a505051e92348d49560ec698ed921f2c81be
Reviewed-on: https://go-review.googlesource.com/c/go/+/461896
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
DW_AT_decl_line provides the line number of function declarations (the
line containing the func keyword). This is the equivalent to CL 429638,
but provided via DWARF.
Note that the file of declarations (DW_AT_decl_file) is already provided
for non-inlined functions. It is omitted for inlined functions because
those DWARF subprograms may be generated outside of their source
compilation unit, where referencing the file table is difficult.
Fixes#57308.
Change-Id: I3ad12e1f366c4465c2a588297988a5825ef7efec
Reviewed-on: https://go-review.googlesource.com/c/go/+/458195
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Zeroing requires a non-K0 mask register be specified.
(gcc enforces this when assembling.)
The non-K0 restriction is already handled by the Yknot0 restriction.
But if the mask register is missing altogether, we misassemble the
instruction.
Fixes#57952
Not sure if this is really worth mentioning in the release notes,
but just in case I'll mark it.
RELNOTE=yes
Change-Id: I8f05d3155503f1f16d1b5ab9d67686fe5b64dfea
Reviewed-on: https://go-review.googlesource.com/c/go/+/463229
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Илья Токарь <tocarip@gmail.com>
Reviewed-by: Iskander Sharipov <quasilyte@gmail.com>
CL 463219 broke TestAllDependencies because zsyscall_windows.go
was not correctly formatted, probably edited by hand.
The failure was not catch by the CL builders because it is
only failing on linux longtests builders, which was not executed.
Windows builders skip that test because it lacks of the `diff` command.
Change-Id: Id02992d71be2db7e9d3d169545679ab957f3be7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463841
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL sets the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS notification mode
for all udp and tcp networks.
When SetFileCompletionNotificationModes was implemented, back in
go 1.2 [1], it was not possible to enable this mode on udp connections
because it is buggy on Windows 7 and earlier. The bug was fixed on
Windows 8. We can safely enable this mode now, since go 1.21
will require Windows 10 or higher.
While here, I noticed that this mode is only enabled for tcp, but not
for tcp4 nor tcp6. I don't think this restriction makes sense, so I'm
lifting it.
The performance gains are relevant:
name old time/op new time/op delta
ReadWriteMsgUDPAddrPort-12 13.3µs ± 4% 11.2µs ± 8% -15.90% (p=0.000 n=10+9)
WriteToReadFromUDP-12 14.5µs ±18% 11.4µs ± 4% -21.35% (p=0.000 n=10+9)
WriteToReadFromUDPAddrPort-12 13.4µs ± 3% 11.0µs ± 2% -18.00% (p=0.000 n=10+9)
[1] https://codereview.appspot.com/12409044
Change-Id: Idf41c35898beceac39d21decb47910f7d8ac247b
Reviewed-on: https://go-review.googlesource.com/c/go/+/463839
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
zoneinfo_abbrs hasn't been updated since go 1.14, it's time to
regenerate it.
Updates #58113
Change-Id: Ic156ae607c46f1f5a9408b1fc0b56de6c14a4ed4
Reviewed-on: https://go-review.googlesource.com/c/go/+/463838
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This generates GetTempPath2. Go now tries to determine if the windows it runs on has GetTempPath2 by finding it only once at the loading time. If GetTempPath2 exists, it sets the flag so that any calls to tempDir will use it. If it doesn't exist, Go then uses GetTempPath.
GetTempPath2 was generated into internal/syscall/windows since syscall is locked down.
Fixes#56899
Change-Id: Iff08502aebc787fde802ee9496c070c982fbdc08
GitHub-Last-Rev: b779389534
GitHub-Pull-Request: golang/go#57980
Reviewed-on: https://go-review.googlesource.com/c/go/+/463219
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
On Windows the registry data type REG_EXPAND_SZ indicates that the string requires expansion
of environment variables. The existing implementation doesn't take that into consideration
and just returns the unexpanded string, ignoring the registry type. This implementation ensures
that environment variables are properly expanded when needed.
Fixes#57576
Change-Id: Ia02c1b05a4cf6eaaffb3be88ce1c9ee100db250f
Reviewed-on: https://go-review.googlesource.com/c/go/+/460535
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
ir.VisitFuncsBottomUp returns recursive==true for functions which
call themselves. It also returns any closures inside that function.
We don't want to report the closures as recursive, as they really
aren't. Only the containing function is recursive.
Fixes#54159
Change-Id: I3b4d6710a389ec1d6b250ba8a7065f2e985bdbe1
Reviewed-on: https://go-review.googlesource.com/c/go/+/463233
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
This environment variable appears to never be used; according to
https://cs.opensource.google/search?q=META_BUILDLET_HOST_TYPE&ss=go&ssfr=1
this is the only reference to it in the whole Go project.
Change-Id: I6426a1d9e16441358c0e88daf4358112e659b2a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/463741
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Manually consolidate the remaining ppc64/ppc64le test which
are not so trivial to automatically merge.
The remaining ppc64le tests are limited to cases where load/stores are
merged (this only happens on ppc64le) and the race detector (only
supported on ppc64le).
Change-Id: I1f9c0f3d3ddbb7fbbd8c81fbbd6537394fba63ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/463217
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Use a small python script to consolidate duplicate
ppc64/ppc64le tests into a single ppc64x codegen test.
This makes small assumption that anytime two tests with
for different arch/variant combos exists, those tests
can be combined into a single ppc64x test.
E.x:
// ppc64le: foo
// ppc64le/power9: foo
into
// ppc64x: foo
or
// ppc64: foo
// ppc64le: foo
into
// ppc64x: foo
import glob
import re
files = glob.glob("codegen/*.go")
for file in files:
with open(file) as f:
text = [l for l in f]
i = 0
while i < len(text):
first = re.match("\s*// ?ppc64(le)?(/power[89])?:(.*)", text[i])
if first:
j = i+1
while j < len(text):
second = re.match("\s*// ?ppc64(le)?(/power[89])?:(.*)", text[j])
if not second:
break
if (not first.group(2) or first.group(2) == second.group(2)) and first.group(3) == second.group(3):
text[i] = re.sub(" ?ppc64(le|x)?"," ppc64x",text[i])
text=text[:j] + (text[j+1:])
else:
j += 1
i+=1
with open(file, 'w') as f:
f.write("".join(text))
Change-Id: Ic6b009b54eacaadc5a23db9c5a3bf7331b595821
Reviewed-on: https://go-review.googlesource.com/c/go/+/463220
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Updates #57237
Change-Id: I149c8b7eeac91b87b5810250f96d48ca87135807
Reviewed-on: https://go-review.googlesource.com/c/go/+/463218
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: xie cui <523516579@qq.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
We currently check for at least three different permission bits before
running tests that require root permissions: we look for UID 0, lack
of an LXC container, and lack of a Docker container, and probe a
number of distro-specific files in /proc and /sys.
The sheer number of these checks suggests that we have probably missed
at least one. Per Alan J. Perlis, “If you have a procedure with ten
parameters, you probably missed some.” (And, indeed, we definitely
have: a Debian patch¹ adds one more environment check!)
CL 58170 added some of these container checks, but “decided to go this
way instead of just skipping os.IsPermission errors because many of
those tests were specifically written to check false positive
permission errors.” However, we can't in general distinguish between a
false-positive error and a real one caused by a container: if one is
making a change to the syscall package, they should run the tests with
-v and check for unexpected skips.
Notably:
- TestUnshare already skips itself if the command fails with an error
ending in the string "operation not permitted", which could be caused
by a variety of possible bugs.
- The Unshare tests added in CL 38471 will fail with a permission
error if CLONE_NEWNS is not supported, but it seems to me that if
CLONE_NEWNS is supported — sufficient to start the process! — then
Unmount must also be supported, and the test can at least check that
the two are consistent.
- The AmbientCaps tests should fail to start the subprocess with
EINVAL or similar (not produce bogus output) if the kernel does not
support ambient caps for any reason, which we can then detect.
(If the subprocess fails in the way the test is concerned about, it
will exit with status 2, not fail to start in the first place.)
By executing the system calls and checking for permission errors,
this change exposed an existing bug for AmbientCaps (filed as #57208),
which was detected by the linux-arm-aws builder.
For #57208.
Updates #21379.
Updates #14693.
¹https://sources.debian.org/patches/golang-1.19/1.19.3-1/0006-skip-userns-test-in-schroot-as-well.patch/
Change-Id: I9b167661fa1bb823168c8b50d8bbbf9643e49f76
Reviewed-on: https://go-review.googlesource.com/c/go/+/456375
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Alexander Morozov <lk4d4math@gmail.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
path.Join collapses duplicated '/' tokens, but an HTTP URL
intentionally includes a '://' after the scheme.
This should fix the syntax of the errors seen in
https://build.golang.org/log/a17d0c7b6159ea4dad0a9e5378ab5a36ee30ce44.
Updates #52727.
Change-Id: I6e1773a7eb8b3e7e2b3ca29540c1e94a7cd2d99d
Reviewed-on: https://go-review.googlesource.com/c/go/+/461682
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>
hex.Decode never checks the length of dst and triggers a panic
if there are insufficient bytes in the slice.
There isn't document on what the behavior *should* be in this case.
Two possibilities:
1. Error dst has insufficient space (as done in this change)
2. Reduce the length of the decode to min(dst, src)
Option 1 was chosen because it seems the least surprising or
subtle.
Change-Id: I3bf029e3d928202de716830434285e3c165f26dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/461958
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Benjamin Prosnitz <bprosnitz@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Minor code reorganization: the next version of unify.go doesn't
need this function anymore, so move it where it is still used.
Change-Id: I6744a2361b5dfe2564ec73787a7a110e85ac9f1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/463230
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
The unifier was written such that it was possible to specify
a different set of type parameters (declared by different
generic declarations) for each type x, y being unified,
to allow for what is called "bidirectional unification"
in the documentation (comments).
However, in the current implementation, this mechanism is
not used:
- For function type inference, we only consider the
type parameter list of the generic function (type parameters
that appear in the arguments are considered stand-alone types).
We use type parameter renaming to avoid any problems in case
of recursive generic calls that rely on type inference.
- For constraint type inference, the type parameters for the
types x and y (i.e., the type parameter and its constraint)
are the same and had to be explicitly set to be identical.
This CL removes the ability to set separate type parameter
lists. Instead a single type parameter list is used during
unification and is provided when we initialize a unifier.
As a consequence, we don't need to maintain the separate
tparamsList data structure: since we have a single list
of type parameters we can keep it directly in the unifier.
Adjust all the unifier code accordingly and update comments.
As an aside, remove the `exact` flag from the unifier as it
was never set. However, keep the functionality for now and
use a constant (exactUnification) instead. This makes it
easy to find the respectice code without incurring any cost.
Change-Id: I969ba6dbbed2d65d06ba4e20b97bdc362c806772
Reviewed-on: https://go-review.googlesource.com/c/go/+/463223
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL simplifies and removes some old noding code, which isn't
necessary any more.
Most notably, we no longer need separate posMaps for each noder,
because noders are only used for parsing now. Before we started using
types2, noders were also responsible for constructed (untyped) IR, so
posMaps were necessary to translate syntax.Pos into src.XPos.
Change-Id: Ic761abcd727f5ecefc71b611635a0f5b088c941f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463738
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
To simplify backend analysis, we normalize variadic and method calls:
variadic calls are rewritten with an explicit slice argument, and
method calls are turned into function calls that pass the receiver
argument as the first parameter.
But because we've been supporting multiple frontends, this
normalization was scattered in various later passes. Now that we're
back to just one frontend, we can move the normalization forward into
typecheck (where most other IR normalization already happens).
Change-Id: Idd05ae231fc180ae3dd1664452414f6b6d578962
Reviewed-on: https://go-review.googlesource.com/c/go/+/463737
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
All the Lookup* methods that resolve hostnames eventually call lookupIP
or lookupHost method. When the order is selected to be hostLookupCGO
then lookupHost calls cgoLookupHost which internally calls cgoLookupIP
(the lookupIP directly calls cgoLookupIP).
When we provide a context that is cancelled after cgo call, then the
cgoLookupIP returns completed == false, which caues the
lookupIP/lookupHost to fallback to the go resolver.
This fallback is unnecessary because our context is already cancelled.
The same thing can happen to LookupAddr.
Change-Id: Ifff7716c461f05d954ef43b5205865103558b410
GitHub-Last-Rev: 2ef2023e8c
GitHub-Pull-Request: golang/go#57042
Reviewed-on: https://go-review.googlesource.com/c/go/+/454696
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The user is likely to run other commands that need these libraries
immediately after they are built.
For #57734.
Updates #56889.
Change-Id: I2a1a234e6031d85f017ee692ea1ace8c6e0e7355
Reviewed-on: https://go-review.googlesource.com/c/go/+/452679
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This should help to prevent bugs from unintended use of system tools,
especially the system or bootstrap "go" command.
(Suggested by Austin on CL 452678.)
Updates #31567.
Change-Id: I71809ee30d06eda4b5ff8f90656d4f1a462d35dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/452776
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Unified IR generates uniform IR for "a, b = f()" to be able to insert
implicit conversion expressions, but the result is somewhat more
verbose and trips up the inliner's naive cost metrics.
The hairyVisitor.doNode method was already adjusted to account for
this, but isBigFunc needs the same adjustment.
Fixes#57563.
Change-Id: Ia8d86a6e314ec60190c78f40ace4fb30dadc4413
Reviewed-on: https://go-review.googlesource.com/c/go/+/460395
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also remove existing special cases that transform "go" into
gorootBinGo, because they make debugging and code-reviews more
difficult: log messages that don't include the full path can mask bugs
like #31567, and the reader of the code has to trace through the
various call chains to verify that the correct "go" is being used.
Instead, we can make the use of the correct "go" command plainly
obvious in the code by using one consistent name for it.
(Prior to this CL, we had three different names for it:
gorootBinGo, "go", and cmdGo. Now we have only one.
Updates #31567.
Change-Id: Ia9ff27e5e800c79af5a4e9f2803c9ea5ccafbf35
Reviewed-on: https://go-review.googlesource.com/c/go/+/452678
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Sym.Def used to be used for symbol resolution during the
old (pre-types2) typechecker. But since moving to types2-based IR
construction, we haven't really had a need for Sym.Def to ever refer
to anything but the package-scope definition, because types2 handles
symbol resolution for us.
This CL finally removes the Markdcl/Pushdcl/Popdcl functions that have
been a recurring source of issues in the past.
Change-Id: I2b012a0f17203efdd724ebd1e9314bd128cc2d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/458625
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This CL removes a handful of features that were only needed for the
pre-unified frontends.
In particular, Type.Pkg was a hack for iexport so that
go/types.Var.Pkg could be precisely populated for struct fields and
signature parameters by gcimporter, but it's no longer necessary with
the unified export data format because we now write export data
directly from types2-supplied type descriptors.
Several other features (e.g., OrigType, implicit interfaces, type
parameters on signatures) are no longer relevant to the unified
frontend, because it only uses types1 to represent instantiated
generic types.
Updates #57410.
Change-Id: I84fd1da5e0b65d2ab91d244a7bb593821ee916e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/458622
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
These were used by the nounified frontend for representing
uninstantiated generic types; however, the unified frontend only needs
types1 to represent instantiated types.
Updates #57410.
Change-Id: Iac417fbf2b86f4e08bd7fdd26ae8ed17395ce833
Reviewed-on: https://go-review.googlesource.com/c/go/+/458621
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL removes most of the code specific to the nounified
frontend. To simplify review, it's a strict remove-only CL.
Updates #57410.
Change-Id: Ic3196570aa4286618c1d5e7fd0d0e6601a18195b
Reviewed-on: https://go-review.googlesource.com/c/go/+/458620
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
In the types1 universe under the unified frontend, we never need to
worry about type parameter constraints, so we only see pure
interfaces. However, we might still see interfaces that contain union
types, because of interfaces like "interface{ any | int }" (equivalent
to just "any").
We can handle these without needing to actually represent type unions
within types1 by simply mapping any union to "any".
Updates #57410.
Change-Id: I5e4efcf0339edbb01f4035c54fb6fb1f9ddc0c65
Reviewed-on: https://go-review.googlesource.com/c/go/+/458619
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Before this CL, the comment used the case of a recursive generic
function call as an example for uni-directional unification.
However, such cases are now more generally (and correctly) addressed
through renaming of the type parameters.
Change-Id: I69e94f53418e1fb4ca9431aeb27c639c40d19b09
Reviewed-on: https://go-review.googlesource.com/c/go/+/463735
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Doing this allows updates to swig so it can access slices
and strings in a somewhat less-unsafe way.
Change-Id: If2af8f8cf58d2287569dcd7c7ce09728e20b5ff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/463396
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
