Stuck on the call to `def_path_str`

[xizheyin]

In rustc, I added one line of code between L754 and L755

rust/compiler/rustc_resolve/src/late/diagnostics.rs

Lines 754 to 755 in 84f67a5

	let source_map = self.r.tcx.sess.source_map();
	// check if the field is used in a format string, such as `"{x}"`

I added this code

                            tracing::info!("macro_def_id: {:?}", self.r.tcx.def_path_str(span.ctxt().outer_expn_data().macro_def_id.unwrap()));

And I build it using:

./x build --stage 1

And run it on this code by rustc +stage1 xxx

struct Foo {
    x: i32
}

impl Foo {
    fn foo(&self) {
        let _ = format!("{x}"); //~ ERROR cannot find value `x` in this scope [E0425]
    }
}

fn main(){}

I expected to see this happen:

it print something

Instead, this happened:

It stucked

Meta

rustc --version --verbose:

rustc 1.89.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.89.0-dev
LLVM version: 20.1.5

Backtrace

<backtrace>

[compiler-errors]

Have you tried looking into the stack with gdb?

[bjorn3]

I think the problem here is that def_path_str as part of the path trimming functionality depends on name resolution info that is being computed at the point you are calling def_path_str, thereby causing infinite recursion.

[xizheyin]

Have you tried looking into the stack with gdb?

No, I haven't had a chance to try gdb yet.

I think the problem here is that def_path_str as part of the path trimming functionality depends on name resolution info that is being computed at the point you are calling def_path_str, thereby causing infinite recursion.

Is this one as expected? Or is it a bug?

[bjorn3]

It is not a bug at least.