Hang from infinitely-self-recursive trait alias

[wxie7]

I tried this code:

#![feature(trait_alias)]
#![feature(impl_trait_in_assoc_type)]
trait Foo {
    type Bar: Baz<Self, Self>;
    fn bar(&self) -> Self::Bar;
}
struct X;
impl Foo for X {
    type Bar = impl Baz<Self, Self>;
    fn bar(&self) -> Self::Bar {
        |x| x
    }
}
trait Baz<A: ?Sized, B: ?Sized> = Baz(&A) -> &B;
fn main() {}

It mutates from the following file, but the following code will not cause a hang.

#![feature(trait_alias)]
#![feature(impl_trait_in_assoc_type)]

trait Foo {
    type Bar: Baz<Self, Self>;

    fn bar(&self) -> Self::Bar;
}

struct X;

impl Foo for X {
    type Bar = impl Baz<Self, Self>;

    fn bar(&self) -> Self::Bar {
        |x| x
    }
}

trait Baz<A: ?Sized, B: ?Sized> = Fn(&A) -> &B;

fn main() {}

Also, I used impl_trait_in_assoc_type and Baz as search keywords but didn’t find any related issues with open.

Meta

rustc --version --verbose:

rustc 1.85.0-nightly (acabb5248 2024-12-04)
binary: rustc
commit-hash: acabb5248231987ae1f0c215208d1005a5db402d
commit-date: 2024-12-04
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.5

Backtrace

<backtrace>

[cyrgani]

Reduced:

trait Foo {
    type Bar: Baz<()>;
}
impl Foo for () {
    type Bar = ();
}
trait Baz<A> = Baz<&'static A>;

[theemathas]

Minimized:

#![feature(trait_alias)]
fn foo<T: Baz<i32>>() {}
trait Baz<A> = Baz<Option<A>>;

(Hangs without producing any errors or warnings. If the foo definition is moved after the Baz definition, then there's a cycle error before the hang.)

[jieyouxu]

Triage notes:

trait Foo {
    type Bar: Baz<()>;
}
impl Foo for () {
    type Bar = ();
}
trait Baz<A> = Baz<&'static A>;

hangs on stable (1.83) without the feature gate, which is a bit different from the other minimization which involves the feature gate

#![feature(trait_alias)]
fn foo<T: Baz<i32>>() {}
trait Baz<A> = Baz<Option<A>>;

[jieyouxu]

I feel like this probably is already reported but I can't find an earlier report.

[lqd]

I feel like this probably is already reported

I had the same feeling, we have many reports of superficially similar looking hangs. It could be interesting to bisect this one though, because this looks like a somewhat recent regression (from 1.78).

[lqd]

bisects to nightly-2024-03-09

• Add arm64ec-pc-windows-msvc target #119199 - dpaoliello:arm64ec, r=petrochenkov
• Rollup of 10 pull requests #122151 - GuillaumeGomez:rollup-hfxr9kv, r=GuillaumeGomez
• Use GEP inbounds for ZST and DST field offsets #122048 - erikdesjardins:inbounds, r=oli-obk
• Optimize write with as_const_str for shorter code #122059 - nyurik:with-as-const-str, r=cuviper
• Replace the default branch with an unreachable branch If it is the last variant #120268 - DianQK:otherwise_is_last_variant_switchs, r=oli-obk
• Rollup of 8 pull requests #122182 - matthiaskrgr:rollup-gzimi4c, r=matthiaskrgr
• Check that return type is WF in typeck #122078 - gurry:121443-ice-layout-is-sized-alt, r=oli-obk
• Merge collect_mod_item_types query into check_well_formed #121500 - oli-obk:track_errors12, r=petrochenkov
• Rollup of 8 pull requests #122190 - matthiaskrgr:rollup-9ol4y30, r=matthiaskrgr
• Rollup of 9 pull requests #122206 - matthiaskrgr:rollup-4txx9wx, r=matthiaskrgr