Stack overflow when using recursive type and conditions

[supersurviveur]

Summary

Using recursive type with conditions leads to a stack overflow.

To reproduce :

use std::marker::PhantomData;

trait Group {
    type ExposantSet: Group;
}

struct Pow<T: Group> {
    exposant: Box<Pow<T::ExposantSet>>,
    _p: PhantomData<T>,
}

impl<T: Group> Pow<T> {
    fn is_zero(&self) -> bool {
        false
    }
    fn normalize(&self) {
        if self.is_zero() {
        } else if false {
        }
    }
}

Removing the else if condition make the bug disappear.

Version

rustc 1.89.0-nightly (ce7e97f73 2025-05-11)
binary: rustc
commit-hash: ce7e97f7371af47e0786f74aa169f6ac9473ff4e
commit-date: 2025-05-11
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.4

Error output

thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow, aborting
warning: `formalith` (bin "formalith") generated 3 warnings
error: could not compile `formalith` (bin "formalith"); 3 warnings emitted

Caused by:
  process didn't exit successfully: `/home/julien/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/clippy-driver /home/julien/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc --crate-name formalith --edition=2024 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=159 --crate-type bin --emit=dep-info,metadata -C embed-bitcode=no -C debuginfo=2 --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=a142a0962d0a3e76 -C extra-filename=-a5c1622c0424deeb --out-dir /home/julien/code/test_rust/target/debug/deps -C incremental=/home/julien/code/test_rust/target/debug/incremental -L dependency=/home/julien/code/test_rust/target/debug/deps` (signal: 6, SIGABRT: process abort signal)

[supersurviveur]

Clippy seems to loop forever in interior_mut_ty_chain here :

rust-clippy/clippy_utils/src/ty/mod.rs

Lines 1172 to 1180 in 010c2d3

	if is_std_collection || def.is_box() {
	// Include the types from std collections that are behind pointers internally
	args.types().find_map(|ty| self.interior_mut_ty_chain(cx, ty))
	} else if self.ignored_def_ids.contains(&def.did()) || def.is_phantom_data() {
	None
	} else {
	def.all_fields()
	.find_map(|f| self.interior_mut_ty_chain(cx, f.ty(cx.tcx, args)))
	}

[profetia]

@rustbot claim

[profetia]

I just realize that in interior_mut_ty_chain it is actually the expected behavior to stack overflow, because you do need to traversve all the associated types to determine if it is interior mutable, which in this issue is unbounded.

[profetia]

We may need to come up some creative ways to fix this issue.

[supersurviveur]

It's not the only place where recursive types are a problem, rust-doc and rustc also hang/overflow at some places, so it's hard to telle if it's a wanted behaviour.

Here I'm not sure if it's the desired behaviour, since ExponantSet of an ExponantSet is a type implementing the same Trait as ExponantSet itself. So exploring this type multiple time is useless I think, but I'm not sure and it seems hard to fix.

[samueltardieu]

I've opened #14965 for it. Protection against infinitely recursive associated types is something we do at other places already.

@profetia This was quick to fix and test, so I've submitted the PR directly.