Diagnostic doesn't clarify that error "cyclic type of infinite size" refers to type size / a failed occurs-check & not to the size of the in-memory representation of its values

[jacobsa]

Here is a snippet from some (more realistic) code for creating a struct that contains a closure which, when run, will delete the struct:

struct Foo<F> {
    f: Option<F>,
}

unsafe fn make_self_deleting() -> impl Sized {
    let foo = Box::into_raw(Box::new(Foo { f: None }));
    (*foo).f = Some(|| {
        let _ = Box::from_raw(foo);
    });

    foo
}

(Playground)

This involves a self-referential type, since the struct Foo is generic over the closure that it contains, but the closure captures a pointer to Foo, so it's unsurprising that the compiler rejects it. However the error is a bit weird:

cyclic type of infinite size

I agree with the "cyclic" part, but I was surprised by the "infinite size" part. That's not actually true here, is it? The closure needs to capture only one pointer.

[fmease]

I was surprised by the "infinite size" part. That's not actually true here, is it? The closure needs to capture only one pointer.

That's not in reference to the in-memory representation of the values that inhabit the type but to the size of the type itself "if you were to write it down without self-references" which you couldn't in this case.

E.g., in _ = |f: fn(_)| f(f) f would need to have a type that satisfies ?0 = fn(?0) but in an iso-recursive type system like Rust's¹ there's no such type – since fn(fn(fn(fn(..)))) "can't be written down" (in an equi-recursive type system it would be allowed), so its "textual representation" "has an infinite size" (OTOH the in-memory repr of its values, fn ptrs, would be finite similar to your example). It fails the so-called occurs-check.

This verbiage is relatively common for a failed occurs-check, at least in HM-style languages like Haskell or ones with more powerful type systems (e.g., dependently typed languages).

Footnotes

1. Well, mostly. It does have (latent) bottoms / diverging terms at the type-level, namely alias types, so it's only partially true. ↩

[ais523]

This is related to / a similar situation to #144617 (although it seems to be a different problem rather than a duplicate bug).

[fmease]

The issue you've linked (#144617) is not related at all since in that issue"infinite size" refers to the size of the in-memory representation of values of that type.

Its "textual representation" however is finite, it's literally "U". It has nothing to do with the occurs-check I've described above. Since unions are nominal types, they break the type recursion, so they act as roll from an iso-recursive perspective IINM.

[fmease]

(Obv. the improved diagnostic shouldn't mention the term occurs-check which I've added to the issue title for easy lookup; it should use more digestible terms)

[jacobsa]

Thanks, I figured that was the answer. It would be nice to clarify in the error which kind of "infinite size" we are talking about, since I would guess that "size" related to a type is often interpreted as size_of::<Type>().

[jacobsa]

(…which it seems you agree with, thanks for retitling.)