Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

misc/wasm: Microsoft Edge 18 (latest) crashes due to TextEncoder not being supported #27295

Closed
silbinarywolf opened this issue Aug 28, 2018 · 9 comments
Labels
arch-wasm WebAssembly issues FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@silbinarywolf
Copy link
Contributor

silbinarywolf commented Aug 28, 2018

What version of Go are you using (go version)?

go version go1.11 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Jake\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=D:\GoProjects
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Jake\AppData\Local\Temp\go-build055571426=/tmp/go-build -gno-record-gcc-switches

What did you do?

I attempted to run a simple "hello world" WASM application on Microsoft Edge.

package main

import "fmt"

func main() {
	panic("Hello world")
}

What did you expect to see?

I expected that when I pressed F12 and opened the Developer Tools, there would be "Hello world" printed in the console logs with panic information, like in Google Chrome.

Console was cleared
wasm_exec.js:45 panic: Hello world
wasm_exec.js:45 
wasm_exec.js:45 goroutine 1 [running]:
wasm_exec.js:45 main.main()
wasm_exec.js:45 	D:/GoProjects/src/github.com/silbinarywolf/wasm-test/main.go:4 +0x2
wasm_exec.js:67 exit code: 2
exit @ wasm_exec.js:67
runtime.wasmExit @ wasm_exec.js:185
runtime.wasmExit @ wasm-004f446a-782:4
runtime.exit @ wasm-004f446a-771:3
runtime.fatalpanic.func2 @ wasm-004f446a-706:47
runtime.systemstack @ wasm-004f446a-727:100
runtime.fatalpanic @ wasm-004f446a-380:151
runtime.gopanic @ wasm-004f446a-374:887
main.main @ wasm-004f446a-879:50
runtime.main @ wasm-004f446a-401:590
_rt0_wasm_js @ wasm-004f446a-769:37
run @ wasm_exec.js:383
run @ wasm_exec.html:34
onclick @ wasm_exec.html:39

What did you see instead?

SCRIPT5009: 'TextEncoder' is not defined wasm_exec.js (64,1)
SCRIPT5009: 'Go' is not defined index_wasm.html (11,1)

This error occurs because Edge does not support TextEncoder, however, it does support WASM.
https://caniuse.com/#search=TextEncoder
https://caniuse.com/#search=wasm

Proposed solution

Explore polyfilling TextEncoder and including the polyfill inside misc/wasm/wasm_exec.js so that Edge will work.

@silbinarywolf silbinarywolf changed the title misc/wasm/wasm_exec: Microsoft Edge isn't supported out-of-the-box misc/wasm/wasm_exec: Microsoft Edge crashes due to TextEncoder not being supported Aug 28, 2018
@silbinarywolf silbinarywolf changed the title misc/wasm/wasm_exec: Microsoft Edge crashes due to TextEncoder not being supported misc/wasm/wasm_exec: Microsoft Edge 18 (latest) crashes due to TextEncoder not being supported Aug 28, 2018
@silbinarywolf
Copy link
Contributor Author

silbinarywolf commented Aug 28, 2018

I'll put together a PR, but for anybody who stumbles upon this, here's a modified wasm_exec.js with the polyfill included:

// Copyright 2018 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

(() => {
	// Map web browser API and Node.js API to a single common API (preferring web standards over Node.js API).
	const isNodeJS = typeof process !== "undefined";
	if (isNodeJS) {
		global.require = require;
		global.fs = require("fs");

		const nodeCrypto = require("crypto");
		global.crypto = {
			getRandomValues(b) {
				nodeCrypto.randomFillSync(b);
			},
		};

		global.performance = {
			now() {
				const [sec, nsec] = process.hrtime();
				return sec * 1000 + nsec / 1000000;
			},
		};

		const util = require("util");
		global.TextEncoder = util.TextEncoder;
		global.TextDecoder = util.TextDecoder;
	} else {
		// Add polyfill for TextEncoder and TextDecoder for Microsoft Edge 17/18 support
		// https://caniuse.com/#feat=textencoder
		if (!window.TextEncoder) {
			TextEncoder = function(){}
			TextEncoder.prototype.encode = function (string) {
				var octets = [];
				var length = string.length;
				var i = 0;
				while (i < length) {
					var codePoint = string.codePointAt(i);
					var c = 0;
					var bits = 0;
					if (codePoint <= 0x0000007F) {
						c = 0;
						bits = 0x00;
					} else if (codePoint <= 0x000007FF) {
						c = 6;
						bits = 0xC0;
					} else if (codePoint <= 0x0000FFFF) {
						c = 12;
						bits = 0xE0;
					} else if (codePoint <= 0x001FFFFF) {
						c = 18;
						bits = 0xF0;
					}
					octets.push(bits | (codePoint >> c));
					c -= 6;
					while (c >= 0) {
						octets.push(0x80 | ((codePoint >> c) & 0x3F));
						c -= 6;
					}
					i += codePoint >= 0x10000 ? 2 : 1;
				}
				return octets;
			};
		}
		if (!window.TextDecoder) {
			TextDecoder = function(){}
			TextDecoder.prototype.decode = function (octets) {
				var string = "";
				var i = 0;
				while (i < octets.length) {
					var octet = octets[i];
					var bytesNeeded = 0;
					var codePoint = 0;
					if (octet <= 0x7F) {
						bytesNeeded = 0;
						codePoint = octet & 0xFF;
					} else if (octet <= 0xDF) {
						bytesNeeded = 1;
						codePoint = octet & 0x1F;
					} else if (octet <= 0xEF) {
						bytesNeeded = 2;
						codePoint = octet & 0x0F;
					} else if (octet <= 0xF4) {
						bytesNeeded = 3;
						codePoint = octet & 0x07;
					}
					if (octets.length - i - bytesNeeded > 0) {
						var k = 0;
						while (k < bytesNeeded) {
							octet = octets[i + k + 1];
							codePoint = (codePoint << 6) | (octet & 0x3F);
							k += 1;
						}
					} else {
						codePoint = 0xFFFD;
						bytesNeeded = octets.length - i;
					}
					string += String.fromCodePoint(codePoint);
					i += bytesNeeded + 1;
				}
				return string
			};
		}

		if (typeof window !== "undefined") {
			window.global = window;
		} else if (typeof self !== "undefined") {
			self.global = self;
		} else {
			throw new Error("cannot export Go (neither window nor self is defined)");
		}

		let outputBuf = "";
		global.fs = {
			constants: { O_WRONLY: -1, O_RDWR: -1, O_CREAT: -1, O_TRUNC: -1, O_APPEND: -1, O_EXCL: -1 }, // unused
			writeSync(fd, buf) {
				outputBuf += decoder.decode(buf);
				const nl = outputBuf.lastIndexOf("\n");
				if (nl != -1) {
					console.log(outputBuf.substr(0, nl));
					outputBuf = outputBuf.substr(nl + 1);
				}
				return buf.length;
			},
			openSync(path, flags, mode) {
				const err = new Error("not implemented");
				err.code = "ENOSYS";
				throw err;
			},
		};
	}

	const encoder = new TextEncoder("utf-8");
	const decoder = new TextDecoder("utf-8");

	global.Go = class {
		constructor() {
			this.argv = ["js"];
			this.env = {};
			this.exit = (code) => {
				if (code !== 0) {
					console.warn("exit code:", code);
				}
			};
			this._callbackTimeouts = new Map();
			this._nextCallbackTimeoutID = 1;

			const mem = () => {
				// The buffer may change when requesting more memory.
				return new DataView(this._inst.exports.mem.buffer);
			}

			const setInt64 = (addr, v) => {
				mem().setUint32(addr + 0, v, true);
				mem().setUint32(addr + 4, Math.floor(v / 4294967296), true);
			}

			const getInt64 = (addr) => {
				const low = mem().getUint32(addr + 0, true);
				const high = mem().getInt32(addr + 4, true);
				return low + high * 4294967296;
			}

			const loadValue = (addr) => {
				const f = mem().getFloat64(addr, true);
				if (!isNaN(f)) {
					return f;
				}

				const id = mem().getUint32(addr, true);
				return this._values[id];
			}

			const storeValue = (addr, v) => {
				const nanHead = 0x7FF80000;

				if (typeof v === "number") {
					if (isNaN(v)) {
						mem().setUint32(addr + 4, nanHead, true);
						mem().setUint32(addr, 0, true);
						return;
					}
					mem().setFloat64(addr, v, true);
					return;
				}

				switch (v) {
					case undefined:
						mem().setUint32(addr + 4, nanHead, true);
						mem().setUint32(addr, 1, true);
						return;
					case null:
						mem().setUint32(addr + 4, nanHead, true);
						mem().setUint32(addr, 2, true);
						return;
					case true:
						mem().setUint32(addr + 4, nanHead, true);
						mem().setUint32(addr, 3, true);
						return;
					case false:
						mem().setUint32(addr + 4, nanHead, true);
						mem().setUint32(addr, 4, true);
						return;
				}

				let ref = this._refs.get(v);
				if (ref === undefined) {
					ref = this._values.length;
					this._values.push(v);
					this._refs.set(v, ref);
				}
				let typeFlag = 0;
				switch (typeof v) {
					case "string":
						typeFlag = 1;
						break;
					case "symbol":
						typeFlag = 2;
						break;
					case "function":
						typeFlag = 3;
						break;
				}
				mem().setUint32(addr + 4, nanHead | typeFlag, true);
				mem().setUint32(addr, ref, true);
			}

			const loadSlice = (addr) => {
				const array = getInt64(addr + 0);
				const len = getInt64(addr + 8);
				return new Uint8Array(this._inst.exports.mem.buffer, array, len);
			}

			const loadSliceOfValues = (addr) => {
				const array = getInt64(addr + 0);
				const len = getInt64(addr + 8);
				const a = new Array(len);
				for (let i = 0; i < len; i++) {
					a[i] = loadValue(array + i * 8);
				}
				return a;
			}

			const loadString = (addr) => {
				const saddr = getInt64(addr + 0);
				const len = getInt64(addr + 8);
				return decoder.decode(new DataView(this._inst.exports.mem.buffer, saddr, len));
			}

			const timeOrigin = Date.now() - performance.now();
			this.importObject = {
				go: {
					// func wasmExit(code int32)
					"runtime.wasmExit": (sp) => {
						const code = mem().getInt32(sp + 8, true);
						this.exited = true;
						delete this._inst;
						delete this._values;
						delete this._refs;
						this.exit(code);
					},

					// func wasmWrite(fd uintptr, p unsafe.Pointer, n int32)
					"runtime.wasmWrite": (sp) => {
						const fd = getInt64(sp + 8);
						const p = getInt64(sp + 16);
						const n = mem().getInt32(sp + 24, true);
						fs.writeSync(fd, new Uint8Array(this._inst.exports.mem.buffer, p, n));
					},

					// func nanotime() int64
					"runtime.nanotime": (sp) => {
						setInt64(sp + 8, (timeOrigin + performance.now()) * 1000000);
					},

					// func walltime() (sec int64, nsec int32)
					"runtime.walltime": (sp) => {
						const msec = (new Date).getTime();
						setInt64(sp + 8, msec / 1000);
						mem().setInt32(sp + 16, (msec % 1000) * 1000000, true);
					},

					// func scheduleCallback(delay int64) int32
					"runtime.scheduleCallback": (sp) => {
						const id = this._nextCallbackTimeoutID;
						this._nextCallbackTimeoutID++;
						this._callbackTimeouts.set(id, setTimeout(
							() => { this._resolveCallbackPromise(); },
							getInt64(sp + 8) + 1, // setTimeout has been seen to fire up to 1 millisecond early
						));
						mem().setInt32(sp + 16, id, true);
					},

					// func clearScheduledCallback(id int32)
					"runtime.clearScheduledCallback": (sp) => {
						const id = mem().getInt32(sp + 8, true);
						clearTimeout(this._callbackTimeouts.get(id));
						this._callbackTimeouts.delete(id);
					},

					// func getRandomData(r []byte)
					"runtime.getRandomData": (sp) => {
						crypto.getRandomValues(loadSlice(sp + 8));
					},

					// func stringVal(value string) ref
					"syscall/js.stringVal": (sp) => {
						storeValue(sp + 24, loadString(sp + 8));
					},

					// func valueGet(v ref, p string) ref
					"syscall/js.valueGet": (sp) => {
						storeValue(sp + 32, Reflect.get(loadValue(sp + 8), loadString(sp + 16)));
					},

					// func valueSet(v ref, p string, x ref)
					"syscall/js.valueSet": (sp) => {
						Reflect.set(loadValue(sp + 8), loadString(sp + 16), loadValue(sp + 32));
					},

					// func valueIndex(v ref, i int) ref
					"syscall/js.valueIndex": (sp) => {
						storeValue(sp + 24, Reflect.get(loadValue(sp + 8), getInt64(sp + 16)));
					},

					// valueSetIndex(v ref, i int, x ref)
					"syscall/js.valueSetIndex": (sp) => {
						Reflect.set(loadValue(sp + 8), getInt64(sp + 16), loadValue(sp + 24));
					},

					// func valueCall(v ref, m string, args []ref) (ref, bool)
					"syscall/js.valueCall": (sp) => {
						try {
							const v = loadValue(sp + 8);
							const m = Reflect.get(v, loadString(sp + 16));
							const args = loadSliceOfValues(sp + 32);
							storeValue(sp + 56, Reflect.apply(m, v, args));
							mem().setUint8(sp + 64, 1);
						} catch (err) {
							storeValue(sp + 56, err);
							mem().setUint8(sp + 64, 0);
						}
					},

					// func valueInvoke(v ref, args []ref) (ref, bool)
					"syscall/js.valueInvoke": (sp) => {
						try {
							const v = loadValue(sp + 8);
							const args = loadSliceOfValues(sp + 16);
							storeValue(sp + 40, Reflect.apply(v, undefined, args));
							mem().setUint8(sp + 48, 1);
						} catch (err) {
							storeValue(sp + 40, err);
							mem().setUint8(sp + 48, 0);
						}
					},

					// func valueNew(v ref, args []ref) (ref, bool)
					"syscall/js.valueNew": (sp) => {
						try {
							const v = loadValue(sp + 8);
							const args = loadSliceOfValues(sp + 16);
							storeValue(sp + 40, Reflect.construct(v, args));
							mem().setUint8(sp + 48, 1);
						} catch (err) {
							storeValue(sp + 40, err);
							mem().setUint8(sp + 48, 0);
						}
					},

					// func valueLength(v ref) int
					"syscall/js.valueLength": (sp) => {
						setInt64(sp + 16, parseInt(loadValue(sp + 8).length));
					},

					// valuePrepareString(v ref) (ref, int)
					"syscall/js.valuePrepareString": (sp) => {
						const str = encoder.encode(String(loadValue(sp + 8)));
						storeValue(sp + 16, str);
						setInt64(sp + 24, str.length);
					},

					// valueLoadString(v ref, b []byte)
					"syscall/js.valueLoadString": (sp) => {
						const str = loadValue(sp + 8);
						loadSlice(sp + 16).set(str);
					},

					// func valueInstanceOf(v ref, t ref) bool
					"syscall/js.valueInstanceOf": (sp) => {
						mem().setUint8(sp + 24, loadValue(sp + 8) instanceof loadValue(sp + 16));
					},

					"debug": (value) => {
						console.log(value);
					},
				}
			};
		}

		async run(instance) {
			this._inst = instance;
			this._values = [ // TODO: garbage collection
				NaN,
				undefined,
				null,
				true,
				false,
				global,
				this._inst.exports.mem,
				this,
			];
			this._refs = new Map();
			this._callbackShutdown = false;
			this.exited = false;

			const mem = new DataView(this._inst.exports.mem.buffer)

			// Pass command line arguments and environment variables to WebAssembly by writing them to the linear memory.
			let offset = 4096;

			const strPtr = (str) => {
				let ptr = offset;
				new Uint8Array(mem.buffer, offset, str.length + 1).set(encoder.encode(str + "\0"));
				offset += str.length + (8 - (str.length % 8));
				return ptr;
			};

			const argc = this.argv.length;

			const argvPtrs = [];
			this.argv.forEach((arg) => {
				argvPtrs.push(strPtr(arg));
			});

			const keys = Object.keys(this.env).sort();
			argvPtrs.push(keys.length);
			keys.forEach((key) => {
				argvPtrs.push(strPtr(`${key}=${this.env[key]}`));
			});

			const argv = offset;
			argvPtrs.forEach((ptr) => {
				mem.setUint32(offset, ptr, true);
				mem.setUint32(offset + 4, 0, true);
				offset += 8;
			});

			while (true) {
				const callbackPromise = new Promise((resolve) => {
					this._resolveCallbackPromise = () => {
						if (this.exited) {
							throw new Error("bad callback: Go program has already exited");
						}
						setTimeout(resolve, 0); // make sure it is asynchronous
					};
				});
				this._inst.exports.run(argc, argv);
				if (this.exited) {
					break;
				}
				await callbackPromise;
			}
		}

		static _makeCallbackHelper(id, pendingCallbacks, go) {
			return function() {
				pendingCallbacks.push({ id: id, args: arguments });
				go._resolveCallbackPromise();
			};
		}

		static _makeEventCallbackHelper(preventDefault, stopPropagation, stopImmediatePropagation, fn) {
			return function(event) {
				if (preventDefault) {
					event.preventDefault();
				}
				if (stopPropagation) {
					event.stopPropagation();
				}
				if (stopImmediatePropagation) {
					event.stopImmediatePropagation();
				}
				fn(event);
			};
		}
	}

	if (isNodeJS) {
		if (process.argv.length < 3) {
			process.stderr.write("usage: go_js_wasm_exec [wasm binary] [arguments]\n");
			process.exit(1);
		}

		const go = new Go();
		go.argv = process.argv.slice(2);
		go.env = process.env;
		go.exit = process.exit;
		WebAssembly.instantiate(fs.readFileSync(process.argv[2]), go.importObject).then((result) => {
			process.on("exit", (code) => { // Node.js exits if no callback is pending
				if (code === 0 && !go.exited) {
					// deadlock, make Go print error and stack traces
					go._callbackShutdown = true;
					go._inst.exports.run();
				}
			});
			return go.run(result.instance);
		}).catch((err) => {
			throw err;
		});
	}
})();

This gist was used: https://gist.github.com/Yaffle/5458286

@gopherbot
Copy link

Change https://golang.org/cl/131718 mentions this issue: misc/wasm: add polyfill for TextEncoder/TextDecoder for Edge support

@agnivade agnivade changed the title misc/wasm/wasm_exec: Microsoft Edge 18 (latest) crashes due to TextEncoder not being supported misc/wasm: Microsoft Edge 18 (latest) crashes due to TextEncoder not being supported Aug 28, 2018
@agnivade agnivade added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 28, 2018
@agnivade agnivade added this to the Go1.12 milestone Aug 28, 2018
@FiloSottile FiloSottile added the arch-wasm WebAssembly issues label Aug 30, 2018
@FiloSottile
Copy link
Contributor

@gopherbot please file this to be considered for backport to 1.11.

We will need to decide what the backport policy is for Wasm, in particular when a new browser breaks our code.

@gopherbot
Copy link

Backport issue(s) opened: #27393 (for 1.11).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

silbinarywolf added a commit to silbinarywolf/go that referenced this issue Sep 1, 2018
silbinarywolf added a commit to silbinarywolf/go that referenced this issue Sep 2, 2018
…ace polyfill before wasm_exec.js to fix crashing in Edge

Fixes golang#27295
silbinarywolf added a commit to silbinarywolf/go that referenced this issue Sep 2, 2018
silbinarywolf added a commit to silbinarywolf/go that referenced this issue Sep 2, 2018
…ace polyfill before wasm_exec.js to fix crashing in Edge

Fixes golang#27295
silbinarywolf added a commit to silbinarywolf/go that referenced this issue Sep 2, 2018
silbinarywolf added a commit to silbinarywolf/go that referenced this issue Sep 2, 2018
…ace polyfill before wasm_exec.js to fix crashing in Edge

Fixes golang#27295
silbinarywolf added a commit to silbinarywolf/go that referenced this issue Sep 2, 2018
@bradfitz bradfitz reopened this Oct 1, 2018
@gopherbot
Copy link

Change https://golang.org/cl/138937 mentions this issue: Revert "misc/wasm: add polyfill for TextEncoder/TextDecoder for Edge support"

@gopherbot
Copy link

Change https://golang.org/cl/139037 mentions this issue: misc/wasm: add mention of polyfill for Edge support

@gopherbot
Copy link

Change https://golang.org/cl/139057 mentions this issue: [release-branch.go1.11] misc/wasm: add mention of polyfill for Edge support

gopherbot pushed a commit that referenced this issue Oct 2, 2018
…support"

This reverts CL 131718, commit a0e7f12.

Reason for revert: adds request overhead & dependency on third-party service for all users regardless of whether it's necessary.

Updates #27295

Change-Id: I4a8a9b0c8e4a3198c884dfbd90ba36734f70a9a9
Reviewed-on: https://go-review.googlesource.com/138937
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gopherbot pushed a commit that referenced this issue Oct 2, 2018
…upport

Edge supports WebAssembly but not TextEncoder or TextDecoder.
This change adds a comment pointing to a polyfill that could
be used. The polyfill is not added by default, because we want to
let the user decide if/how to include the polyfill.

Fixes #27295

Change-Id: I375f58f2168665f549997b368428c398dfbbca1c
Reviewed-on: https://go-review.googlesource.com/139037
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit cfb603b0b5fb9c1e72be665b2d65743ddf18c779)
Reviewed-on: https://go-review.googlesource.com/139057
Reviewed-by: Richard Musiol <neelance@gmail.com>
changkun added a commit to changkun/go that referenced this issue Nov 30, 2018
* [release-branch.go1.11] doc/go1.11, cmd/go: elaborate on new GOFLAGS environment variable

In Go 1.11, cmd/go gained support for the GOFLAGS environment variable.
It was added and described in detail in CL 126656.
Mention it in the Go 1.11 release notes, link to the cmd/go documentation,
and add more details there.

Fixes golang#27387.

Change-Id: Ifc35bfe3e0886a145478d36dde8e80aedd8ec68e
Reviewed-on: https://go-review.googlesource.com/135035
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Rob Pike <r@golang.org>
(cherry picked from commit 58c6afe)
Reviewed-on: https://go-review.googlesource.com/135496
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

* [release-branch.go1.11] net/http: ensure null body in Fetch response is not read

The Fetch API returns a null body if there is no response body,
on browsers that support streaming the response body. This
change ensures we check for both undefined and null bodies
before attempting to read the body.

Fixes golang#27424

Change-Id: I0da86b61284fe394418b4b431495e715a037f335
Reviewed-on: https://go-review.googlesource.com/131236
Reviewed-by: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit ce53683)
Reviewed-on: https://go-review.googlesource.com/136915

* [release-branch.go1.11] runtime: ignore races between close and len/cap

They aren't really races, or at least they don't have any
observable effect. The spec is silent on whether these are actually
races or not.

Fix this problem by not using the address of len (or of cap)
as the location where channel operations are recorded to occur.
Use a random other field of hchan for that.

I'm not 100% sure we should in fact fix this. Opinions welcome.

Fixes golang#27778

Change-Id: Ib4efd4b62e0d1ef32fa51e373035ef207a655084
Reviewed-on: https://go-review.googlesource.com/135698
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(cherry picked from commit 83dfc3b)
Reviewed-on: https://go-review.googlesource.com/138179
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] net: fail fast for DNS rcode success with no answers of requested type

DNS responses which do not contain answers of the requested type return
errNoSuchHost, the same error as rcode name error. Prior to
golang.org/cl/37879, both cases resulted in no additional name servers
being consulted for the question. That CL changed the behavior for both
cases. Issue golang#25336 was filed about the rcode name error case and
golang.org/cl/113815 fixed it. This CL fixes the no answers of requested
type case as well.

Updates golang#27525
Fixes golang#27537

Change-Id: I52fadedcd195f16adf62646b76bea2ab3b15d117
Reviewed-on: https://go-review.googlesource.com/133675
Run-TryBot: Ian Gudger <igudger@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 94f48dd)
Reviewed-on: https://go-review.googlesource.com/138175
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] cmd/go: add GOMIPS value to build id for mipsle

Strip a trailing "le" from the GOARCH value when calculating the GOxxx
environment variable that affects it.

Updates golang#27260
Fixes golang#27420

Change-Id: I081f30d5dc19281901551823f4f56be028b5f71a
Reviewed-on: https://go-review.googlesource.com/131379
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 61318d7)
Reviewed-on: https://go-review.googlesource.com/138176
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] doc: add go1.11 to contrib.html

Missing from https://golang.org/project

Change-Id: I6cb769ae861a81f0264bae624b5fe8d70aa92497
Reviewed-on: https://go-review.googlesource.com/138356
Reviewed-by: Chris Broadfoot <cbro@golang.org>

* [release-branch.go1.11] reflect: use correct write barrier operations for method funcs

Fix the code to use write barriers on heap memory, and no
write barriers on stack memory.

These errors were discovered as part of fixing golang#27695. They may
have something to do with that issue, but hard to be sure.
The core cause is different, so this fix is a separate CL.

Update golang#27867

Change-Id: Ib005f6b3308de340be83c3d07d049d5e316b1e3c
Reviewed-on: https://go-review.googlesource.com/137438
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit e35a412)
Reviewed-on: https://go-review.googlesource.com/138581
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] reflect: ensure correct scanning of return values

During a call to a reflect-generated function or method (via
makeFuncStub or methodValueCall), when should we scan the return
values?

When we're starting a reflect call, the space on the stack for the
return values is not initialized yet, as it contains whatever junk was
on the stack of the caller at the time. The return space must not be
scanned during a GC.

When we're finishing a reflect call, the return values are
initialized, and must be scanned during a GC to make sure that any
pointers in the return values are found and their referents retained.

When the GC stack walk comes across a reflect call in progress on the
stack, it needs to know whether to scan the results or not. It doesn't
know the progress of the reflect call, so it can't decide by
itself. The reflect package needs to tell it.

This CL adds another slot in the frame of makeFuncStub and
methodValueCall so we can put a boolean in there which tells the
runtime whether to scan the results or not.

This CL also adds the args length to reflectMethodValue so the
runtime can restrict its scanning to only the args section (not the
results) if the reflect package says the results aren't ready yet.

Do a delicate dance in the reflect package to set the "results are
valid" bit. We need to make sure we set the bit only after we've
copied the results back to the stack. But we must set the bit before
we drop reflect's copy of the results. Otherwise, we might have a
state where (temporarily) no one has a live copy of the results.
That's the state we were observing in issue golang#27695 before this CL.

The bitmap used by the runtime currently contains only the args.
(Actually, it contains all the bits, but the size is set so we use
only the args portion.) This is safe for early in a reflect call, but
unsafe late in a reflect call. The test issue27695.go demonstrates
this unsafety. We change the bitmap to always include both args
and results, and decide at runtime which portion to use.

issue27695.go only has a test for method calls. Function calls were ok
because there wasn't a safepoint between when reflect dropped its copy
of the return values and when the caller is resumed. This may change
when we introduce safepoints everywhere.

This truncate-to-only-the-args was part of CL 9888 (in 2015). That
part of the CL fixed the problem demonstrated in issue27695b.go but
introduced the problem demonstrated in issue27695.go.

TODO, in another CL: simplify FuncLayout and its test. stack return
value is now identical to frametype.ptrdata + frametype.gcdata.

Update golang#27867

Change-Id: I2d49b34e34a82c6328b34f02610587a291b25c5f
Reviewed-on: https://go-review.googlesource.com/137440
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/138582
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] reflect: fix s390x reflect method calls

R0 isn't the zero register any more. Oops.

Update golang#27867

Change-Id: I46a975ed37d5e570afe2e228d3edf74949e08ad7
Reviewed-on: https://go-review.googlesource.com/138580
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Reviewed-on: https://go-review.googlesource.com/138583
Run-TryBot: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] net: concatenate multiple TXT strings in single TXT record

When go resolver was changed to use dnsmessage.Parser, LookupTXT
returned two strings in one record as two different records. This change
reverts back to concatenating multiple strings in a single
TXT record.

Updates golang#27763
Fixes golang#27886

Change-Id: Ice226fcb2be4be58853de34ed35b4627acb429ea
Reviewed-on: https://go-review.googlesource.com/136955
Reviewed-by: Ian Gudger <igudger@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Gudger <igudger@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 7b3b160323b56b357832549fbab7a60d27688ec1)
Reviewed-on: https://go-review.googlesource.com/138177
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>

* [release-branch.go1.11] encoding/json: fix UnmarshalTypeError without field and struct values

Updates golang#26444
Updates golang#27275
Fixes golang#27318

Change-Id: I9e8cbff79f7643ca8964c572c1a98172b6831730
GitHub-Last-Rev: 7eea215
GitHub-Pull-Request: golang#26719
Reviewed-on: https://go-review.googlesource.com/126897
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/138178
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] doc: document Go 1.11.1

Updates golang#27953

Change-Id: I2f1a55e15dc5737a5a06bd894c46b2c4705f338c
Reviewed-on: https://go-review.googlesource.com/138858
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit f99fc3a)
Reviewed-on: https://go-review.googlesource.com/138859
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

* [release-branch.go1.11] go1.11.1

Change-Id: I3cf3e57b11ad02b497276bae1864fc5ade8144b9
Reviewed-on: https://go-review.googlesource.com/138860
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

* [release-branch.go1.11] misc/wasm: add mention of polyfill for Edge support

Edge supports WebAssembly but not TextEncoder or TextDecoder.
This change adds a comment pointing to a polyfill that could
be used. The polyfill is not added by default, because we want to
let the user decide if/how to include the polyfill.

Fixes golang#27295

Change-Id: I375f58f2168665f549997b368428c398dfbbca1c
Reviewed-on: https://go-review.googlesource.com/139037
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit cfb603b0b5fb9c1e72be665b2d65743ddf18c779)
Reviewed-on: https://go-review.googlesource.com/139057
Reviewed-by: Richard Musiol <neelance@gmail.com>

* [release-branch.go1.11] cmd/compile: don't crash reporting misuse of shadowed built-in function

The existing implementation causes a compiler panic if a function parameter shadows a built-in function, and then calling that shadowed name.

Updates golang#27356
Fixes golang#27399

Change-Id: I1ffb6dc01e63c7f499e5f6f75f77ce2318f35bcd
Reviewed-on: https://go-review.googlesource.com/132876
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 4a095b8)
Reviewed-on: https://go-review.googlesource.com/c/139103
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] cmd/compile: fix type of OffPtr in some optimization rules

In some optimization rules the type of generated OffPtr was
incorrectly set to the type of the pointee, instead of the
pointer. When the OffPtr value is spilled, this may generate
a spill of the wrong type, e.g. a floating point spill of an
integer (pointer) value. On Wasm, this leads to invalid
bytecode.

Fixes golang#27961.

Change-Id: I5d464847eb900ed90794105c0013a1a7330756cc
Reviewed-on: https://go-review.googlesource.com/c/139257
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
(cherry picked from commit c96e3bc)
Reviewed-on: https://go-review.googlesource.com/c/139104
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

* [release-branch.go1.11] cmd/go: don't mention -mod=release

The -mod=release flag is not supported, so this appears to be a
documentation mistake.

Updates golang#27354.
Fixes golang#27398.

Change-Id: I895e8d5b4918adcb1f605361773173f312fa7b65
GitHub-Last-Rev: 42bfe0c
GitHub-Pull-Request: golang#27358
Reviewed-on: https://go-review.googlesource.com/132116
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 014901c)
Reviewed-on: https://go-review.googlesource.com/c/139421
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] doc: update docs.html with new tour import path

As of golang.org/cl/141857 the import path has changed from
golang.org/x/tour/gotour to golang.org/x/tour

Change-Id: Ib54ab2e50188ef66c8a5c45136babfa49ad6934a
Reviewed-on: https://go-review.googlesource.com/c/141917
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 035f9e8)
Reviewed-on: https://go-review.googlesource.com/c/143617

* [release-branch.go1.11] cmd/go: ensure git attributes are set

This change disables the export-subst and export-ignore attributes when
creating zip files for modules. This is done to prevent the ziphash for
a given repo/revision from differing based on variables such as git
version or size of repo. The full rational for this change is detailed
here:

    golang#27153 (comment)

Fixes golang#28094

Change-Id: Ib33f525d91d2581fa0b5d26e70d29620c7e685e9
Reviewed-on: https://go-review.googlesource.com/c/135175
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-on: https://go-review.googlesource.com/c/141098
Reviewed-by: Andrew Bonventre <andybons@golang.org>

* [release-branch.go1.11] cmd/go, cmd/link: silence bogus Apple Xcode warning

Certain installations of Xcode are affected by a bug that causes
them to print an inconsequential link-time warning that looks like:

	ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.

This has nothing to do with Go, and we've sent this repro case
to Apple:

	$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
	version: 10.0.0.0.1.1535735448
	$ clang --version
	Apple LLVM version 10.0.0 (clang-1000.10.44.2)
	Target: x86_64-apple-darwin17.7.0
	Thread model: posix
	InstalledDir: /Library/Developer/CommandLineTools/usr/bin
	$ cat > issue.c
	int main() { return 0; }
	^D
	$ clang issue.c -framework CoreFoundation
	ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
	$

Even if Apple does release a fixed Xcode, many people are seeing
this useless warning, and we might as well make it go away.

Fixes golang#26073.

Change-Id: Ifc17ba7da1f6b59e233c11ebdab7241cb6656324
Reviewed-on: https://go-review.googlesource.com/c/144112
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
(cherry picked from commit 66bb8dd)
Reviewed-on: https://go-review.googlesource.com/c/145458
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

* [release-branch.go1.11] internal/poll: advance file position in windows sendfile

Some versions of Windows (Windows 10 1803) do not set file
position after TransmitFile completes. So just use Seek
to set file position before returning from sendfile.

Fixes golang#27411

Change-Id: I7a49be10304b5db19dda707b13ac93d338aeb190
Reviewed-on: https://go-review.googlesource.com/131976
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/145779
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>

* [release-branch.go1.11] cmd/go/internal/modcmd: remove non-existent -dir flag

Updates golang#27243
Fixes golang#27498

Change-Id: If9230244938dabd03b9afaa6600310df8f97fe92
Reviewed-on: https://go-review.googlesource.com/131775
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 55ef446)
Reviewed-on: https://go-review.googlesource.com/c/146717
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] cmd/trace: don't drop sweep slice details

For sweep events, we used to modify the ViewerEvent returned from
ctx.emitSlice later in order to embed more details about the sweep
operation. The trick no longer works after the change
https://golang.org/cl/92375 and caused a regression.

ctx.emit method encodes the ViewerEvent, so any modification to the
ViewerEvent object after ctx.emit returns will not be reflected.

Refactor ctx.emitSlice, so ctx.makeSlice can be used when producing
slices for SWEEP. ctx.emit* methods are meant to truely emit
ViewerEvents.

Fixes golang#27717
Updates golang#27711

Change-Id: I0b733ebbbfd4facd8714db0535809ec3cab0833d
Reviewed-on: https://go-review.googlesource.com/135775
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit e57f24a)
Reviewed-on: https://go-review.googlesource.com/c/146698
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

* [release-branch.go1.11] database/sql: correctly report MaxIdleClosed stat

Previously the MaxIdleClosed counter was incremented when added
to the free connection list, rather then when it wasn't added
to the free connection list. Flip this logic to correct.

Fixes golang#28325

Change-Id: I405302c14fb985369dab48fbe845e5651afc4ccf
Reviewed-on: https://go-review.googlesource.com/c/138578
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 7db509e)
Reviewed-on: https://go-review.googlesource.com/c/146697
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>

* [release-branch.go1.11] go/types: use correct receiver types for embedded interface methods

Interface methods don't declare a receiver (it's implicit), but after
type-checking the respective *types.Func objects are marked as methods
by having a receiver. For interface methods, the receiver base type used
to be the interface that declared the method in the first place, even if
the method also appeared in other interfaces via embedding. A change in
the computation of method sets for interfaces for Go1.10 changed that
inadvertently, with the consequence that sometimes a method's receiver
type ended up being an interface into which the method was embedded.
The exact behavior also depended on file type-checking order, and because
files are sometimes sorted by name, the behavior depended on file names.

This didn't matter for type-checking (the typechecker doesn't need the
receiver), but it matters for clients, and for printing of methods.

This change fixes interface method receivers at the end of type-checking
when we have all relevant information.

Fixes golang#28249
Updates golang#28005

Change-Id: I96c120fb0e517d7f8a14b8530f0273674569d5ea
Reviewed-on: https://go-review.googlesource.com/c/141358
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-on: https://go-review.googlesource.com/c/146660
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

* [release-branch.go1.11] doc: document Go 1.10.5

Change-Id: I11adca150ab795607b832fb354a3e065655e1020
Reviewed-on: https://go-review.googlesource.com/c/147179
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 2764d5e)
Reviewed-on: https://go-review.googlesource.com/c/147181
Reviewed-by: Andrew Bonventre <andybons@golang.org>

* [release-branch.go1.11] doc: document Go 1.11.2

Change-Id: Iaff03911f1807d462f1966590626bd486807f53d
Reviewed-on: https://go-review.googlesource.com/c/147178
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit c5d78f5)
Reviewed-on: https://go-review.googlesource.com/c/147182
Reviewed-by: Andrew Bonventre <andybons@golang.org>

* [release-branch.go1.11] go1.11.2

Change-Id: Idd3527ba8f2329876cbca646aacd97739b9828f7
Reviewed-on: https://go-review.googlesource.com/c/147217
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] runtime: never call into race detector with retaken P

cgocall could previously invoke the race detector on an M whose P had
been retaken. The race detector would attempt to use the P-local state
from this stale P, racing with the thread that was actually wired to
that P. The result was memory corruption of ThreadSanitizer's internal
data structures that presented as hard-to-understand assertion failures
and segfaults.

Reorder cgocall so that it always acquires a P before invoking the race
detector, and add a test that stresses the interaction between cgo and
the race detector to protect against future bugs of this kind.

Fixes golang#28690.

Change-Id: Ide93f96a23490314d6647547140e0a412a97f0d4
Reviewed-on: https://go-review.googlesource.com/c/148717
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(cherry picked from commit e496e61)
Reviewed-on: https://go-review.googlesource.com/c/148902
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] runtime: avoid arm64 8.1 atomics on Android

The kernel on some Samsung S9+ models reports support for arm64 8.1
atomics, but in reality only some of the cores support them. Go
programs scheduled to cores without support will crash with SIGILL.

This change unconditionally disables the optimization on Android.
A better fix is to precisely detect the offending chipset.

Fixes golang#28586

Change-Id: I35a1273e5660603824d30ebef2ce7e429241bf1f
Reviewed-on: https://go-review.googlesource.com/c/147377
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/149557
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] cmd/go: don't panic when go run is passed ... under nonexistent dir

Given a nonexistent directory above a wildcard:

    go run ./nonexistent/...

Print this error instead of panicking:

    go run: no packages loaded from ./nonexistent/...

Updates golang#28696.
Fixes golang#28725

Change-Id: Iaa3bc5c78b14ef858d931778e1bc55ca626c5571
GitHub-Last-Rev: bb1a804
GitHub-Pull-Request: golang#28703
Reviewed-on: https://go-review.googlesource.com/c/148821
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
(cherry picked from commit 529ea7c)
Reviewed-on: https://go-review.googlesource.com/c/149607
Run-TryBot: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] cmd/compile: don't deadcode eliminate labels

Dead-code eliminating labels is tricky because there might
be gotos that can still reach them.

Bug probably introduced with CL 91056

Fixes golang#28617

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

* runtime: when using explicit argmap, also use arglen

When we set an explicit argmap, we may want only a prefix of that
argmap.  Argmap is set when the function is reflect.makeFuncStub or
reflect.methodValueCall. In this case, arglen specifies how much of
the args section is actually live. (It could be either all the args +
results, or just the args.)

Fixes golang#28752

Change-Id: Idf060607f15a298ac591016994e58e22f7f92d83
Reviewed-on: https://go-review.googlesource.com/c/149217
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit 0098f8a)
Reviewed-on: https://go-review.googlesource.com/c/149457

* [release-branch.go1.11] cmd/compile: reintroduce work-around for cyclic alias declarations

This change re-introduces (temporarily) a work-around for recursive
alias type declarations, originally in https://golang.org/cl/35831/
(intended as fix for golang#18640). The work-around was removed later
for a more comprehensive cycle detection check. That check
contained a subtle error which made the code appear to work,
while in fact creating incorrect types internally. See golang#25838
for details.

By re-introducing the original work-around, we eliminate problems
with many simple recursive type declarations involving aliases;
specifically cases such as golang#27232 and golang#27267. However, the more
general problem remains.

This CL also fixes the subtle error (incorrect variable use when
analyzing a type cycle) mentioned above and now issues a fatal
error with a reference to the relevant issue (rather than crashing
later during the compilation). While not great, this is better
than the current status. The long-term solution will need to
address these cycles (see golang#25838).

As a consequence, several old test cases are not accepted anymore
by the compiler since they happened to work accidentally only.
This CL disables parts or all code of those test cases. The issues
are: golang#18640, golang#23823, and golang#24939.

One of the new test cases (fixedbugs/issue27232.go) exposed a
go/types issue. The test case is excluded from the go/types test
suite and an issue was filed (golang#28576).

Updates golang#18640.
Updates golang#23823.
Updates golang#24939.
Updates golang#25838.
Updates golang#28576.

Fixes golang#27232.
Fixes golang#27267.
Fixes golang#27383.

Change-Id: I6c2d10da98bfc6f4f445c755fcaab17fc7b214c5
Reviewed-on: https://go-review.googlesource.com/c/147286
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit e630538)
Reviewed-on: https://go-review.googlesource.com/c/151339
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

* [release-branch.go1.11] cmd/compile/internal/gc: OMUL should be evaluated when using soft-float

When using soft-float, OMUL might be rewritten to function call
so we should ensure it was evaluated first.

Updates golang#28688
Fixes golang#28694

Change-Id: I30b87501782fff62d35151f394a1c22b0d490c6c
Reviewed-on: https://go-review.googlesource.com/c/148837
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit c92e73b)
Reviewed-on: https://go-review.googlesource.com/c/151342
Reviewed-by: Andrew Bonventre <andybons@golang.org>

* [release-branch.go1.11] go/types: avoid certain problems with recursive alias type declarations

It is possible to create certain recursive type declarations involving
alias types which cause the type-checker to produce an (invalid) type
for the alias because it is not yet available. By type-checking alias
declarations in a 2nd phase, the problem is mitigated a bit since it
requires more convoluted alias declarations for the problem to appear.

Also re-enable testing of fixedbugs/issue27232.go again (which was the
original cause for this change).

Updates golang#28576.
Fixes golang#28972.

Change-Id: If6f9656a95262e6575b01c4a003094d41551564b
Reviewed-on: https://go-review.googlesource.com/c/147597
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-on: https://go-review.googlesource.com/c/151500
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
@maxence-charriere
Copy link

maxence-charriere commented Feb 18, 2019

I have the same error with edge => https://app-demo-232021.appspot.com

Wasm file was built with:

▶ go version
go version go1.11.5 darwin/amd64

I also tried by adding https://github.com/golang/go/blob/master/misc/wasm/wasm_exec.html#L15-L19 (both min and non min version) but still got the

SCRIPT5009: SCRIPT5009: 'TextEncoder' is not defined
wasm_exec.js (58,2)
SCRIPT5009: SCRIPT5009: 'Go' is not defined
app-demo-232021.appspot.com (646,1)

@bradfitz
Copy link
Contributor

Closed bugs are not tracked or worked on. File a new bug if you have a problem.

suzannehamilton added a commit to nationalarchives/tdr-prototype-mvc that referenced this issue Oct 25, 2019
Checksum calculations were failing in Edge because the Rust WebAssembly
wrapper depends on `TextDecoder`, which is not supported by the
current version of Edge (even though WebAssembly itself is supported):

https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder/TextDecoder

This commit fixes the problem by trying to load the WASM module, and
falling back to checksums calculated in JavaScript if the module fails to
load.

This uses exceptions for control flow, but there's no obvious property to
test to be confident that WASM will work, since it may depend on modules
other than `TextDecoder` in the future.

A possible alternative would be to polyfill `TextDecoder`, as described
here: golang/go#27295 (comment)

The polyfill is quite complicated, though, so the JS checksum fallback
seems like a better solution, at least for now. We can revisit it if there
are major performance problems.
@golang golang locked and limited conversation to collaborators Feb 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly issues FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants