Skip to content

Conversation

@ChayimFriedman2
Copy link
Contributor

@ChayimFriedman2 ChayimFriedman2 commented Oct 23, 2025

The first commit remains unchanged. Only the second and third commits need review.

I verified that metrics do not regress anymore, and that r-a is usable in the editor.

Basically, we switch to expanding cfg_attr in AST form, filter irrelevant attributes from the item tree, and move hir-def attributes (non-item-tree) to be flag-based.

The main motivation is memory usage, although this also simplifies the code, and fixes some bugs around handling of `cfg_attr`s.
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 23, 2025
See the comment in the code. Previously it wasn't present because we were'nt stripping derives appearing before attribute macros, so we kept the derive and therefore the helper resolved as well. But we should strip the derives, as rustc does.
…value` attr

It caused the attribute macro to not be removed, causing it to be expanded again and again.

I don't know how to test this, as it's hard to test that the recursion limit was reached.
@ChayimFriedman2 ChayimFriedman2 marked this pull request as draft October 23, 2025 16:28
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 23, 2025
@ChayimFriedman2

This comment was marked as outdated.

And instead call `EditionedFileId::current_edition_guess_origin`, as most callers do it anyway.
@ChayimFriedman2 ChayimFriedman2 marked this pull request as ready for review October 23, 2025 16:46
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 23, 2025
@ChayimFriedman2 ChayimFriedman2 marked this pull request as draft October 27, 2025 22:40
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 27, 2025
@ChayimFriedman2
Copy link
Contributor Author

Weird, I now see on the metrics page that this regresses time and memory considerably. Don't merge this until I investigate that.

Comment on lines +225 to +236
.or_else(|| db.all_crates().first().copied())
.unwrap_or_else(|| {
// What we're doing here is a bit fishy. We rely on the fact that we only need
// the crate in the item tree, and we should not create an `EditionedFileId`
// without a crate except in cases where it does not matter. The chances that
// `all_crates()` will be empty are also very slim, but it can occur during startup.
// In the very unlikely case that there is a bug and we'll use this crate, Salsa
// will panic.

// SAFETY: 0 is less than `Id::MAX_U32`.
salsa::plumbing::FromId::from_id(unsafe { salsa::Id::from_index(0) })
});
Copy link
Member

Choose a reason for hiding this comment

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

Do we really need that previous change (making the function non-optional). Not too fond of this hack, this might populate queries that aren't necessary if this value makes it through. I am also not too happy with the sheer amount of hacks we are slowly accumulating.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What do you mean by "making the function non-optional"?

Copy link
Member

Choose a reason for hiding this comment

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

I meant 1671349

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants