Install @@toStringTag on namespace objects

[shvaikalesh]

Follow-up of #357.

This change aligns WebIDL namespace objects with ECMA-262 ones like Math and Atomics.

Chrome (84.0.4126.0) already implements this PR:

WebAssembly[Symbol.toStringTag] // => "WebAssembly"

cc @domenic

---

Preview | Diff

[domenic]

Interesting. I don't think we should do this; instead we can fix Chrome. Namespace objects here are patterned after those in the JS spec, such as Math and JSON, which do not have such toStringTags.

Note also that the other namespace objects on the platform, CSS and Math, do not have such toStringTags in Chrome. So I think this is just a Chrome bug.

[domenic]

Oh, I didn't click through your link. I see the JS spec is inconsistent, and Reflect has no toStringTag, but all the others do.

Hmm, so in that case probably we should align with the JS spec...

[domenic]

I filed tc39/ecma262#1970 to get some clarity here. We should probably wait for that to settle before going either way.

[shvaikalesh]

Thank you for rapid feedback! I've removed WebAssembly[@@toStringTag] from WebKit's patch.

[domenic]

@shvaikalesh it looks like the plan is to have toStringTag on namespace objects after all, per tc39/ecma262#2057 (comment). Would you be up for finishing this PR, and also adding web platform tests? (For web platform tests we should test WebAssembly, console, and CSS.)

[ExE-Boss]

When it comes to console, should the %Symbol.toStringTag% property be installed on console.[[Prototype]] or on console?

[domenic]

It should follow the normal rules for Web IDL.

[shvaikalesh]

@domenic Thank you for moving this forward! The tests are at web-platform-tests/wpt#24717. Is there something I could do to finish this PR?

[domenic]

PR looks good! I'll merge. If you could also file issues on the engines per https://github.com/heycam/webidl#breaking-changes-should-be-filed-against that'd be ideal.