internal: Build source map for hir_def::TypeRefs

[ChayimFriedman2]

So that given a TypeRef we will be able to trace it back to source code.

This is necessary to be able to provide diagnostics for lowering to chalk tys, since the input to that is TypeRef. This is the first step towards diagnostics for ty lowering. The next steps will be smaller :P

This means that TypeRefs now have an identity, which means storing them in arena and not interning them, which is an unfortunate (but necessary) loss but also a pretty massive change. Luckily, because of the separation layer we have for IDE and HIR, this change never crosses the IDE boundary.

This gives an unfortunate regression of ~170mb in analysis-stats ..

Sorry for the size of the PR; I did some extra things but they are trivial - most of the code is necessary and impossible to split.

[bors]

☔ The latest upstream changes (presumably #18075) made this pull request unmergeable. Please resolve the merge conflicts.

[ChayimFriedman2]

Okay, this is ready for review.

I intend to submit a follow-up PR with few cleanups that I don't want to insert here to not increase the size of this already-large PR.

[Veykril]

This gives an unfortunate regression of ~170mb in analysis-stats ..

Whew that's quite a bit 😞 Wonder if we can shrink TypeRef some more (its 40 bytes on master)

[Veykril]

Aside: I imagine we might wanna give lifetimes the same treatment (given they also only appear in type position anyways)

[Veykril]

I guess part of the memory increase comes from the new source map queries not being LRU'd. Gonna think a bit aabout whether we can reduce the memory impact of this change to some degree (aside from LRUing those queries)

[lnicola]

Can we make block_item_tree etc. transparent to save some memory? Because block_item_tree_query just calls block_item_tree_with_source_map now.

[Veykril]

The split exists for incrementality purposes, and making that one transparent won't really save much given it just clones the Arc

[ChayimFriedman2]

If anything, it's the opposite: we can make the source maps query transparent (not just this one), since everyone that wants the source map is not perf-sensitive (IDE layer).

[ChayimFriedman2]

I guess part of the memory increase comes from the new source map queries not being LRU'd

What is the difference between LRU'd and not LRU'd queries?

[ChayimFriedman2]

I'll try to find how each type consumes memory, and as a result of this analysis what can we do to shrink it.

[Veykril]

I guess part of the memory increase comes from the new source map queries not being LRU'd

What is the difference between LRU'd and not LRU'd queries?

LRU'd ones will just have their caches evicted if they overflow the LRU limit (up to the limit).

[ChayimFriedman2]

@Veykril Adding #[salsa::lru] around the source map queries does not help analysis-stats . at all (neither it makes it worse, though). I'll explore other ways. Should I still LRU them?