(*buf).string previously manually searched
through its underlying byte slice until we
encountered a '0'. This change instead uses
bytes.IndexByte that results in a speed up:

$ benchstat before.txt after.txt

name         old time/op    new time/op    delta
BufString-8     257ns ± 1%     174ns ± 1%  -32.37%  (p=0.000 n=9+8)

name         old speed      new speed      delta
BufString-8   495MB/s ± 1%   732MB/s ± 1%  +47.76%  (p=0.000 n=10+8)

name         old alloc/op   new alloc/op   delta
BufString-8      162B ± 0%      162B ± 0%     ~     (all equal)

name         old allocs/op  new allocs/op  delta
BufString-8      3.00 ± 0%      3.00 ± 0%     ~     (all equal)

Change-Id: I7cf241742cc091d5d30d987a168b02d83955b1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/196657
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>

Fixes #34415

Change-Id: I8eaa7606ae01e569a076cf7f3c28dbec2a153001
Reviewed-on: https://go-review.googlesource.com/c/go/+/196578Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

In a position independent executable the data or BSS may be located
close to the end of memory. If it is placed closer than
rootBlockBytes, then the calculations in markrootBlock would overflow,
and the test that ensures that n is not larger than n0 would fail.
This would then cause scanblock to scan data that it shouldn't,
using an effectively random ptrmask, leading to program crashes.

No test because the only way to test it is to build a PIE and convince
the kernel to put the data section near the end of memory, and I don't
know how to do that. Or perhaps we could use a linker script, but that
is painful.

The new code is algebraically identical to the original code, but
avoids the potential overflow of b+rootBlockBytes.

Change-Id: Ieb4e5465174bb762b063d2491caeaa745017345e
Reviewed-on: https://go-review.googlesource.com/c/go/+/195717
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

A precondition of modload.PackageBuildInfo is that its path and deps
arguments correspond to paths that have been loaded successfully with
modload.ImportPaths or one of the Load functions. load.Package.load
should not call PackageBuildInfo if there were any errors resolving
imports.

Fixes #34393

Change-Id: I107514f1c535885330ff266c85d3981b71b31c2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/196520
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Before this change, wasm only used float variables with a size of 64 bit
and applied rounding to 32 bit precision where necessary. This change
adds proper 32 bit float variables.

Reduces the size of pkg/js_wasm by 254 bytes.

Change-Id: Ieabe846a8cb283d66def3cdf11e2523b3b31f345
Reviewed-on: https://go-review.googlesource.com/c/go/+/195117Reviewed-by: Cherry Zhang <cherryyz@google.com>

This consolidates the construction of 'ambiguous import' errors to a
single location, ensuring consistency, and lays the groundwork for
automatic resolution in the future.

While we're at it, change "found" to "found package" to try to make
the cause of the error clearer.

Updates #32128
Updates #27899

Change-Id: I14a93593320e5c60d20b0eb686d0d5355763c30c
Reviewed-on: https://go-review.googlesource.com/c/go/+/196298
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

This test is failing in the builders due to the deployed versions of
gccgo not supporting module mode. However, the bug reproduced in
GOPATH mode too, so that mode should be fine for a regression test.

Updates #34358

Change-Id: I954132a96849e80e8783d4de10389fcab7b14af2
Reviewed-on: https://go-review.googlesource.com/c/go/+/196518
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

Follow-up CL removing a TODO.

Change-Id: If900d2f999f6a3e2f2ead29283375547e03cac86
Reviewed-on: https://go-review.googlesource.com/c/go/+/196337Reviewed-by: Alan Donovan <adonovan@google.com>

Couple of changes to the linker's dwarf test, including:

 - add some code to the DWARF tests inlining coverage to verify the
   call_file attribute attached to inlined routine DIEs. If function
   main.F is inlined into function main.G, we want to see that the
   call_file attribute in the inlined routine DIE for main.F is the
   same file as that reported for main.G.

 - fix a glitch with the way the DW_AT_decl_file attribute was
   being checked. The previous code relied on hard-coded indices
   into the line table files table, which is very brittle (since
   there is no requirement that files be ordered in any specific
   way). Instead, add machinery to look up the actual file string
   via the line table reader.

Change-Id: I44e71c69b6e676238cf4b805e7170de17b50939f
Reviewed-on: https://go-review.googlesource.com/c/go/+/196517
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>

The mime and strconv packages already have a const with this name & value.

Change-Id: Ibd7837f854ac8ec3f57943a9d1db07f4cf6db858
GitHub-Last-Rev: 775cdce3b75350aa3b9a6f31f04cfdd0033e9ac3
GitHub-Pull-Request: golang/go#34389
Reviewed-on: https://go-review.googlesource.com/c/go/+/196437Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

modload.MinReqs was passing modload.buildList to mvs.Reqs explicitly,
apparently as an optimization. However, we do not always have the
invariant that modload.buildList is complete: in particular, 'go mod
tidy' begins by reducing modload.buildList to only the set of modules
that provide packages to the build, which may be substantially smaller
than the final build list.

Other operations, such as 'go mod graph', do not load the entire
import graph, and therefore call Reqs with the unreduced build list.

Since Reqs retains modules according to a post-order traversal of the
list, an incomplete list may produce a different traversal order — and
therefore a different minimal solution, when multiple minimal
solutions exist. That caused 'go mod tidy' to produce different output
from other 'go' subcommands when certain patterns of dependencies are
present.

Since passing in the build list is only an optimization anyway, remove
the parameter and recompute the actual (complete) list at the
beginning of mvs.Reqs itself. That way, it is guaranteed to be
complete and in canonical order.

Fixes #34086

Change-Id: I3101bb81a1853c4a5e773010da3e44d2d90a570c
Reviewed-on: https://go-review.googlesource.com/c/go/+/193397
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

TestAmbientCapsUserns also needs to be skipped, e.g. in case the test is
run inside a chroot.

Updates #34015

Change-Id: I53913432fe9408217edfe64619adbfd911a51a7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/196500
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Windows type PBOOL is a pointer to a 4 byte value, where 0 means false
and not-0 means true. That means we should use uint32 here, not bool,
since Go bools can be 1 byte. Since a *bool is never a "real" valid
Windows type, converting on both in and out is probably sufficient,
since *bool shouldn't ever be used as something with significance for
its particular address.

Updates: #34364
Change-Id: I4c1b91cd9a39d91e23dae6f894b9a49f7fba2c0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/196122
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Currently there is no way for go doc to output a clean
one-line symbol representation of types, functions, vars
and consts without documentation lines or other text lines
added.

For example `go doc fmt` has a huge introduction so if you
pass that to grep or fzf to search a symbol let say scan
`go doc fmt | grep scan` you get way to many false
positives.

Added a `-short` flag to be able to do
`go doc -short fmt | grep scan` instead which will result in
just the symbols you are looking for.

func Fscan(r io.Reader, a ...interface{}) (n int, err error)
func Fscanf(r io.Reader, format string, a ...interface{}) (n int, err error)
func Fscanln(r io.Reader, a ...interface{}) (n int, err error)
func Sscan(str string, a ...interface{}) (n int, err error)
func Sscanf(str string, format string, a ...interface{}) (n int, err error)
func Sscanln(str string, a ...interface{}) (n int, err error)


Fixes #32597

Change-Id: I77a73838adc512c8d1490f5a82075de6b0462a31
Reviewed-on: https://go-review.googlesource.com/c/go/+/184017
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

This was in response to a post-merge review comment in
golang.org/cl/185537

Change-Id: I866b3882c8e83bf1fef60115cff5d1c6a9863f09
Reviewed-on: https://go-review.googlesource.com/c/go/+/186319Reviewed-by: Andrew Bonventre <andybons@golang.org>

When walking filesystem paths to locate packages, we normally prune
out subdirectories with names beginning with ".", "_", or equal to
"testdata". However, we should not prune out such a directory if it is
at or above the module root, since its name is not part of the package
path.

Fixes #28481
Updates #27852

Change-Id: Ice82b1f908afaab50f5592f6c38ca6a0fe911edf
Reviewed-on: https://go-review.googlesource.com/c/go/+/196297
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I1ab0b5f713581b5f497878f222fa4ba3998a0ccd
Reviewed-on: https://go-review.googlesource.com/c/go/+/196179Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The current msanwrite() segfaults during libpreinit
when built with -msan on arm64. The cause is msancall()
in runtime/msan_arm64.s called by msanwrite() assumes
that it is always called with a valid g, leading to a
segfult.

This CL adds a check for nil g in msancall().

Fixes #34338

Change-Id: If4ad7e37556cd1d99346c1a7b4852651d1e4e4aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/196157Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #34358

Change-Id: I3022ac88e1ad595dc72c0063852b8d4a1ec3f0ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/196120
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Since I first started on this CL, most of the methods have had examples
added by other folks, so this is now one new example, and additions to
two existing examples for extra clarity.

The issue has a comment about not necessarily having examples for all
methods, but I recall finding this package pretty confusing when I first
used it, and having concrete examples would have really helped me
navigate all the different options. There are more
String methods with examples now, but I think seeing how the byte-slice
methods work could also be helpful to explain the differences.

Updates #21450

Change-Id: I27b4eeb634fb8ab59f791c0961cce79a67889826
Reviewed-on: https://go-review.googlesource.com/c/go/+/120145Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently, if you call various reflect methods you might get a panic with a
message like, "reflect: Field of non-struct type". Sometimes it's easy to
grok what's going on, but other times you need to laboriously go perform
reflect.ValueOf(myType).Kind().

This CL just adds that detail to the error message, saving debuggers the
extra step and making the error message more clear.

Change-Id: I7e0c211a3001e6b217b828cbcf50518080b5cb1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/183097Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

'go tool trace' pointed at an obvious inefficiency; roughly the first
fifth of the program's life was CPU-heavy and making use of only one CPU
core at a time.

This was due to genOp being run before genLower. We did make genLower
use goroutines to parallelize the work between architectures, but we
didn't make genOp run in parallel too.

Do that. To avoid having two layers of goroutines, simply fire off all
goroutines from the main function, and inline genLower, since it now
becomes just two lines of code.

Overall, this shaves another ~300ms from 'go run *.go' on my laptop.

	name     old time/op         new time/op         delta
	Rulegen          2.04s ± 2%          1.76s ± 2%  -13.93%  (p=0.008 n=5+5)

	name     old user-time/op    new user-time/op    delta
	Rulegen          9.04s ± 1%          9.25s ± 1%   +2.37%  (p=0.008 n=5+5)

	name     old sys-time/op     new sys-time/op     delta
	Rulegen          235ms ±14%          245ms ±16%     ~     (p=0.690 n=5+5)

	name     old peak-RSS-bytes  new peak-RSS-bytes  delta
	Rulegen          179MB ± 1%          190MB ± 2%   +6.21%  (p=0.008 n=5+5)

Change-Id: I057e074c592afe06c831b03ca447fba12005e6f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/196177
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #33185

Change-Id: I0adcffa5d1c9e55ae52309c59f961b0710166098
Reviewed-on: https://go-review.googlesource.com/c/go/+/187921Reviewed-by: Sameer Ajmani <sameer@golang.org>
Run-TryBot: Sameer Ajmani <sameer@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently, the line table reader keeps the file name table internal.
However, there are various attributes like AttrDeclFile and
AttrCallFile whose value is an index into this table. Hence, in order
to interpret these attributes, we need access to the file name table.

This CL adds a method to LineReader that exposes the file table of the
current compilation unit in order to allow consumers to interpret
attributes that index into this table.

Change-Id: I6b64b815f23b3b0695036ddabe1a67c3954867dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/192699
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently, dwarf.Reader exposes the current compilation unit's address
size, but doesn't expose its byte order. Both are important for
decoding many attributes. For example, location descriptions include
addresses that are encoded in native form for the CU.

This CL exposes the byte order of the compilation unit in the same way
we already expose its address size, which makes it possible to decode
attributes containing native addresses.

Change-Id: I92f156818fe92b049d1dfc1613816bb1689cfadf
Reviewed-on: https://go-review.googlesource.com/c/go/+/192698
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

CL 140357 caused HTTP/2 connections to be put in the idle pool, but
failed to properly guard the trace.GotConn call in getConn. dialConn
returns a minimal persistConn with conn == nil for HTTP/2 connections.
This persistConn was then returned from queueForIdleConn and caused the
httptrace.GotConnInfo passed into GotConn to have a nil Conn field.

HTTP/2 connections call GotConn themselves so leave it for HTTP/2 to call
GotConn as is done directly below.

Fixes #34282

Change-Id: If54bfaf6edb14f5391463f908efbef5bb8a5d78e
GitHub-Last-Rev: 2b7d66a1ce66b4424c4d0fca2b8e8b547d874136
GitHub-Pull-Request: golang/go#34283
Reviewed-on: https://go-review.googlesource.com/c/go/+/195237Reviewed-by: Michael Fraenkel <michael.fraenkel@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fix bug in previous CL 171768 -- with Go 1.13 the proper entry point
to call is runtime.setmodinfo, not runtime..z2fdebug.setmodinfo (this
changed when we moved from 1.12). [ Unclear why trybots and runs of
all.bash didn't catch this, but hand testing made it apparent. ]

Updates #30344.

Change-Id: I91f47bd0c279ad2d84875051be582818b13735b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/196237
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

I noticed lots of trailing whitespace in one of cmd/trace's HTML files.
While at it, remove a few others from still-maintained files. Leave old
documents alone, such as doc/devel/weekly.html.

Change-Id: I7de7bbb6dd3fe6403bbb1f1178a8d3640c1e537b
Reviewed-on: https://go-review.googlesource.com/c/go/+/196178
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

RELNOTE=This change adds an underscore to all Go symbols in darwin, and
the behavior might be confusing to users of tools like "nm", etc.

Fixes #33808

Change-Id: I1849e6618c81215cb9bfa62b678f6f389cd009d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/196217
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Use a different recipe for capturing debug modinfo if we're compiling
with the gccgo toolchain, to avoid applying a go:linkname directive to
a variable (not supported by gccgo).

Fixes #30344.

Change-Id: I9ce3d42c3bbb809fd68b140f56f9bbe3406c351b
Reviewed-on: https://go-review.googlesource.com/c/go/+/171768Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This cleans up the isel code generation in ssa for ppc64x.

Current there is no isel op and the isel code is only
generated from pseudo ops in ppc64/ssa.go, and only using
operands with values 0 or 1. When the isel is generated,
there is always a load of 1 into the temp register before it.

This change implements the isel op so it can be used in PPC64.rules,
and can recognize operand values other than 0 or 1. This also
eliminates the forced load of 1, so it will be loaded only if
needed.

This will make the isel code generation consistent with other ops,
and allow future rule changes that can take advantage of having
a more general purpose isel rule.

Change-Id: I363e1dbd3f7f5dfecb53187ad51cce409a8d1f8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/195057
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>

Fixes #32162

Change-Id: I164665108fa8ae299229054bded82cb3b027bccb
Reviewed-on: https://go-review.googlesource.com/c/go/+/196023
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #34015

Change-Id: I29798fb9c72b6f4bee8aecea96ab13b4cba2e80d
Reviewed-on: https://go-review.googlesource.com/c/go/+/195738
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When compiling expression switches, we try to optimize runs of
constants into binary searches. The ordering used isn't visible to the
application, so it's unimportant as long as we're consistent between
sorting and searching.

For strings, it's much cheaper to compare string lengths than strings
themselves, so instead of ordering strings by "si <= sj", we currently
order them by "len(si) < len(sj) || len(si) == len(sj) && si <= sj"
(i.e., the lexicographical ordering on the 2-tuple (len(s), s)).

However, it's also somewhat cheaper to compare strings for equality
(i.e., ==) than for ordering (i.e., <=). And if there were two or
three string constants of the same length in a switch statement, we
might unnecessarily emit ordering comparisons.

For example, given:

    switch s {
    case "", "1", "2", "3": // ordered by length then content
        goto L
    }

we currently compile this as:

    if len(s) < 1 || len(s) == 1 && s <= "1" {
        if s == "" { goto L }
        else if s == "1" { goto L }
    } else {
        if s == "2" { goto L }
        else if s == "3" { goto L }
    }

This CL switches to using a 2-level binary search---first on len(s),
then on s itself---so that string ordering comparisons are only needed
when there are 4 or more strings of the same length. (4 being the
cut-off for when using binary search is actually worthwhile.)

So the above switch instead now compiles to:

    if len(s) == 0 {
        if s == "" { goto L }
    } else if len(s) == 1 {
        if s == "1" { goto L }
        else if s == "2" { goto L }
        else if s == "3" { goto L }
    }

which is better optimized by walk and SSA. (Notably, because there are
only two distinct lengths and no more than three strings of any
particular length, this example ends up falling back to simply using
linear search.)

Test case by khr@ from CL 195138.

Fixes #33934.

Change-Id: I8eeebcaf7e26343223be5f443d6a97a0daf84f07
Reviewed-on: https://go-review.googlesource.com/c/go/+/195340
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Fixes #34343.

Change-Id: I74240c8f431f6596338633a86a7a5ee1fce70a65
Reviewed-on: https://go-review.googlesource.com/c/go/+/196057
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Remove redundant code and improve documentation in the process.

Fixes #34211.

Change-Id: I9a6d1467f1a2c98a163f41f9df147fc6500c6fad
Reviewed-on: https://go-review.googlesource.com/c/go/+/196077Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: Ic33dfccf06681470bec19f66653fda67d9901095
Reviewed-on: https://go-review.googlesource.com/c/go/+/196118Reviewed-by: Keith Randall <khr@golang.org>

We used to use OXCASE to represent general, possibly multi-valued
cases, and then desugar these during walk into single-value cases
represented by OCASE.

In CL 194660, we switched to eliminated the desugaring step and
instead handle the multi-valued cases directly, which eliminates the
need for an OCASE Op. Instead, we can simply remove OCASE, and rename
OXCASE to just OCASE.

Passes toolstash-check.

Change-Id: I3cc184340f9081d37453927cca1c059267fdbc12
Reviewed-on: https://go-review.googlesource.com/c/go/+/196117Reviewed-by: Keith Randall <khr@golang.org>

When emitting base cases, previously we would emit:

    if c1 { s1 }
    if c2 { s2 }
    if c3 { s3 }

With this CL, we instead emit:

    if c1 { s1 }
    else if c2 { s2 }
    else if c3 { s3 }

Most of the time, this doesn't make a difference, because s1/s2/s3 are
typically "goto" statements. But for type switches, we currently emit:

    if hash == 271 { if _, ok := iface.(T1); ok { goto t1case } }
    if hash == 314 { if _, ok := iface.(T2); ok { goto t2case } }

That is, the if bodies can fallthrough, even though it's impossible
for them to match any of the subsequent cases.

Change-Id: I453d424d0b5e40060a703738bbb374523f1c403c
Reviewed-on: https://go-review.googlesource.com/c/go/+/195339
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Complete interfaces before comparing them with Checker.identical.
This requires passing through a *Checker to various functions that
didn't need this before.

Verified that none of the exported API entry points for interfaces
that rely on completed interfaces are used internally except for
Interface.Empty. Verified that interfaces are complete before
calling Empty on them, and added a dynamic check in the exported
functions.

Unfortunately, this fix exposed another problem with an esoteric
test case (#33656) which we need to reopen.

Fixes #34151.
Updates #33656.

Change-Id: I4e14bae3df74a2c21b565c24fdd07135f22e11c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/195837
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>