LSP Panic: access to field whilst the value is being initialized

[MichaReiser]

Summary

LSP[ty] ty encountered a problem. Check the logs for more details.
lsp_signatur handler RPC[Error] code_name = InternalError, message = "request handler panicked at /Users/runner/.cargo/git/checkouts/salsa-e6f3bb7c2a062968/d66
fe33/src/tracked_struct.rs:912:21:\
access to field whilst the value is being initialized\
run with `RUST_BACKTRACE=1` environment variable to display a backtrace\
"

This is a bug in Salsa

Version

No response

[MichaReiser]

This normally suggests that we access a tracked struct that has been deleted. I'm not entirely sure how we'd end up here other than that it's probably something, something fixpoint. @ibraheemdev do you have any idea why this might happen?

This might be salsa-rs/salsa#969 (comment)

[MichaReiser]

I think the reason this could be an issue for cycle heads only is that we never back date queries that have cycle heads (that is, queries that participated in a cycle but aren't the head). That means, any query dependent on those re-executes and sees any newly created tracked struct.

[MichaReiser]

Okay, I think I have a fix for this. It's not related to my refactors (but I did discover something else that I broke).

I believe the issue is that deep_verify_memo might return unchanged for a provisional memo from a previous iteration. This seems wrong, at least if the cycle heads weren't finalized. Or we, at least, need to propagate the cycle heads because we may not hit the same cycle heads during verification

[MichaReiser]

There might be two reasons why this happening:

1. We access a tracked struct that was removed due to when salsa runs diff_outputs for queries participating in a cycle: fix: diff outputs for queries participating in a cycle salsa-rs/salsa#980

2. I don't have a repro for the second case yet but let's say we have the following query:

a -> b
  -> d(b.x) (reads interned returned by b)

b -> c
  -> interns x

c -> a

The execution is as follow when a is the entry point:

• maybe_changed_after(a) -> deep_verify_memo(a)
• maybe_changed_after(b) -> deep_verify_memo(b)
• maybe_changed_after(c) -> deep_verify_memo(c)
• return fixpoint initial for a (unchanged)
• maybe_changed_after(x)
• maybe_changed_after(d(b.x)) -> deep_verify_memo(d(b.x)) (locks b.x)

However, if Salsa now calls into b first, the execution is:

• maybe_changed_after(b) -> deep_verify_memo(b)
• maybe_changed_after(c) -> deep_verify_memo(c)
• maybe_changed_after(a) -> deep_verify_memo(a)
• return fixpoint initial for b (unchanged)
• maybe_changed_after(d(b.x)) -> deep_verify_memo(d(b.x)) this panics because b.x hasn't been verified (we haven't fully walked bs dependencies yet)

The crucial difference to non-cyclic queries is that cyclic queries aren't guaranteed to form a tree; they can form a graph where different queries depend on each other's results from different iterations. The challenge with this is that maybe_changed_after is order sensitive AND it's not guaranteed that maybe_changed_after is guaranteed to be called on the same cycle head as when the value was computed in the last revision.

I'm not sure if it would be okay to just call maybe_changed_after on the memo's `cycle heads from the last revision. I'd have to double-check if we don't run into any ordering issues

[MichaReiser]

I'm starting to consider rewriting the fix point implementation to store a separate memo for each iteration instead of aggregating the results of all iterations into a single Memo. The aggregation adds a fair amount of complexity and I suspect that things like validate_same_iteration could become much easier if we have separate memos.

Separate memos would also guarantee that maybe_changed_after remains a tree walk and not a graph traversal as it is today. It may even allow us to enable backdating for queries participating in cycles and verifying them eagerly in maybe_changed_after.

We did discuss this a bit in today's salsa meeting: #Contributing to Salsa > 2025-08-20 meeting @ 💬

One challenge that I see with this is how to store multiple memo's on a single argument: From my conversation with @ibraheemdev

the memos are type-erased, so I think you could store a different type of memo for cycle queries that included multiple iterations

oh, like a super memo that has a boxcar vec with the memos of each iteration?

something like that yeah

[MichaReiser]

Notes from another salsa meeting where we discussed how to fix this https://hackmd.io/L5wDAaqySqacXH1_yzwzXw

[MichaReiser]

Some more notes: https://hackmd.io/@michareiser/S11NEQ6pll

[AlexWaygood]

Some more notes: hackmd.io/@michareiser/S11NEQ6pll

😢