-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
internal: Build source map for hir_def::TypeRef
s
#18074
base: master
Are you sure you want to change the base?
internal: Build source map for hir_def::TypeRef
s
#18074
Conversation
☔ The latest upstream changes (presumably #18075) made this pull request unmergeable. Please resolve the merge conflicts. |
9af921a
to
3c34665
Compare
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. |
hir_def::TypeRef
shir_def::TypeRef
s
Whew that's quite a bit 😞 Wonder if we can shrink |
} | ||
|
||
/// A single generic argument. | ||
#[derive(Debug, Clone, PartialEq, Eq, Hash)] | ||
pub enum GenericArg { | ||
Type(TypeRef), | ||
Type(TypeRefId), | ||
Lifetime(LifetimeRef), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside: I imagine we might wanna give lifetimes the same treatment (given they also only appear in type position anyways)
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) |
Can we make |
The split exists for incrementality purposes, and making that one transparent won't really save much given it just clones the |
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). |
What is the difference between LRU'd and not LRU'd queries? |
I'll try to find how each type consumes memory, and as a result of this analysis what can we do to shrink it. |
LRU'd ones will just have their caches evicted if they overflow the LRU limit (up to the limit). |
@Veykril Adding |
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 means that `TypeRef`s 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.
3c34665
to
9a2a0a2
Compare
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 :PThis means that
TypeRef
s 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.