Unused generic in struct definition is allowed when used in invariant position

[theemathas]

I'm not sure if this is a bug or not.

The following code compiles:

struct Thing<T>(*mut Thing<T>);

I expected the above code to not compile, since the generic parameter T is used only in a recursive position. There isn't an "actual" T usage anywhere in the struct.

Note that changing the *mut to *const makes the code stop compiling. It seems that the recursion must be in an invariant position for the code to compile.

Code and error with *const

struct Thing<T>(*const Thing<T>);

error: type parameter `T` is only used recursively
 --> src/lib.rs:1:30
  |
1 | struct Thing<T>(*const Thing<T>);
  |              -               ^
  |              |
  |              type parameter must be used non-recursively in the definition
  |
  = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData`
  = note: all type parameters must be used in a non-recursive way in order to constrain their variance

This also has some strange behavior with auto traits. For example, the following code compiles:

use std::cell::Cell;
struct Thing<T>(Box<Cell<Thing<T>>>);
fn require_send<T: Send>() {}
fn wut() {
    require_send::<Thing<*mut ()>>();
}

Discovered in #152857

cc @lcnr

Meta

Reproducible on the playground with version 1.95.0-nightly (2026-02-19 7f99507f57e6c4aa0dce)

[mro95]

Hmm i checked and its also compiling on 1.93.1.

Funny thing is, you can also use it like this, but its quite useless.
let a: Thing<()> = Thing(std::ptr::null_mut());

If you try to put something else then a null ptr, it doesn't compile.

[theemathas]

Oddly enough, this doesn't compile:

struct Thing<T>(fn(Thing<T>) -> Thing<T>);

[QuineDot]

In my understanding, "is unused" is really "inferred to be bivariant", see here or the issues it closed for example.

The last example not being constrained does seem like a limitation of the implementation though (it is considered in "recursive variance type 2" in Taming the Wildcards).

[lcnr]

The fact that we have a fast path where we eagerly require all parameters referenced in an invariant position to be invariant, regardless of how they are used there is 🤷

I do consider this a bug and would accept a fix if it is not too invasive, but don't think this is a major issue

[mro95]

@rustbot claim