Make `#[allow(unused_variables)]` implicit when calling `todo!()`

[od-b]

Hi, first post! Please don't hesitate to murder me if this is a terrible idea or i'm in the wrong place.

Implementing in Rust i found that communicating with the compiler is essentially where most of the time is spent, and the todo!() macro is super handy to give the compiler a heads up that i'm aware something is not working.

However, I think it would be very handy for the macro to also communicate to the compiler/checker (i don't know the correct terms) that unused variables are OK – iff no other code exists within that scope.

E.g

fn build(a: u8, b: u8) -> Self {
   todo!()
}

Instead implicitly becoming:

#[allow(unused_variables)]
fn build(a: u8, b: u8) -> Self {
   todo!()
}

For as long as no other code exists within build.

I found myself being quite overwhelmed with error messages, but a global
#!allow(unused_variables)] feels so dirty and the error notice is usually very handy.

For context i started learning a week ago, and so it could very well be that this suggestion is:

• Not feasible
• Undesired
• Already exists in some form (in which case please let me know!)

Coming from C i'm loving it so far, despite the [imo.] steep learning curve. Given how anxiety inducing concurrency is in C, Rust honestly feels like a more mature language in many ways. Thank you to everyone who contributes to the language!

[steffahn]

Regarding prior discussion, a search in this forum gave me this thread. Then on GitHub, I could find this issue, and this first attempt for implementing something like that that, which got closed but contains interesting discussion as well

[Heliozoa]

I'd love to have this if it went a lot further than in the OP, I frequently use todo!() in incomplete code and the numerous superfluous warnings are pretty annoying.

For me, "iff no other code exists within that scope" would make this pretty niche. It's very rare that I don't have any other code around it at all, rather I use todo!() in functions as I work on them to keep the project compiling.

In an "extreme" case I might have a function with multiple todo!()s, something like this:

fn func(a: i32) -> SomeStruct {
    let x = 1234;
    let y: AnotherStruct = todo!();
    let z = 1234;
    todo!()
}

and for me it would be a big improvement if this didn't produce all the unused variable/unreachable statement warnings that it currently does. todo!() is an explicit signal that the code is unfinished, so it is expected that there may be unused variables and such.

The PR steffahn linked was closed in favor of #[expect(lint)] which is still unstable, but even if it wasn't it isn't something I would use for this. Having to type out

#[expect(unused_variable)]
#[expect(unreachable_statement)]

over functions as I'm working on them and then removing them after I'm done is more of a pain than the warnings themselves, I feel that way even about #[allow(warnings)].

It doesn't seem like people were fans of the suggestion in the PR, though I don't really find the arguments against it too convincing. Something as simple as println!("a={a}, b={b}"); already turns off the warnings in the OP example, the arguments are "used" but the function is still unfinished. #![warn(clippy::todo)] (and potentially denying it in CI) seems like a much better way to have a warning as a reminder of unfinished code than unused variables that you need to remember are supposed to be there, as opposed to other unused variables.

At the end of the day though this is a small enough issue for me that typing #[allow(warnings)] is too inconvenient a workaround so it's not a big deal for me even if this suggestion doesn't go forwards. Would be nice though!

[od-b]

Completely agree with you here! Regarding the iff, i'm simply not experienced enough with the language to deduct whether allowing (not warning about*) all unused variables would be a good idea, and so i figured i'd limit the suggestion.