Skip to content

Fixed an issue with ReduceLabel flows spoiling node reachability cache#61265

Closed
Andarist wants to merge 4 commits intomicrosoft:mainfrom
Andarist:fix/reduce-label-spoiling-reachability-cache
Closed

Fixed an issue with ReduceLabel flows spoiling node reachability cache#61265
Andarist wants to merge 4 commits intomicrosoft:mainfrom
Andarist:fix/reduce-label-spoiling-reachability-cache

Conversation

@Andarist
Copy link
Copy Markdown
Contributor

@Andarist Andarist commented Feb 25, 2025

fixes #61259
fixes #63004

const saveAntecedents = target.antecedent;
target.antecedent = (flow as FlowReduceLabel).node.antecedents;
const result = isReachableFlowNodeWorker((flow as FlowReduceLabel).antecedent, /*noCacheCheck*/ false);
const result = isReachableFlowNodeWorker((flow as FlowReduceLabel).antecedent, FlowNodeReachableCacheFlags.None);
Copy link
Copy Markdown
Contributor Author

@Andarist Andarist Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as the comment in this block says:

// Cache is unreliable once we start adjusting labels

We can't let this isReachableFlowNodeWorker call here to populate the cache as that would create entries based on the temporary antecedent(s). Anything computed below this call can't be preserved, at least not without including the id of this ReduceLabel flow in the cache key or smth.

So this disables cache writes. As later on that would be used on the same shared flow but with "correct" antecedents (and that's the only result the compiler should cache and trust).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still considering 2 things here:

  • should this code maybe save & restore flowNodeReachable[getFlowNodeId(target)]?
  • should reads be permanently disabled here? this would make the previous consideration obsolete

I have not been able to produce a test case that would prove either to be required so far but I have only spent a little bit of time on it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @ahejlsberg who has been thinking about this sort of thing recently and I believe had ideas on how to simplify the flow node logic here

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, Corsa still suffers from this (checked at microsoft/typescript-go@a92eff4 )

@Andarist Andarist force-pushed the fix/reduce-label-spoiling-reachability-cache branch from 2a860e8 to 4552c20 Compare February 25, 2025 15:12
@typescript-bot typescript-bot added the For Backlog Bug PRs that fix a backlog bug label Jan 18, 2026
@typescript-bot
Copy link
Copy Markdown
Collaborator

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

  • For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
  • Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
  • Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

For Backlog Bug PRs that fix a backlog bug

Projects

Status: Done

3 participants