name              old time/op   new time/op   delta
EncodeToString-4   35.5µs ± 7%   33.3µs ± 6%  -6.27%   (p=0.008 n=10+9)
DecodeString-4      120µs ± 7%    113µs ± 8%  -5.88%  (p=0.011 n=10+10)

name              old speed     new speed     delta
EncodeToString-4  231MB/s ± 8%  247MB/s ± 5%  +6.55%   (p=0.008 n=10+9)
DecodeString-4    109MB/s ± 7%  116MB/s ± 8%  +6.27%  (p=0.011 n=10+10)

Change-Id: I60bf962464179e35b1711617adbc45a822eaece5
Reviewed-on: https://go-review.googlesource.com/45876Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I0bbb53cad9a7c464ab1cfca381128f33496813ff
Reviewed-on: https://go-review.googlesource.com/49130Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I3a83c63f4db2e46fd96f373378a429896e93f9d1
Reviewed-on: https://go-review.googlesource.com/48861Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This commit changes sys.Wasm to sys.WASM, as requested on
https://groups.google.com/forum/#!topic/golang-dev/VquDxlhjPkg

Change-Id: I30a208c34576a8bb49b9beb524203d71df8fdf1c
Reviewed-on: https://go-review.googlesource.com/118395Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently these two forms of layout are done in a single pass. This
makes it difficult to compress DWARF sections because that must be
done after relocations are applied, which must happen after virtual
address layout, but we can't layout the file until we've compressed
the DWARF sections.

Fix this by separating the two layout steps. In the process, we can
also unify the copy-pasted code in Link.address to compute file
offsets. Currently, each instance of this is slightly different, but
there's no reason for it to be. For example, we don't perform
PEFILEALIGN alignment on Segrodata or Selreltodata even when HeadType
== Hwindows, but it turns out it doesn't matter whether you do or
don't because these segments simply don't exist on Windows. Hence, in
the unified code path, we do this alignment for all segments.
Likewise, there are two ways of computing Fileoff:
  seg.Vaddr - prev.Vaddr + prev.Fileoff
and
  prev.Fileoff + uint64(Rnd(int64(prev.Filelen), int64(*FlagRound)))
At the moment, these always have the same value, but the latter will
continue to work after we start compressing sections on disk.

Tested by comparing test binaries for all packages in std before and
after this change for GOOS={linux,windows,darwin,plan9}. All binaries
are identical.

For #11799.

Change-Id: If09f28771bb4d78dd392fd58b8d7c9d5f22b0b9f
Reviewed-on: https://go-review.googlesource.com/111682
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Before this CL, if you had GOCACHE=/some/dir, then the cmd/go tests used it.
But if you were relying on the implicit behavior that GOCACHE being empty
meant an appropriate system-specific cache directory, then the cmd/go tests
ran with no cache at all, which makes them about 4X slower.

During all.bash GOCACHE is set to a fresh temporary directory and is therefore
already getting proper caching; this CL mainly helps people running 'go test cmd/go'
by hand.

Change-Id: I7c322ca79b877c1d0a3b448b95d5354fbfcba7f8
Reviewed-on: https://go-review.googlesource.com/118320
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

ARM64 manual says it is "constrained unpredictable" if the src
and dst registers of STLXRB are same, although it doesn't seem
to cause any problem on real hardwares so far. Fix by allocating
a different register to hold the updated value for
AtomicAnd8/Or8. We do this by making the ops returns <val,mem>
like AtomicAdd, although val will not be used elsewhere.

Fixes #25823.

Change-Id: I735b9822f99877b3c7aee67a65e62b7278dc40df
Reviewed-on: https://go-review.googlesource.com/117976
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Wei Xiao <Wei.Xiao@arm.com>

Fixes #25834

Change-Id: I33e58dabfd04b84dfee1a9a3796796b5d19862e7
Reviewed-on: https://go-review.googlesource.com/118295
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The original fix (https://go-review.googlesource.com/c/go/+/35831)
for this issue was incorrect as it reported cycles in cases where
it shouldn't.

Instead, use a different approach: A type cycle containing aliases
is only a cycle if there are no type definitions. As soon as there
is a type definition, alias expansion terminates and there is no
cycle.

Approach: Split sprint_depchain into two non-recursive and more
easily understandable functions (cycleFor and cycleTrace),
and use those instead for cycle reporting. Analyze the cycle
returned by cycleFor before issueing an alias cycle error.

Also: Removed original fix (main.go) which introduced a separate
crash (#23823).

Fixes #18640.
Fixes #23823.
Fixes #24939.

Change-Id: Ic3707a9dec40a71dc928a3e49b4868c5fac3d3b7
Reviewed-on: https://go-review.googlesource.com/118078Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Updates golang/go#23122

Change-Id: I2d6769101cdd580901cb08a3027d787fa438d4bc
Reviewed-on: https://go-review.googlesource.com/117975Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Also:
 - Add extra SystemStack space for darwin/arm64 just
like for darwin/arm.
 - Removed redundant stack alignment; the arm64 hardware enforces
 the 16 byte alignment.
 - Save and restore the g registers at library initialization.
 - Zero g registers since libpreinit can call libc functions
 that in turn use asmcgocall. asmcgocall requires an initialized g.
 - Change asmcgocall to work even if no g is set. The change mimics
 amd64.

Change-Id: I1b8c63b07cfec23b909c0d215b50dc229f8adbc8
Reviewed-on: https://go-review.googlesource.com/117176
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

sigaction, sigprocmask, sigaltstack, and raiseproc.

Fix bug in mstart_stub where we weren't saving callee-saved registers,
so if an m finished the pthread library calling mstart_stub would
sometimes fail.

Update #17490
Update #22805

Change-Id: Ie297ede0997910aa956834e49e85711b90cdfaa7
Reviewed-on: https://go-review.googlesource.com/116875
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Previously, go/doc would only consider functions and slices that
return types of T or any number of pointers to T: *T, **T, etc. This
change expands the definition of a constructor to include functions
that return arrays of a type (or pointer to that type) in its first
return.

With this change, the following return types also classify a function
as a constructor of type T:

[1]T
[1]*T
[1]**T
(and so on)

Fixes #22856.

Change-Id: I37957c5f2d6a7b2ceeb3fbaef359057f2039393d
Reviewed-on: https://go-review.googlesource.com/85355
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Change-Id: I5704a07375fc672ac70c1f4e8df6f4fff760b4bf
Reviewed-on: https://go-review.googlesource.com/118117
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Change-Id: I88855dfa3166e90386c90bf6220be0596dab3c0d
Reviewed-on: https://go-review.googlesource.com/118175Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I67aac387359378cf7aa8f7cafa6557ebf1338baf
Reviewed-on: https://go-review.googlesource.com/118176Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Previously the Transport had good support for 100 Continue responses,
but other 1xx informational responses were returned as-is.

But per https://tools.ietf.org/html/rfc7231#section-6.2:

> A client MUST be able to parse one or more 1xx responses received
> prior to a final response, even if the client does not expect one. A
> user agent MAY ignore unexpected 1xx responses.

We weren't doing that. Instead, we were returning any 1xx that wasn't
100 as the final result.

With this change we instead loop over up to 5 (arbitrary) 1xx
responses until we find the final one, returning an error if there's
more than 5. The limit is just there to guard against malicious
servers and to have _some_ limit.

By default we ignore the 1xx responses, unless the user defines the
new httptrace.ClientTrace.Got1xxResponse hook, which is an expanded
version of the previous ClientTrace.Got100Continue.

Still remaining:

* httputil.ReverseProxy work. (From rfc7231#section-6.2: "A proxy MUST
  forward 1xx responses unless the proxy itself requested the
  generation of the 1xx response."). Which would require:

* Support for an http.Handler to generate 1xx informational responses.

Those can happen later. Fixing the Transport to be resilient to others
using 1xx in the future without negotiation (as is being discussed
with HTTP status 103) is most important for now.

Updates #17739

Change-Id: I55aae8cd978164643fccb9862cd60a230e430486
Reviewed-on: https://go-review.googlesource.com/116855
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

On dragonfly, freebsd and solaris the sendfile syscall does not update
the read position of the source fd. Update it after sendfile so
successive calls start at the correct position.

Fixes #25809

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

Change-Id: I4e339b7c359a7cdb0933f7624ce190086c9c3599
Reviewed-on: https://go-review.googlesource.com/118155Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>

Setting GOROOT is no longer necessary for custom installation as of 1.10 (reference: https://go-review.googlesource.com/c/go/+/42533). Fixes #25002

Change-Id: Ic3980833ac437b7a20b951df33805ad1071a40ce
GitHub-Last-Rev: 156bf6510a21266bfb8397e564635278aa3bb1e5
GitHub-Pull-Request: golang/go#25190
Reviewed-on: https://go-review.googlesource.com/110435Reviewed-by: Ian Lance Taylor <iant@golang.org>

This CL takes advantage of the ability to record vet-specific export data,
added in CL 108558, to save information about observed printf wrappers.
Then calls to those wrappers from other packages can be format-checked.
This found a few real mistakes using previously-unrecognized printf
wrappers in cmd/compile. It will no doubt find real mistakes in external code.

Change-Id: I9c29c92d89bbdc984571a174a96e6054585e9cd4
Reviewed-on: https://go-review.googlesource.com/108559
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

Updates #23445

Change-Id: I4b09073e53b1cf04de698b711fb5fb0d08bc02df
Reviewed-on: https://go-review.googlesource.com/118077Reviewed-by: Ian Lance Taylor <iant@golang.org>

This CL makes it possible for vet to write down notes about one package
and then access those notes later, when analyzing other code importing
that package. This is much like what the compiler does with its own export
data for type-checking, so we call it "vet-export" data or vetx data.

The next CL in the stack makes vet actually use this functionality.

Change-Id: Ic70043ab407dfbfdb3f30eaea7c0e3c8197009cf
Reviewed-on: https://go-review.googlesource.com/108558
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Fixes #25827

Change-Id: I6736c3ac061ca32aac2eb68b01ba53a179d68cf4
Reviewed-on: https://go-review.googlesource.com/118076
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Keep searching for a package that is both findable and importable. The
current code would always guarantee that a package was findable but
exited if it was not importable.

Fixes #25478

Change-Id: I237b7dfafb930cae02538c4a2e4d5ce0c1058478
Reviewed-on: https://go-review.googlesource.com/114295Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

For memmove/memclr using jump tables only reduces overall
function performance for both amd64 and 386.

Benchmarks for 32-bit memclr:

	name            old time/op    new time/op    delta
	Memclr/5-8        8.01ns ± 0%    8.94ns ± 2%  +11.59%  (p=0.000 n=9+9)
	Memclr/16-8       9.05ns ± 0%    9.49ns ± 0%   +4.81%  (p=0.000 n=8+8)
	Memclr/64-8       9.15ns ± 0%    9.49ns ± 0%   +3.76%  (p=0.000 n=9+10)
	Memclr/256-8      16.6ns ± 0%    16.6ns ± 0%     ~     (p=1.140 n=10+9)
	Memclr/4096-8      179ns ± 0%     166ns ± 0%   -7.26%  (p=0.000 n=9+8)
	Memclr/65536-8    3.36µs ± 1%    3.31µs ± 1%   -1.48%  (p=0.000 n=10+9)
	Memclr/1M-8       59.5µs ± 3%    60.5µs ± 2%   +1.67%  (p=0.009 n=10+10)
	Memclr/4M-8        239µs ± 3%     245µs ± 0%   +2.49%  (p=0.004 n=10+8)
	Memclr/8M-8        618µs ± 2%     614µs ± 1%     ~     (p=0.315 n=10+8)
	Memclr/16M-8      1.49ms ± 2%    1.47ms ± 1%   -1.11%  (p=0.029 n=10+10)
	Memclr/64M-8      7.06ms ± 1%    7.05ms ± 0%     ~     (p=0.573 n=10+8)
	[Geo mean]        3.36µs         3.39µs        +1.14%

For less predictable data, like loop iteration dependant sizes,
branch table still shows 2-5% worse results.
It also makes code slightly more complicated.

This CL removes TODO note that directly suggest trying this
optimization out. That encourages people to spend their time
in a quite hopeless endeavour.

The code used to implement branch table used a 32/64-entry table
with pointers to TEXT blocks that implemented every associated
label work. Most last entries point to "loop" code that is
a fallthrough for all other sizes that do not map into specialized
routines. The only inefficiency is extra MOVL/MOVQ required
to fetch table pointer itself as MOVL $sym<>(SB)(AX*4) is not valid
in Go asm (it works in other assemblers):

	TEXT ·memclrNew(SB), NOSPLIT, $0-8
        	MOVL    ptr+0(FP), DI
        	MOVL    n+4(FP), BX
        	// Handle 0 separately.
        	TESTL   BX, BX
        	JEQ     _0
        	LEAL    -1(BX), CX // n-1
        	BSRL    CX, CX
		// AX or X0 zeroed inside every text block.
       		MOVL    $memclrTable<>(SB), AX
        	JMP     (AX)(CX*4)
	_0:
        	RET

Change-Id: I4f706931b8127f85a8439b95834d5c2485a5d1bf
Reviewed-on: https://go-review.googlesource.com/115678
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

CL 115975 changed TestGoExec to check symbol types.
However, this test is failing on Plan 9, because
there is no read-only data segment symbol on Plan 9.

This change fixes TestGoExec to replace the check
of read-only data segment symbol (R) by data segment
symbol (D) on Plan 9.

Fixes #25820.

Change-Id: I7164cd9056fa1dfcd1dc1b0f87653290c14c85fa
Reviewed-on: https://go-review.googlesource.com/118035
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently .DepOnly is set when go list -test is invoked to help
distinguish those packages that matched the command line spec from those
which are dependencies (of test packages). This is also useful when
calling go list -deps for the same reason.

Change-Id: Ifc0e68dad0fd01355928793ef803691dee5f4f29
Reviewed-on: https://go-review.googlesource.com/112755
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

An upcoming change to cmd/go will enable this functionality, which
allows vet to write down information about one package for use by
later invocation of vet that analyze code importing that package.

We've intended to do this for a long time, but the build caching was
necessary to have a decent way to manage the vet-specific export data.

This is also an experiment in building scalable whole-program analyses.
In the long term we'd like to allow other analyses to be invoked this way.

Change-Id: I34e4b70445786b2e8707ff6a0c00947bf1491511
Reviewed-on: https://go-review.googlesource.com/117099
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

This adds the support to enable the race detector for ppc64le.

Added runtime/race_ppc64le.s to manage the calls from Go to the
LLVM tsan functions, mostly converting from the Go ABI to the
PPC64 ABI expected by Clang generated code.

Changed racewalk.go to call racefuncenterfp instead of racefuncenter
on ppc64le to allow the caller pc to be obtained in the asm code
before calling the tsan version.

Changed the set up code for racecallbackthunk so it doesn't use
the autogenerated save and restore of the link register since that
sequence uses registers inconsistent with the normal ppc64 ABI.

Made various changes to recognize that race is supported for
ppc64le.

Ensured that tls_g is updated and accessible from race_linux_ppc64le.s
so that the race ctx can be obtained and passed to tsan functions.

This enables the race tests for ppc64le in cmd/dist/test.go and
increases the timeout when running the benchmarks with the -race
option to avoid timing out.

Updates #24354, #23731

Change-Id: Ib97dc7ac313e6313c836dc7d2fb698f9d8fba3ef
Reviewed-on: https://go-review.googlesource.com/107935
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

"Syntax analysis" sounds more familiar and fits the
item before, which says "lexical analysis".
If there was specific intention to the original wording,
I, as a reader, would like to see it instead of this
confusing wording.

Change-Id: Id32dbf75300a86b21cb9f35e54526184fe5df6cb
Reviewed-on: https://go-review.googlesource.com/117696Reviewed-by: Robert Griesemer <gri@golang.org>

Change-Id: Ifa14557ba834865602c207297ccf0c63e93feb4c
Reviewed-on: https://go-review.googlesource.com/117695
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

It has been a long time since the last time the vendored zoneinfo in
lib/time was updated, and we're well into the freeze. Update it to the
lastest release from IANA.

Updates #22487

Change-Id: Ib9a8eb409554848285fc88363dbb04ed9d6d9eb0
Reviewed-on: https://go-review.googlesource.com/117855Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When using plugins with goroutines calling cgo, we hit a case where
an intermittent SIGSEGV occurs when referencing an address that is based
on r2 (TOC address). When the failure can be generated in gdb, the
contents of r2 is wrong even though the value in the current stack's
slot for r2 is correct. So that means it somehow switched to start
running the code in this function without passing through the beginning
of the function which had the correct value of r2 and stored it there.

It was noted that in runtime.gogo when the state is restored from
gobuf, r2 is not restored from its slot on the stack. Adding the
instruction to restore r2 prevents the SIGSEGV.

This adds a testcase under testplugin which reproduces the problem if
the program is run multiple times. The team who reported this problem
has verified it fixes the issue on their larger, more complex
application.

Fixes #25756

Change-Id: I6028b6f1f8775d5c23f4ebb57ae273330a28eb8f
Reviewed-on: https://go-review.googlesource.com/117515
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Hardware AES support in Go on s390x currently requires ECB, CBC
and CTR modes be available. It also requires that either the
GHASH or GCM facilities are available. The existing checks missed
some of these constraints.

While we're here simplify the cpu package on s390x, moving masking
code out of assembly and into Go code. Also, update SHA-{1,256,512}
implementations to use the cpu package since that is now trivial.

Finally I also added a test for internal/cpu on s390x which loads
/proc/cpuinfo and checks it against the flags set by internal/cpu.

Updates #25822 for changes to vet whitelist.

Change-Id: Iac4183f571643209e027f730989c60a811c928eb
Reviewed-on: https://go-review.googlesource.com/114397
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Skip it like on freebsd until there is proper a fix for #25809

Updates #25809

Change-Id: Id53c433aee75f2a992ab6a8d58d98fd1f8a6c1c6
Reviewed-on: https://go-review.googlesource.com/117698
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Add test for freebsd issue #25809.

This test also fails on my Windows 10 Version 1803.
My hope is that adding new test will break one of our builders.

Updates #25722
Updates #25809

Change-Id: Ia103bc708b8fa3b9af57613acc44893f90b3fa18
Reviewed-on: https://go-review.googlesource.com/117775
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

TOKEN_ALL_ACCESS was changed at some stage by Microsoft.

Updates #25775

Change-Id: I3e18914207a0020b2ebfb99f4e57aa55f9de813b
Reviewed-on: https://go-review.googlesource.com/117635
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Although not part of http://mimesniff.spec.whatwg.org,
for WASM streaming compilation to happen, the response
needs to have the application/wasm MIME type
as mentioned here:
https://webassembly.github.io/spec/web-api/index.html#streaming-modules.

And all current browsers prevent streaming compilation
from happening if this MIME type is not present in the response.

The magic number is mentioned here:
https://webassembly.org/docs/binary-encoding

Since we are already adding WASM support, it makes sense
to support this MIME type.

Change-Id: I8dd7b413a8c438a5c23c29d843b42f6da2a20ba4
Reviewed-on: https://go-review.googlesource.com/113396Reviewed-by: Richard Musiol <neelance@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Users of this field are better off using Result instead.

Fixes #25763.

Change-Id: I4391afa6ed3873107628630adc1d409d77fb3f20
Reviewed-on: https://go-review.googlesource.com/117675Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>