What specific uses of def_path_str cause the infinite recursion?
Perhaps using something like with_reduced_queries will allow to break the recursion locally, and avoid global changes that this PR does.

Relevant - #154387, #154389.

This should really have a reviewer with a lot of query system experience.

r? @Zoxc

Failed to set assignee to zoxc: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

So the reason of this cycle was that this function wants to iterate over all free items, however they were not available during delayed lowering as it was executed before hir_crate_items(()), now delayed lowering is executed after hir_crate_items(()), and we use available-without-lowering information to fill hir_crate_items with information about delayed owners.

Next, there is one more problem in this function, which is maybe not that actual now, but it will be during supporting inherent impls, as during function resolution we will do coherence check, and in cases like:

struct X<T> { t: T }

// No generics provided
impl X {
  pub fn foo() {}
}

reuse X::foo;

we would still come to for_each_def function, but this time this line will be a problem, as we would call delayed lowering during resolution of delegation, so I stored identifier which is needed by this loop in delayed owners, as it once again information that can be accessed without lowering.

@rustbot ready

@rustbot ready
For perf.

@bors try @rust-timer queue

@bors try @rust-timer queue

☀️ Try build successful (CI)
Build commit: 50b5f1c (50b5f1c585b99753d3ee178835cb2ab226e8fd04, parent: 49b6ac01d6f4c3da812039ae846407a20961aa4c)

Finished benchmarking commit (50b5f1c): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

Max RSS (memory usage)

Cycles

Binary size

Bootstrap: 487.434s -> 486.33s (-0.23%)
Artifact size: 395.10 MiB -> 395.16 MiB (0.01%)

@rustbot ready
Removed fix related to hir_opt_ident, can retry perf.

@bors try @rust-timer queue

☀️ Try build successful (CI)
Build commit: 764186e (764186e460a9233c2345f4defb35b8e4332bdf1d, parent: 30d0309fa821f7a0984a9629e0d227ca3c0d2eda)

Finished benchmarking commit (764186e): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

Max RSS (memory usage)

Cycles

Binary size

Bootstrap: 489.264s -> 503.193s (2.85%)
Artifact size: 395.30 MiB -> 395.32 MiB (0.01%)

Those 5 regressions happened because hir_crate was called during hir_module_items, now it should be ok.