Expunge the concept of well-known symbols from the checker

[weswigham]

Interestingly, there is some fallout here in some odd places:

• First of all, some small changes needed to occur to replicate old behavior. Right now, a computed name of type any produces a number index signature. With this change, we make a string index signature instead (it's more broad and closer to correct).
• Additionally, late-bound members weren't issuing duplicate declaration errors. With this change, they should.
• There's also a fourslash test changes due to the lib in fourslash not-actually-having-symbols (I looked into fixing it to use the built lib, it requires changing a bunch of tests, don't wanna do that here), so the test relied on the old behavior of well-known symbols always "resolving" uniquely, regardless of weather or not they were actually defined.
• Lastly, some emit changes - specifically, where previously we'd elide Symbol.iterator when it appeared as a property name (and assume that the expression had no sideffects), now we retain and emit it (and potentially cache it), as we generally do not assume property access expressions are safe to elide or copy.

Fixes #24622

An important implementation note: As we discussed in person, Inside the checker, if we see members of the global SymbolConstructor of type symbol, we also assume you meant to say unique symbol. In this way, we retain compataibility with older libs or definition files (even as they update), which is how this can build (at all), given node is shimming Symbol.iterator as a symbol.

[weswigham]

This is a copy of the primary change from #24668 - it's required to make the symbols get looked up correctly.

[weswigham]

Huh. These changes seem pretty innocuous, but the build of run.js (the tests) runs out of memory on node6 (and only on node6). During sourcemap emit no less, so very late in the process. @rbuckton can you think of anything offhand we'd be doing where the memory consumption of node6 vs node8 would differ enough to crash the process?

[RyanCavanaugh]

@weswigham Ron's sourcemap rewrite should be going in soon so that will hopefully fix the OOM issues you're getting here

[weswigham]

A merge with master from two months ago shows that we'd already resolved the issue. CI on this PR is green, though it's probably out of date again.

[andrewbranch]

Also fixes #31253

[ExE-Boss]

This needs some serious rebasing.

Also fixes #27525 and #21603.

[ExE-Boss]

This will also fix #36468

[KilianKilmister]

any update on this?

[weswigham]

@rbuckton do we have an appetite for looking into this again? It looks like a number of things are getting dupe'd to it. IIRC we held off on it long ago so lib references could be a thing in node, to potentially remove the need for the global SymbolConstructor-symbol-as-unique symbol workaround.

[justingrant]

FWIW, this PR would also probably fix immerjs/immer#710.

[DanielRosenwasser]

I'd like to bring this back to our focus. I recently spoke to @benlesh about RxJS and how the library leans on Symbol.observable existing.

So just to start, imagine an augmentation like

interface SymbolConstructor {
    observable: symbol;
}

This is inspired by the existing declarations; however, the symbol-observable library re-exports Symbol.observable. If the declaration file contains code like

const symbolObservable: typeof Symbol.observable;
export default symbolObservable;

that appears to any other code as just symbol.

Trying to switch over to a unique symbol like so

interface SymbolConstructor {
    observable: unique symbol;
//              ^^^^^^
}

won't necessarily work because other libraries have also defined it as symbol

interface SymbolConstructor {
    observable: symbol;
}

interface SymbolConstructor {
    observable: unique symbol;
//  ~~~~~~~~~~
// Subsequent property declarations must have the same type.  Property 'observable' must be of type 'unique symbol', but here has type 'symbol'.
}

[benlesh]

I would like to note that:

1. I'm sorry. haha
2. I inherited symbol-observable which was always written this way, while it was in wide use.
3. This stuff is hard.

Another point is that we support IE, which doesn't have Symbol, so we're actually tricking the type system here a bit. Sometimes we get "@@observable" instead, because there's no Symbol. I'll admit it's not ideal, though.

[weswigham]

#42543 Now supersedes this as an updated version for 2021 - large parts are the same (and the result certainly is), but some of the implementation is different.