Infer recursive types through object literal getters

[Colin McDonnell (colinhacks)]

Fixes #62181. Fixes #62180. Refs #64192.

Problem

const node = object({
  name: text(),
  get children() {
    return array(node);
  },
});

On main this reports TS7022 on node and TS7023 on children. With this change it reports nothing, and sample.children[0].children[0].name is string. The hover in #62181 changes from (accessor) parent: any to the recursive type.

Issue #62180 has the same cause. Its symptom is TS2741: Property 'out' is missing on an inherited member. Both are fixed here. Fixing either one alone makes the other worse.

Cause

Before it walks the base types, resolveObjectTypeMembers publishes the table of the type's own declared members as a recursion guard. Any lookup inside that window sees the inherited members as missing. Two defects come from this, and they need opposite fixes.

Inference. When an inferred candidate is checked against its constraint, the comparison walks every property of the source. An un-annotated getter gets its type from its body, so walking it re-enters a declaration that is still being resolved. The circularity is an artifact of the comparison, but it still gets reported and cached.

Publication. A member lookup that runs inside the window doesn't find the inherited members, and the caller treats them as absent.

Change

When compareProvisionally is entered it records the current depth of typeResolutions. If pushTypeResolution then finds a cycle whose start is below that mark, it throws a private sentinel. The site that forced the member, tryGetTypeOfMember, catches it, restores the checker stacks, and reports the member as unanswerable.

The unwind happens before anything is computed from the circular value, so there is no diagnostic to suppress, no placeholder type, no cache write to journal, and nothing to retract. An earlier draft did all four and came to 513 lines.

The unwind has two consequences. Each has a test that fails without it.

• A comparison that skipped an unanswerable member can accept a candidate but can't reject one, and a success isn't written to the relation cache, since that cache outlives the state the skip depended on.
• If the unwind crosses the publication window, the type in flight would be left with MembersResolved set and only its own members in the table. So resolveStructuredTypeMembers clears the flags on the way out.

For the publication defect, resolveObjectTypeMembers pushes the base types it is about to inherit from before it starts. A lookup that misses inside the window then checks those bases and returns the member the table is about to get anyway. If a lookup re-enters through the type in flight, its record is already marked as being consulted, so it falls back to the published table, which is the same view the inheritance loop itself has.

Gating on provisionalDepth

The right answer for a miss in the window depends on the caller. Inside a provisional comparison, completing the lookup against the bases would force the type the comparison is asking about. Outside one, the miss just means the lookup ran too early, and completing it is correct. So the completed lookup only runs when provisionalDepth == 0. Inside a provisional region a narrower rule applies instead. A getUnmatchedProperty miss is treated as "not resolved yet" rather than "absent", but only when some base declares that name. That check, mayInheritProperty, reads declaration tables and doesn't force any member type. It isn't completely free of side effects, since resolving a class's base list can force its heritage expression. But that is the resolution the window is already inside, and the resolution stack guards it.

The table below is measured on a corpus of probe files that reduce the shapes this affects. The count is of errors that ask for an annotation the user can't write (TS7022, TS7023, TS2502).

	lines	errors demanding an annotation
main	—	76
publication fix alone	59	78
inference fix alone	269	0
both, ungated, one answer everywhere	292	5
both, ungated, suppression restored	327	3
this PR	331	0

The publication fix on its own makes inference slightly worse. Without the gate it brings back the collapse on plain mutual recursion (get posts() { return array(post); }) in three files, because completing the lookup forces posts in the middle of inference. Dropping the suppression instead adds fifteen errors.

Tests

There are fifteen conformance cases with baselines. They cover the recursive type and the different ways it gets written, mutual recursion, the postponed constraint and the same constraint split across two files, declaration emit, union recursion in both member forms, reverse mapped inference, and a stricter variant of the shape in #62180. The fourslash fixture is the code from #62180 verbatim.

Five of them behave the same as main and exist to pin that: overload resolution across an unresolved accessor, in both generic and plain signatures; a skipped accessor's constraint error still being reported; a property that really is absent still being reported as absent; and the same on the speculative path. Each of these caught a real bug during development.

The flow-loop case, recursiveTypeThroughObjectLiteralGetterFlowLoop.ts, covers the stack rollback. Its getter body runs a loop and assigns to a union-typed variable, which forces the inner getter from a loop back-edge. Since checkExpressionCachedEx swaps in a nil flowLoopStack and only restores the real one on normal return, an unwind that crosses it has to put the saved stack back rather than re-slice the replacement. If it doesn't, the checker crashes.

The mutual case, recursiveTypeThroughObjectLiteralGetterMutual.ts, is the only test in the suite that reaches the gate. To get there it needs two schemas that name each other through getters, plus two key remappings over the same shape, one on each variance side, each keyed on a different member of the internals. With only one remapping every candidate in the table passes and the gate never matters. Thirteen hand-written cases and the whole corpus missed this. The case is reduced from a real failure.

Every case that asserts a resolved type also reads a key that doesn't exist, behind a @ts-expect-error. On main that directive is reported as unused.

There are five fourslash cases. Two are #62181, one of which checks that the diagnostics are the same whether or not a hover was requested first. The other three check postponed-constraint reporting across different file open orders. One of them never opens the file that has the error.

Cost

All 63 packages under go test ./internal/... pass. No existing reference baseline changes; the only baseline changes are the cases added here.

Code that doesn't hit the pattern is unaffected. The --extendedDiagnostics counters below are the same on every run.

	main	this change
SolidJS, own tsconfig.json — Symbols / Types / Instantiations	172,602 / 829,217 / 1,235,646	identical
fumadocs, packages/core	263,300 / 60,583 / 212,832	identical

On the probe corpus, which does hit the pattern:

	main	this change
Symbols	39,234	40,039 (+2.1%)
Types	8,403	9,283 (+10.5%)
Instantiations	14,281	19,062 (+33%)

The increase is mostly types that collapsed to any on main and now resolve.

I couldn't measure a wall-clock difference. Interleaved runs on the inference-heavy projects give an effect that changes sign from run to run, and control runs of the same binary against itself move by as much as the measured effect.

I compiled 498 projects with both compilers and compared the full diagnostic text. Each was compiled twice on main first, because three or four of them are nondeterministic there.

identical diagnostics	496
differ	1
excluded as nondeterministic on main	4

The one that differs is the probe corpus. The declarations that asked for an annotation on main now infer.

Effect on Zod

Zod replaces its real constraint with a loose structural one at 296 sites, because with the real constraint inference through a getter fails and the schema collapses to any.

This commit removes all 296 and puts the real constraint back at every site. On main that version of the library reports 189 errors, and 167 of them are declarations that need an annotation, getters that need a return type, and the constraint failures that follow once those collapse. With this change all 167 are gone. The remaining 22 are unused symbols and a missing @types/node in that checkout. The recursive schemas in that library cover recursion through a union, a union of one, a discriminated union, mutual recursion, recursive tuples, cyclic data and z.lazy.

Scope

The unwind can only be reached from a provisional comparison. The 498-project comparison and the unchanged counters above agree with that.

One shape isn't fixed, and there is a test for it. When the parameter is a mapped type over the inferred type, so that inference goes through a reverse mapped type, the declaration doesn't resolve on main or with this change. The test, recursiveTypeThroughObjectLiteralGetterReverseMapped.ts, asserts that both report the same errors. A provisional comparison explores further than an ordinary check does, and that must not show up as an extra diagnostic.

Other than that I don't know of a remaining failure. That is measured against the conformance and fourslash suites, the 498 projects, and Zod with every workaround removed.

---

Disclosure: this patch was authored with AI assistance (Claude Code). I have read and understood the result and will discuss and revise it in review.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.