`cycle detected when computing the variances of` despite not using inherent assoc. types feature flag

[Technohacker]

This is a minimal version of a part from my project (compilable repro here)

pub struct Struct1;
pub struct Struct2;
pub struct Struct3;

// These two from external crate
pub trait ExternalTrait {
    type Output;

    fn do_something() -> Self::Output;
}

pub trait ExternalUtilityTrait<T> {
    type Output;

    fn do_something_with_type(&mut self, input: T) -> Self::Output;
}

// These from current crate
// ########## Variances Cycle Error raised here ########
pub struct ProblemStruct<T: HelperTrait> {
    inner: T,
}

pub trait HelperTrait: ExternalUtilityTrait<Struct2> {}

impl<T: HelperTrait> ExternalTrait for ProblemStruct<T> {
    type Output = ();

    fn do_something() -> Self::Output {
        todo!()
    }
}

impl<T: HelperTrait> ExternalUtilityTrait<Struct1> for ProblemStruct<T> {
    type Output = ();

    // Commenting this function out correctly shows the
    // unstable inherent assoc. types warning
    fn do_something_with_type(&mut self, input: Struct1) -> Self::Output {
        todo!()
    }
}

impl<T: HelperTrait> ProblemStruct<T> {
    // Inherent associated type used here
    type Output = ();
}

fn main() {}

Expected compiler error (reported after commenting out the marked part above):

error[E0658]: inherent associated types are unstable
  --> src/main.rs:46:5
   |
46 |     type Output = ();
   |     ^^^^^^^^^^^^^^^^^
   |
   = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information

Actual compiler error:

error[E0391]: cycle detected when computing the variances of `ProblemStruct`
  --> src/main.rs:20:1
   |
20 | pub struct ProblemStruct<T: HelperTrait> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: ...which requires computing the variances for items in this crate...
note: ...which requires computing function signature of `<impl at src/main.rs:34:1: 34:72>::do_something_with_type`...
  --> src/main.rs:39:5
   |
39 |     fn do_something_with_type(&mut self, input: Struct1) -> Self::Output {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: ...which again requires computing the variances of `ProblemStruct`, completing the cycle
note: cycle used when computing function signature of `<impl at src/main.rs:26:1: 26:56>::do_something`
  --> src/main.rs:29:5
   |
29 |     fn do_something() -> Self::Output {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Meta

Bug was initially discovered with a nightly compiler, but I was able to raise it on stable as well. Both versions used from Flatpak's rust-stable and rust-nightly SDKs

Nightly: rustc --version --verbose:

rustc 1.72.0-nightly (6162f6f12 2023-07-01)
binary: rustc
commit-hash: 6162f6f12339aa81fe16b8a64644ead497e411b2
commit-date: 2023-07-01
host: x86_64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.5

Stable: rustc --version --verbose:

rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-unknown-linux-gnu
release: 1.70.0
LLVM version: 16.0.2

[compiler-errors]

What makes you think this is related to inherent associated types? I don't think it has to do with IATs, and it seems to have been failing since 2022.

[fmease]

It's certainly not ideal that we don't currently issue the feature-gate error for inherent associated types next to the cycle error since I assume it's quite confusing and unhelpful for the uninitiated (in the sense of "what the hell did I do wrong, compiler?!").
So it's worth keeping this issue open.

Apart from that, the cycle error is already tracked in #108491 and #110106 but you already found these issues :)

@rustbot label T-compiler F-inherent_associated_types

[fmease]

@compiler-errors There's an inherent assoc ty at the very end of the snippet

[compiler-errors]

Ah, yeah, ok then. @fmease maybe we should just lower IATs to ty::Error unless the feature gate is active to suppress this cycle.

[fmease]

Yas, can do that.

@rustbot claim

[Technohacker]

It was an issue I noticed when I was moving a function from a trait impl to a normal impl and I forgot to remove the associated type, took me a while to identify the issue in my codebase since it was during a design refactor 😅

[fmease]

Addendum: We probably don't want to convert them to ty::Error (or similar) but we want to skip IAT selection entirely, otherwise Self::Output (from the snippet) would suddenly no longer refer to the trait associated type but be an error breaking back-compat. Anyways, easy fix. Gonna work on that later Eh, should be fine actually