Support __proto__ in object literal (type-check only)

[Jack-Works]

related #38385
close #13933

Related:

https://tc39.es/ecma262/#sec-__proto__-property-names-in-object-initializers

tc39/ecma262#2125

Re-open of PR #42359

[typescript-bot]

The TypeScript team hasn't accepted the linked issue #13933. If you can get it accepted, this PR will have a better chance of being reviewed.

[DanielRosenwasser]

To be honest, I don't think we want the complexity of ever thinking about __proto__ in TypeScript. The corresponding issue received 2 votes over 5 years, so I don't think it would make sense to bring this change in.

[bakkot]

#39882 has another 11, from a mostly different set of people.

Anyway, while I think it's fair to not want to think about prototypes, it seems a shame to say that let x = { __proto__: null }; is forever going to be typed as an object with a __proto__ property of null, meaning that __proto__ is suggested in autocompletes and so on.

[Josh-Cena]

It's standard ECMAScript syntax, so even if we don't bring in the whole prototypical semantics, it should at least be special-cased to not mess with valid things like const map: Record<string, string> = { __proto__: null }

[Jack-Works]

This PR doesn't bring "prototype" into the type system. It will treat { __proto__: x, ...rest } as type typeof { ...x, ...rest }.

[sandersn]

@bakkot @Josh-Cena @Jack-Works can you make your case on an issue instead of on a PR? Changes to checker.ts, especially, bit-rot quickly and technical concerns get confused with semantics.

[sandersn]

To help with PR housekeeping, I'm going to close this PR while it's still waiting on its bug to be accepted. We can open again once that happens.