Skip to content

type_complexity triggered in macro-generated code #17446

Description

@nazar-pc

Summary

Similarly to #17430 no-panic generates internal code that exceeds type complexity, while original code was fine.

Original code looked like this:

impl<Reg, Regs, ExtState, Memory, PC, InstructionHandler, CustomError>
    ExecutableInstruction<Regs, ExtState, Memory, PC, InstructionHandler, CustomError>
    for Rv32Instruction<Reg>
where
    Reg: Register<Type = u32>,
    Regs: RegisterFile<Reg>,
    Memory: VirtualMemory,
    PC: ProgramCounter<Reg::Type, Memory, CustomError>,
    InstructionHandler: SystemInstructionHandler<Reg, Regs, Memory, PC, CustomError>,
{
    #[cfg_attr(feature = "no-panic", no_panic_const::no_panic)]
    fn execute(
        self,
        Rs1Rs2OperandValues {
            rs1_value,
            rs2_value,
        }: Rs1Rs2OperandValues<<Self::Reg as Register>::Type>,
        regs: &mut Regs,
        _ext_state: &mut ExtState,
        memory: &mut Memory,
        program_counter: &mut PC,
        system_instruction_handler: &mut InstructionHandler,
    ) -> Result<
        ControlFlow<(), (Self::Reg, <Self::Reg as Register>::Type)>,
        ExecutionError<Reg::Type, CustomError>,
    > {

While after macro-expansion no-panic generated this closure:

let __result = (move || -> Result<
    ControlFlow<(), (Self::Reg, <Self::Reg as Register>::Type)>,
    ExecutionError<Reg::Type, CustomError>,
>   {

Trait definition had the lint suppressed, so there was no complain on the implementation, but since macro-generated code produced a standalone closure, it started triggering the lint:

warning: very complex type used. Consider factoring parts into `type` definitions
  --> ...rs:37:10
   |
37 |       ) -> Result<
   |  __________^
38 | |         ControlFlow<(), (Self::Reg, <Self::Reg as Register>::Type)>,
39 | |         ExecutionError<Reg::Type, CustomError>,
40 | |     > {
   | |_____^
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#type_complexity
   = note: `#[warn(clippy::type_complexity)]` on by default

Macro expansion points to the mentioned closure:

warning: very complex type used. Consider factoring parts into `type` definitions
  --> ...rs:76:36
   |
76 |           let __result = (move || -> Result<
   |  ____________________________________^
77 | |             ControlFlow<(), (Self::Reg, <Self::Reg as Register>::Type)>,
78 | |             ExecutionError<Reg::Type, CustomError>,
79 | |         >   {
   | |_________^
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#type_complexity
   = note: `#[warn(clippy::type_complexity)]` on by default

This is again out of control for macro user and should not be reported.

Lint Name

type_complexity

Reproducer

No response

Version

rustc 1.99.0-nightly (0e29c21d9 2026-07-21)
binary: rustc
commit-hash: 0e29c21d93abc9bdc330182be1fbd33cfd5fee68
commit-date: 2026-07-21
host: x86_64-unknown-linux-gnu
release: 1.99.0-nightly
LLVM version: 22.1.8

Additional Labels

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: Clippy is not doing the correct thingI-false-positiveIssue: The lint was triggered on code it shouldn't have

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions