satisfies in JSDoc

#51753

• Provides a contextual type in JavaScript without casting or calling a helper function - really nice.
• It's unfortunate that @type was used as the original name for JSDoc type assertions. @type would have been a better syntax for what satisfies does.
  • Or @cast and @satisfies, and @type just stays on declarations.
• But if you know you want to use satisfies
• How should this work?
  • Expression positions the same way @type works seems fine.
  • What about declaration forms? Lots of examples of @type or @param.
    • We would like @satisfies to also work in declaration positions - enforce the assignability check on, and also contextually type, the initializer expression(s?).

Optimizations

• Nice wins from monomorphizing our object types.
  • Node (Reduce polymorphism resulting from unstable Node shapes #51682) and Symbol (Monomorphic Symbol access #51880)
• What's next?
  • Can still do this for Signature, Type, more.
• Experimenting with removing the notion of object allocators (our factory for node classes).
• Slight aside - some difficulties with polymorphism analysis tooling due to esbuild renaming.
• Fixed shapes for FlowNodes?
  • [experiment] Try using consistent shapes for FlowNodes #51585
  • Should retry once the deopt tooling is available.
  • Also, harder to analyze because they're just object literals.
    • Analysis works better when the allocation site consistently comes from a constructor. (e.g. new Blah(), etc.)
  • We sort of do this with FlowNode
    • But we still set properties after the fact.
• We ran a deopt analysis on the compiler during the meeting. We saw some interesting things.
  • writeFile is 16% of the time??? (MS Defender????)
  • 600ms on ts namespace - but it has almost no code???
    • const enum preservation?
      • That's nuts.
      • Tradeoff for debuggability.
    • Suspicious.
  • emitFlags is never set, so an |= can't be immediately optimized.
    • We could just set it to 0?