Bump salsa

[Veykril]

No description provided.

[Veykril]

Oh ... we can't actually bump this because it would need SyntaxContext to change to a u64 I think which is a breaking change for the proc-macro RPC API

[ChayimFriedman2]

Yeah there is also a problem with placeholders which are u32 but need to be transmuted into salsa::Id.

[Veykril]

Actual, syntax context isnt really an issue, as we can (and already are) fall back to the TokenId server model.

[ChayimFriedman2]

Even with the larger IDs, this PR still ends up a net positive to memory usage (54mb on self). I believe it's due to salsa-rs/salsa#888 (but it is unrelated to the larger ID, so we could have an even larger save).

[Veykril]

Really? From what I saw this regresses memory by ~100 mb

[ChayimFriedman2]

How did you measure? I measured on Linux with jemalloc.

[Veykril]

I compared the CI runs for analysis-stats from this PR and the parent merge of this PR

[ChayimFriedman2]

I compared the CI runs for analysis-stats from this PR and the parent merge of this PR

???

CI analysis-stats for this PR does not even pass compilation...

[Veykril]

oh wait I mixed this up with my other PR lol, I did try this locally nevermind 😅 Maybe I made a mistake when switching revisions for comparison if your results are that different

[Veykril]

Wait if you tried this yourself, I assume you also had to fix up some dependencies in salsa right? Cause right now we have a dependency conflict with the new salsa. If you haven't then you didn't test the correct thing.

[ChayimFriedman2]

Yes I did. I just removed Cargo.lock and let Cargo regenerate it.

[Veykril]

okay so the generational index stuff is resolved, we are now marking the 3 interneds that we drop the generation of as eternal so cutting the generation won't cause problems

[Veykril]

That test failure is not good, I can't reproduce that on windows ... any mac users here?

[Veykril]

There is a couple of queries being recomputed here which seems odd. I think this might be ast id collisions happening on mac only ...

[davidbarsky]

That test failure is not good, I can't reproduce that on windows ... any mac users here?

Yeah, I can check in a few hours.

[davidbarsky]

There is a couple of queries being recomputed here which seems odd. I think this might be ast id collisions happening on mac only ...

I think the test failures are also on Linux: https://github.com/rust-lang/rust-analyzer/actions/runs/15923806642/job/44916411005?pr=19923. However, GitHub Actions is reporting that as a cancelled, not failed, action.

[Veykril]

Cool, so the test fails on CI on all targets, but not for me locally 🙃

[Veykril]

Okay, the issue is in fact an AstId collision. Now I am unsure why that happens only on CI though, there is nothing environment specific in that code.

[Veykril]

Welp, I have no idea why the ast id is unstable and I am unable to reproduce this locally at al.

        "DidReuseInternedValue { key: StructId(Id(3000g1)), revision: R6 }",
        "DidDiscard { key: struct_signature_shim(Id(3000g1)) }",
        "DidDiscard { key: struct_signature_with_source_map_shim(Id(3000g1)) }",
        "DidDiscard { key: generic_predicates_shim(Id(3000g1)) }",
        "DidDiscard { key: value_ty_shim(Id(3000g1)) }",
        "DidDiscard { key: VariantFields::firewall_(Id(3000g1)) }",
        "DidDiscard { key: VariantFields::query_(Id(3000g1)) }",
        "DidDiscard { key: adt_variance_shim(Id(3000g1)) }",
        "DidDiscard { key: variances_of_shim(Id(3000g1)) }",
        "DidDiscard { key: type_for_adt_tracked(Id(3000g1)) }",

Specifically this part should not be happening, we are evicting the interned StructLoc here because its hash must've changed which is why I believe the AstId has collided.

[Veykril]

I disabled the garbage collection for interneds for now as they make our incremental tests fail (due to immediately garbage collecting).