Port TypeScript#62676: Fix slow sync iteration types spoiling cached async iteration types

[Copilot]

When a type implements both Iterable<T_Sync> and AsyncIterable<T_Async>, the sync slow resolution path could cache results before the async slow path ran, causing for await loops to incorrectly yield the sync type parameter instead of the async one.

type Stream<T_Sync, T_Async> = Iterable<T_Sync> & AsyncIterable<T_Async>;

async function loop(stream: Stream<A, B>) {
  for await (const b of stream) {} // b was incorrectly typed as A instead of B
}

• Move getIterationTypesOfIterableSlow calls inside their respective fast-check blocks so async slow resolution always completes before sync slow resolution runs, preventing cache poisoning

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[jakebailey]

Hm, this does nothing. Maybe we avoid the problem entirely now?

[jakebailey]

microsoft/TypeScript#62676

Probably worth pulling, just because this probably is an ordering thing we now just so happen to avoid in this case, but not others

[Copilot]

Pull request overview

Ports TypeScript#62676 to the Go checker to ensure for await...of prefers AsyncIterable iteration types over sync fallbacks, avoiding incorrect cached results when a type supports both sync and async iteration.

Changes:

• Reorders getIterationTypesOfIterableWorker resolution so async slow-path resolution completes before any sync-path fallback.
• Shares a single diags slice across the async/sync slow paths for related diagnostic info.

[DanielRosenwasser]

No test?

[jakebailey]

See above; this is type order dependent. I don't think I can effectively come up with something that walks this in just the right order to cause the problem again without a lot of effort...

[DanielRosenwasser]

Probably worth pulling, just because this probably is an ordering thing we now just so happen to avoid in this case, but not others

But I don't understand how it's union-order dependent, but

1. Had no diffs with Strada
2. Doesn't introduce diffs with Strada

I also don't know which union it is depending on - this seems to be more about intersections, right?

[jakebailey]

@copilot come up with a test that fails in the Go code before this fix (revert the change locally and keep testing, restore afterward), based on the upstream PR.

Work on this for a while, but if you can't find something, you can give up and say so.

[Copilot]

@copilot come up with a test that fails in the Go code before this fix (revert the change locally and keep testing, restore afterward), based on the upstream PR.

Work on this for a while, but if ...

I spent a while trying to construct a failing test and wasn't able to find one. Here's why:

The original TS bug is caused by type-level caching via setCachedIterationTypes/getCachedIterationTypes, which caches iteration types directly on the Type object under keys like "iterationTypesOfIterable" and "iterationTypesOfAsyncIterable". The sync slow path would call setCachedIterationTypes(type, resolver.iterableCacheKey, ...) and cache sync iteration types under the sync key. Then when the async slow path ran, it could find stale cached types on the type from a previous sync-only resolution (e.g., a for...of call before a for await...of call on the same type).

The Go code never ported this type-level caching mechanism. Instead, it uses a single centralized iterationTypesCache map keyed by (typeId, use & CacheFlags). Since for...of (AllowsSync|ForOf) and for await...of (AllowsSync|AllowsAsync|ForOf) produce different cache keys, they never share cached results. The getIterationTypesOfIterableFast and getIterationTypesOfIterableSlow functions in Go are pure — they don't read or write any per-type cache.

Because neither the fast nor slow paths in Go have side effects that could affect each other, the ordering change from this PR is a no-op for all current code paths. I verified this by reverting the fix, running the upstream forAwaitForIntersection1 test, and regenerating baselines — the output is identical with and without the fix.

The structural change is still correct to port for parity with TS, but I cannot produce a test that fails before the fix in the current Go codebase.

[DanielRosenwasser]

So is there no test diff removal because we haven't updated the submodule? Therefore, there's nothing being tested?

[jakebailey]

No, the test exists, it just doesn't have a diff because the differing caching system prevented it entirely.

So now it's just down to whether or not the code style is better / if it should match. Which, I think it should.