Skip to content

internal: A bunch of cleanups and micro-optimizations - #23197

Open
ChayimFriedman2 wants to merge 5 commits into
rust-lang:masterfrom
ChayimFriedman2:interneds-perf
Open

internal: A bunch of cleanups and micro-optimizations#23197
ChayimFriedman2 wants to merge 5 commits into
rust-lang:masterfrom
ChayimFriedman2:interneds-perf

Conversation

@ChayimFriedman2

Copy link
Copy Markdown
Contributor

Details in individual commits.

Reviewing commit-by-commit is recommended; the commits are fully separate.

Instead conjure it only when we initialize. This makes caller cleaner and also a micro-optimization since the initialization closure does not capture anything now.
…n_args_for_alias()`

It's not an optimization yet, but in the in-tree solver this function reuses the `GenericArgs` if the assoc has no args of its own.
And since `Projection::project()` does not require `DbInterner`, also remove this requirement from any slice's `new_from_iter()`, which is probably better anyway.
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 20, 2026

let interner = DbInterner::new_no_crate(db);
TYPES.get_or_init(|| {
let interner = DbInterner::conjure();

@nicolas-guichard nicolas-guichard Aug 21, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

DbInterner::conjure has the comment // FIXME(next-solver): remove this method and I see changes like #22119 which went the other way. Is this really desirable?

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I... don't know. It would be nice if we could remove it, but I doubt that. I believe it's the lesser evil.

}

#[inline]
pub(crate) fn new_from_slice_no_empty(slice: &[$ty_db]) -> Self {

@nicolas-guichard nicolas-guichard Aug 21, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd expect an assert!(slice.is_empty());, or when is it okay to call new_from_slice_no_empty with an actually empty slice?

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This method is intended specifically for empty ranges (mostly), since we need to intern them somewhere (see its callers).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Its closest caller just above calls it in the non-empty case and it's called no_empty. The logic looks right but the name is super confusing. I think something like new_from_slice_force_interned is clearer?

};
let create_generic_args = |slice| {
let ty = GenericArgs::new_from_slice(slice);
let ty = GenericArgs::new_from_slice_no_empty(slice);

@nicolas-guichard nicolas-guichard Aug 21, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The create_* functions are explicitly called with the empty slice below to pre-intern it. This is confusing.

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

If we call new_from_slice() here, it's deadlock since it accesses what we're interning here.

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.

3 participants