[ddc] Patching the native Object prorotype causes confusing internal representation issues

[nshahan]

DDC patches the native JS Object prototype to have some additional properties for the dart equals, hashCode, and runtimeType.

sdk/sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/classes.dart

Lines 447 to 458 in c66faf9

	void _installPropertiesForObject(jsProto) {
	// core.Object members need to be copied from the non-symbol name to the
	// symbol name.
	var coreObjProto = JS<Object>('!', '#.prototype', Object);
	var names = getOwnPropertyNames(coreObjProto);
	for (int i = 0, n = JS('!', '#.length', names); i < n; ++i) {
	var name = JS<String>('!', '#[#]', names, i);
	if (name == 'constructor') continue;
	var desc = getOwnPropertyDescriptor(coreObjProto, name);
	defineProperty(jsProto, JS('', '#.#', dartx, name), desc);
	}
	}

This means that any native JS object created on the page has those properties, including any object created for internal representation purposes. This causes some confusing conditions when debugging internal runtime logic. One such example is that we store method and setter signatures in a native object:

sdk/pkg/dev_compiler/lib/src/kernel/compiler.dart

Lines 1422 to 1425 in c66faf9

	setSignature = runtimeStatement('set${name}Signature(#, () => #)', [
	className,
	js_ast.ObjectInitializer(elements, multiline: elements.length > 1)
	]);

Later when we read the properties from this native object we find some that were not intended. This means we advance into code paths that are not expected, for example when calling a setter dynamically:

sdk/sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/operations.dart

Lines 136 to 138 in c66faf9

	if (setterType != null) {
	return JS('', '#[#] = #.as(#)', obj, f, setterType, value);
	}

We could avoid this confusion in our internal state by avoiding the patches on the native prototypes or by avoiding the use of native objects in our representation (use native maps instead).