Skip to content

refactor: Lower type-refs before type inference #19462

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

Merged
merged 1 commit into from
Apr 9, 2025

Conversation

Veykril
Copy link
Member

@Veykril Veykril commented Mar 27, 2025

This PR refactors how we deal with items in hir-def lowering.

  • It now lowers all of them through an "ExpressionStore" (kind of a misnomer as this point) as their so called *Signatures.
  • We now uniformly lower type AST into TypeRefs before type inference.
  • Likewise, this moves macro expansion out of type inference, resulting in a single place where we do non-defmap macro expansion.
  • Finally, this PR removes a lot of information from ItemTree, making the DefMap a lot less likely to be recomputed and have it only depend on actual early name resolution related information (not 100% true, we still have ADT fields in there but thats a follow up removal).

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 27, 2025
@Veykril Veykril force-pushed the push-ypvprvvwkyll branch 11 times, most recently from 4d8191c to cd3b8db Compare April 3, 2025 08:04
@Veykril Veykril force-pushed the push-ypvprvvwkyll branch 3 times, most recently from 9fa36ff to 125d8c6 Compare April 4, 2025 11:23
@Veykril
Copy link
Member Author

Veykril commented Apr 4, 2025

CI is green for the first time 🎉 I did should_panic a couple of low bearing diagnostics tests though, figured I'll look into those more generally as a followup as the diagnostics part in hir is a bit of a mess to follow (that or maybe Chayim is already planning on cleaning that up with their related work there).

Gonna leave the history as is until reviews, then I'll squash. Might cleanup a couple things after, same for documentation, I'll do that as a follow up.

@Veykril Veykril marked this pull request as ready for review April 4, 2025 11:40
@Veykril Veykril force-pushed the push-ypvprvvwkyll branch 3 times, most recently from e09d309 to f29fc03 Compare April 5, 2025 08:34
Comment on lines +145 to +146
#[salsa::tracked]
fn enum_variants(&self, id: EnumId) -> Arc<EnumVariants> {
self.enum_variants_with_diagnostics(id).0
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I assume you changed this in the macro, but what does this do?

(Should we just define this this as a tracked method on EnumId instead?)

Copy link
Member Author

Choose a reason for hiding this comment

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

It's just shorthand syntax. Instead of having to create a a function and pointing to it wtih invoke_actual this allows writing that inline. Its basically just salsa::tracked but written as part of the trait here

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, gotcha. We can probably replace a lot of usages of invoke_actual with this, I think!

Copy link
Contributor

@ChayimFriedman2 ChayimFriedman2 left a comment

Choose a reason for hiding this comment

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

I reviewed the changes (although I didn't look at the newest changes deeply), looks good! Commented a few nits.

@@ -515,10 +340,8 @@ pub enum AttrOwner {
TopLevel,

Variant(FileItemTreeId<Variant>),
// while not relevant to early name resolution, fields can contain visibility
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this a reason to include them in the item tree? Can't we resolve visibilities from signatures?

Copy link
Member Author

Choose a reason for hiding this comment

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

I was asking myself that earlier when I stumbled upon this again. Pretty sure this can go as well. I assume I put that comment there due to a misunderstanding. Will turn that into a FIXME

#[salsa::invoke_actual(TraitAliasData::trait_alias_query)]
fn trait_alias_data(&self, e: TraitAliasId) -> Arc<TraitAliasData>;
#[salsa::tracked]
fn variant_fields(&self, id: VariantId) -> Arc<VariantFields> {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not saying you should do it in this PR, but maybe it is time to consider making those return references?

Copy link
Member Author

Choose a reason for hiding this comment

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

Absolutely. There is a lot of Arcs we should be able to drop now in one swoop. I kept using Arcs everywhere for now as to not do even more work in this PR.

@Veykril Veykril force-pushed the push-ypvprvvwkyll branch 2 times, most recently from 9777fbb to b2ed56f Compare April 6, 2025 09:10
@@ -276,153 +266,6 @@ m!();
);
}

#[test]
fn mod_paths() {
Copy link
Contributor

Choose a reason for hiding this comment

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

i'm not sure i see these tests moved elsewhere—do we just not need these anymore, or...?

Copy link
Contributor

Choose a reason for hiding this comment

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

They test things that are removed from the item tree.

Copy link
Contributor

@ChayimFriedman2 ChayimFriedman2 left a comment

Choose a reason for hiding this comment

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

I reviewed the newer commits. Left a few nits.

@Veykril Veykril force-pushed the push-ypvprvvwkyll branch from 3990cc6 to e3633c3 Compare April 9, 2025 08:12
@Veykril
Copy link
Member Author

Veykril commented Apr 9, 2025

Alright, will squash once CI goes green and then merge

@Veykril Veykril force-pushed the push-ypvprvvwkyll branch from e3633c3 to 3ee9346 Compare April 9, 2025 08:25
@Veykril Veykril force-pushed the push-ypvprvvwkyll branch from 3ee9346 to 95dce5a Compare April 9, 2025 08:42
This refactors how we deal with items in hir-def lowering.

- It now lowers all of them through an "ExpressionStore" (kind of a misnomer as this point) as their so called *Signatures.
- We now uniformly lower type AST into TypeRefs before type inference.
- Likewise, this moves macro expansion out of type inference, resulting in a single place where we do non-defmap macro expansion.
- Finally, this PR removes a lot of information from ItemTree, making the DefMap a lot less likely to be recomputed and have it only depend on actual early name resolution related information (not 100% true, we still have ADT fields in there but thats a follow up removal).
@Veykril Veykril force-pushed the push-ypvprvvwkyll branch from 95dce5a to 1fd9520 Compare April 9, 2025 08:43
@Veykril Veykril enabled auto-merge April 9, 2025 08:43
@Veykril Veykril added this pull request to the merge queue Apr 9, 2025
Merged via the queue into rust-lang:master with commit dc363f7 Apr 9, 2025
14 checks passed
@Veykril Veykril deleted the push-ypvprvvwkyll branch April 9, 2025 09:06
@Veykril
Copy link
Member Author

Veykril commented Apr 9, 2025

This did reduce memory usage on self by ~160mb, but it also regressed with unknown types in inference. I imagine this PR regressed some support for const arguments in types.

ChayimFriedman2 added a commit to ChayimFriedman2/rust-analyzer that referenced this pull request Apr 18, 2025
That is, all queries that have a `with_diagnostic` variant.

Them being tracked was (maybe) needed before rust-lang#19462, because back then diagnostics could refer `AstId`s (for macro types), but now they are no longer needed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants