Cycle when computing type of recursive opaque type

[LeSeulArtichaut]

I tried this code:

#![feature(rustc_attrs)]

#[rustc_layout_scalar_valid_range_start(1)]
struct NonZero<T>(T);

fn closure_ref_capture() -> NonZero<impl Sized> {
    let x = closure_ref_capture();
    unsafe { NonZero(move || { &x.0; }) }
}

rustc gives the following output:

error[E0391]: cycle detected when computing type of `closure_ref_capture::{opaque#0}`
 --> test.rs:6:37
  |
6 | fn closure_ref_capture() -> NonZero<impl Sized> {
  |                                     ^^^^^^^^^^
  |
note: ...which requires borrow-checking `closure_ref_capture`...
 --> test.rs:6:1
  |
6 | fn closure_ref_capture() -> NonZero<impl Sized> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...which requires processing `closure_ref_capture`...
 --> test.rs:6:1
  |
6 | fn closure_ref_capture() -> NonZero<impl Sized> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...which requires processing MIR for `closure_ref_capture`...
 --> test.rs:6:1
  |
6 | fn closure_ref_capture() -> NonZero<impl Sized> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...which requires building MIR for `closure_ref_capture`...
 --> test.rs:6:1
  |
6 | fn closure_ref_capture() -> NonZero<impl Sized> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...which requires unsafety-checking `closure_ref_capture`...
 --> test.rs:8:33
  |
8 |     unsafe { NonZero(move || { &x.0; }) }
  |                                 ^^^
  = note: ...which requires computing whether `impl Sized` is freeze...
  = note: ...which requires evaluating trait selection obligation `impl Sized: std::marker::Freeze`...
  = note: ...which again requires computing type of `closure_ref_capture::{opaque#0}`, completing the cycle
note: cycle used when checking item types in top-level module
 --> test.rs:1:1
  |
1 | / #![feature(rustc_attrs)]
2 | |
3 | | #[rustc_layout_scalar_valid_range_start(1)]
4 | | struct NonZero<T>(T);
... |
8 | |     unsafe { NonZero(move || { &x.0; }) }
9 | | }
  | |_^

warning: function cannot return without recursing
 --> test.rs:6:1
  |
6 | fn closure_ref_capture() -> NonZero<impl Sized> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot return without recursing
7 |     let x = closure_ref_capture();
  |             --------------------- recursive call site
  |
  = note: `#[warn(unconditional_recursion)]` on by default
  = help: a `loop` may express intention better if this is on purpose

error[E0720]: cannot resolve opaque type
 --> test.rs:6:37
  |
6 | fn closure_ref_capture() -> NonZero<impl Sized> {
  |                                     ^^^^^^^^^^ recursive opaque type
7 |     let x = closure_ref_capture();
8 |     unsafe { NonZero(move || { &x.0; }) }
  |              -------------------------- returning here with type `NonZero<[closure@test.rs:8:22: 8:39]>`

error: aborting due to 3 previous errors; 1 warning emitted

This affects both the MIR and the THIR unsafety checkers. However, since the code is obviously wrong and the relevant errors are still emitted, I'd expect this to be closed as wontfix.

Meta

rustc --version --verbose:

rustc 1.56.0-nightly (5ad7389bd 2021-08-06)
binary: rustc
commit-hash: 5ad7389bdd1abe7d2c6f73a233af1a7a69e96285
commit-date: 2021-08-06
host: x86_64-unknown-linux-gnu
release: 1.56.0-nightly
LLVM version: 12.0.1

[danielhenrymantilla]

Potentially related:

use Send as SomeAutoTrait;
macro_rules! SomeExistential {() => ( impl Sized )}

fn foo() -> SomeExistential!() {
    // check if `typeof![foo()] : SomeAutoTrait`
    let _: &dyn SomeAutoTrait = &foo();
}

• Context

[LeSeulArtichaut]

@danielhenrymantilla Interestingly, the code you provided is a different cycle (it doesn't involve is_freeze checks). I think it looks more like #78649, and it might be a great MCVE for that issue which doesn't seem to have one.

Ultimately I think both issues have the same root cause, i.e. the type system and the MIR builder being dependent on each other. Maybe fixing #78649 will fix this issue as well.

[kornelski]

I've ran into this in kornelski/cargo-deb@e814497 using rustc 1.60.0-nightly (ec4bcaa 2022-01-15) on macOS aarch64

and it's a weird case, because it only affects cargo fix --edition, but not any other command like cargo build, not even cargo fix --edition-idioms.

error[E0391]: cycle detected when computing when `manifest::CargoDeb` has a significant destructor
   --> src/manifest.rs:906:1
    |
906 | struct CargoDeb {
    | ^^^^^^^^^^^^^^^
    |
    = note: ...which immediately requires computing when `manifest::CargoDeb` has a significant destructor again
    = note: cycle used when computing whether `manifest::Cargo` has a significant drop

It doesn't like this:

struct CargoDeb {
    pub variants: Option<HashMap<String, CargoDeb>>,
}

It compiles if I change it to:

struct CargoDeb {
    pub variants: Option<HashMap<String, Box<CargoDeb>>>,
}

but given the odd nature of this bug, that may just be a coincidence.

[LeSeulArtichaut]

@kornelski This is #92725, you can look there for details. Thanks anyway for the report.

[syvb]

I can't reproduce this with the THIR unsafety checker (which is the default since #117673) on recent nightlies - I think this issue should be closed. The only error I get is (ignoring warnings):

error[E0720]: cannot resolve opaque type
 --> /tmp/a.rs:6:37
  |
6 | fn closure_ref_capture() -> NonZero<impl Sized> {
  |                                     ^^^^^^^^^^ recursive opaque type
7 |     let x = closure_ref_capture();
8 |     unsafe { NonZero(move || { &x.0; }) }
  |              --------------------------
  |              |                  |
  |              |                  closure captures itself here
  |              returning here with type `NonZero<{closure@/tmp/a.rs:8:22: 8:29}>`