Problem

The JSG_TS_OVERRIDE, JSG_TS_DEFINE, JSG_STRUCT_TS_OVERRIDE, and JSG_STRUCT_TS_DEFINE macros stringify their varargs via JSG_STRING_LITERAL, a two-step helper that expands macro identifiers in the argument before stringification.

On Darwin, <stdio.h> defines stdin, stdout, and stderr as preprocessor macros (__stdinp, __stdoutp, __stderrp). Override blocks containing those identifiers are silently corrupted in the stringified TypeScript:

JSG_TS_OVERRIDE({ readonly stdin: WritableStream | null });
// macOS: "{ readonly __stdinp: WritableStream | null }"
// Linux: "{ readonly stdin: WritableStream | null }"

This is observable in src/workerd/api/container.h, where the ExecOptions and ExecProcess overrides reference these names. The platform divergence breaks bazel run //types for downstream consumers building on macOS — the generated worker-configuration.d.ts differs from the Linux-built committed snapshot.

Fix

Stringify directly with #__VA_ARGS__ at the outermost macro that captures the user's tokens, rather than forwarding through JSG_STRING_LITERAL. Single-step stringification doesn't trigger preprocessor expansion of the argument tokens.

JSG_STRING_LITERAL is preserved in macro-meta.h (it is still used by edgeworker/server/async-signal-debug.h for variable-name logging where two-step semantics are harmless). Its doc comment now warns against using it for user-supplied source-code blocks and points readers at the correct pattern.

Testing

Added a regression test (KJ_TEST("typescript macros with stdio identifiers") in rtti-test.c++) that asserts override and define blocks containing stdin/stdout/stderr survive stringification verbatim. Verified on macOS that:

• The new test fails with the bug present, passes with the fix applied.
• bazel test //src/workerd/jsg:all — 46/46 pass.
• bazel build //types — generated experimental and latest types match the committed Linux snapshot exactly (diff -r types/generated-snapshot/ bazel-bin/types/definitions/ is empty).