Inherent Associated Types feature regression on compiler releases after May.

[luissantosHCIT]

I was working on a Hackathon project back in May using compiler versions prior to that month. However, during the Hackathon I updated the nightly compiler to latest and found that my project no longer compiled. At the time, I did not have time to investigate so I tabled the issue. The project in question is rumtk. For reference, I am the same person in #141714. This is my more formal account now that I am focusing on software development on Rust. rumtk is a project I hope helps with hospital and clinic infrastructure.

At any rate, I now found a bit more time to investigate because my project's documentation in docs.rs has been failing for months which is a bigger problem now for me. Unfortunately, I was only able to narrow down the issue to changes in the feature #![feature(inherent_associated_types)]. I do not know what changed and whether the long term issue is to re-design the area of the code that uses this feature.

I have limited time but I am willing to learn more about fiddling and troubleshooting the compiler if someone mentors me! Long term, I want to be able to spend a weekend and offer constructive patches.

What Errors Do I Get?

With the feature on, nightly 1.93 gives me a serde error about a value type not being in scope.

With the feature off, I cannot longer compile a line of my own code.

Code

Feature On

    #[test]
    fn test_deserialize_serde_json() {
        use serde::{Deserialize, Deserializer, Serialize, Serializer};
        use serde_json::{from_str, to_string};

        #[derive(Serialize, Deserialize, PartialEq, Debug, Clone)]
        struct MyStruct {
            hello: RUMString,
        }

        let hw = MyStruct {
            hello: RUMString::from("World"),
        };
        let hw_str = to_string(&hw).unwrap();
        let new_hw: MyStruct = from_str(&hw_str).unwrap();

        assert_eq!(
            new_hw, hw,
            "Deserialized JSON does not match the expected value!"
        );
    }

I expected to see this happen: compiles like it did for a year.

Instead, this happened: Value not in scope error

Feature Off

    pub struct RUMClientHandle {
        runtime: &'static SafeTokioRuntime,
        client: SafeClient,
    }

    impl RUMClientHandle {
        type SendArgs<'a> = (SafeClient, &'a RUMNetMessage);
        type ReceiveArgs = SafeClient;

        pub fn connect(ip: &str, port: u16) -> RUMResult<RUMClientHandle> {
            RUMClientHandle::new(ip, port)
        }
        //     ...
    }

I expected to see this happen: compiles like it did for a year.

Instead, this happened: Value not in scope error

Version it worked on

It most recently worked on: 1.86.0

Version with regression

Probably as early as Rust 1.87 and definitely by 1.89.

rustc --version --verbose:

rustc 1.93.0-nightly (f15a7f385 2025-11-04)
binary: rustc
commit-hash: f15a7f38580ddbdc1a23909dd05cf6cc6d9f3919
commit-date: 2025-11-04
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.3

Backtrace

Backtrace

 Compiling pyo3-build-config v0.27.1
   Compiling pyo3-macros-backend v0.27.1
   Compiling pyo3-ffi v0.27.1
   Compiling pyo3 v0.27.1
   Compiling pyo3-macros v0.27.1
   Compiling rumtk-core v0.9.3
   Compiling serde_test v0.1.0 (/home/<>/RustroverProjects/serde_test)
warning: the feature `inherent_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes
 --> src/main.rs:1:12
  |
1 | #![feature(inherent_associated_types)]
  |            ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information
  = note: `#[warn(incomplete_features)]` on by default

warning: unused imports: `from_str` and `to_string`
 --> src/main.rs:7:18
  |
7 | use serde_json::{from_str, to_string};
  |                  ^^^^^^^^  ^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` (part of `#[warn(unused)]`) on by default

warning: unused imports: `rumtk_deserialize` and `rumtk_serialize`
 --> src/main.rs:9:18
  |
9 | use rumtk_core::{rumtk_deserialize, rumtk_serialize};
  |                  ^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^

error[E0220]: associated type `Value` not found for `__FieldVisitor` in the current scope
  --> src/main.rs:12:21
   |
12 | #[derive(Serialize, Deserialize, PartialEq, Debug, Clone)]
   |                     ^^^^^^^^^^^
   |                     |
   |                     associated item not found in `__FieldVisitor`
   |                     associated type `Value` not found for this struct
   |
   = note: the associated type was found for
           
   = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0220]: associated type `Value` not found for `__Visitor<'de>` in the current scope
  --> src/main.rs:12:21
   |
12 | #[derive(Serialize, Deserialize, PartialEq, Debug, Clone)]
   |                     ^^^^^^^^^^^
   |                     |
   |                     associated item not found in `__Visitor<'de>`
   |                     associated type `Value` not found for this struct
   |
   = note: the associated type was found for
           
   = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0220`.
warning: `serde_test` (bin "serde_test") generated 3 warnings
error: could not compile `serde_test` (bin "serde_test") due to 5 previous errors; 3 warnings emitted

I use the nightly channel because of fuzz testing.

Last Words

I have also looked at #8995.

For information about the weird errors getting generated, see my docs.rs issue.

Sample Test Code

#![feature(inherent_associated_types)]
#![feature(type_alias_impl_trait)]
#![feature(unboxed_closures)]
#![feature(buf_read_has_data_left)]

use serde::{ Serialize, Deserialize};
use serde_json::{from_str, to_string};

use rumtk_core::{rumtk_deserialize, rumtk_serialize};
use rumtk_core::strings::{RUMString};

#[derive(Serialize, Deserialize, PartialEq, Debug, Clone)]
struct MyJSON {
    hello: RUMString,
}

#[test]
fn test_pure_serde_json() {
    let expected = MyJSON{hello: RUMString::new("world")};
    let json = to_string(&expected).unwrap();
    let deserialized: MyJSON = from_str(&json).unwrap();
    assert_eq!(
        deserialized, expected,
        "Deserialized JSON does not match the expected value!"
    );
    println!("{:?}", json);
}

#[test]
fn test_rumtk_json() {
    let expected = MyJSON{hello: RUMString::new("world")};
    let json = rumtk_serialize!(&expected).unwrap();
    let deserialized: MyJSON = rumtk_deserialize!(&json).unwrap();
    assert_eq!(
        deserialized, expected,
        "Deserialized JSON does not match the expected value!"
    );
    println!("{:?}", json);
}

fn main() {
    println!("Hello, world!");
}

Sample Test Cargo.toml

[package]
name = "serde_test"
version = "0.1.0"
edition = "2021"
rust-version = "1.79.0"

[dependencies]
compact_str = { version = "0.9.0", features = ["serde"] }

serde = { version = "1.0.228", features = ["derive", "std"] }
serde_json = "1.0.145"
rumtk-core = "0.9.3"

Toggling the feature on or off should replicate the build errors despite the definitions living in rumtk-core.

Moving forward, I think I will just pull the conflicting types out of the impl to avoid issues. I think in retrospect, it was more of a reflex from my C++ habits. I still figure that I should let you know about the regression since I was able to generate valid programs based on my framework for the purpose of the Hackathon demo before updating to the newer compilers. Meaning, the compiler used to keep track of item types and resolve sub types without issues. Hopefully, this is helpful and maybe I learn about how Rust handles features under the hood!

[luissantosHCIT]

r? @tgross35

[rustbot]

Error: r? is only allowed on PRs.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[fmease]

Most likely, this is #142006 (comment) (a semi-intentional regression).

[fmease]

The temporary fix for that would be to put back the "if candidates.is_empty() { return Ok(None); }" in hir_ty_lowering which was removed in #140247.

However, at that time it was removed to paper over some mGCA (min_generic_const_args) ICEs or inference issues. I don't know if that has been resolved. Feel free to experiment with such a fix, I'm available here or on Zulip if you have any questions (and I'm sure Boxy is, too).

[fmease]

I'll now close this in favor of #142006 (comment).