Emit Symbol.toStringTag properties in TS 6.0

[Renegade334]

Fixes #1641.
Fixes #2172.
Alternative to #1762.
Supersedes #2075.

Reference: https://webidl.spec.whatwg.org/#dfn-class-string

This amends the builder to append Symbol.toStringTag properties to interfaces and iterators in the ts6.0 core libraries. (ES6's well-known symbols are universally defined in ts6.0.)

Because adding a property with a literal type affects inheritance chains, only "final" classes (ie. those that do not have any inheritance children within the current global) can have these properties typed as string literals. (For example, it's not possible for Blob#[Symbol.toStringTag] to be typed as "Blob", because File inherits from Blob, and a property of type "File" can't override a parent property of type "Blob".)

For those interfaces that have one or more inheritance children, there are two possible approaches.

• One is not to emit the property at all – but it's inconsistent to have some interfaces with Symbol.toStringTag properties, and others (including some very common ones) without them.
• The alternative is to emit properties for these as well, but type them permissively as string, so that they can be correctly overridden by child interfaces. This is the approach taken here.

The toStringTag emitter does not add to any interface marked noInterfaceObject, since these are usually pseudo-types that are not true IDL interfaces, nor to namespaces converted to interfaces (ie. console).

[github-actions]

Thanks for the PR!

This section of the codebase is owned by @saschanaz - if they write a comment saying "LGTM" then it will be merged.

[Bashamega]

Move DOMException to a .kdl file, maybe move it to dom.kdl

[Renegade334]

Moving the existing override is really beyond the scope of this changeset; would be better suited to a follow-up PR.

[Bashamega]

Moving the existing override is really beyond the scope of this changeset; would be better suited to a follow-up PR.

Then remove the changes in patches.ts

[saschanaz]

But why noToStringTag at all?

[Renegade334]

Error doesn't have a toStringTag property in the TS libs, and DOMException is a common target for userland inheritance, so the concern is that this will do more harm than good.

[saschanaz]

I guess Jake needs to make such PR then?

[jakebailey]

Yes, getting there 😄

[jakebailey]

microsoft/TypeScript#62682

[jakebailey]

The results on the above are pretty bad.

[Renegade334]

A significant proportion are intentional errors that are now differentiating between discrete DOM interfaces that are empty or identically-shaped, but looks like most of the remainder are assignability errors between the lib.dom interfaces and userland DOM-like interfaces that are unlikely to go down well. (It's worth saying that those same errors would also be triggered by those interfaces having any new props/methods added, not just toStringTag, but adding an additional key to every single interface would turbocharge the breakage.)