Suppressing lints, but not entirely

help
1

It would be neat to be able to mark a function as being a work-in-progress:

#[wip]
fn somefunc(blah: Context) -> Result<(), Error> {
}

.. which would tell the compiler/clippy that it should not bother generating lint warnings, because there might be a gazillion of them, and none of them matter currently (.. because the function is a work-in-progress). However, the compiler/linter should output a single line saying "lints for somefunc() have been suppressed because it is a work-in-progress".

The point would be to avoid spamming the compiler/linters output, but leave a tiny reminder that there's still work to do there.

Is there a way to accomplish this with some macro magic?

2

What about the unimplemented macro?

3

unimplemented!() will take care of return type mismatch errors, but it doesn't have any effect on warnings — though there is a currently active proposal to make it suppress dead_code warnings.

What you can do for warnings is #[allow(warnings)] or #[expect(warnings)]:

#[expect(warnings)]
fn somefunc(blah: String) -> Result<(), std::io::Error> {
    unimplemented!()
}

The lint name warnings refers to every lint that is currently set to issue warnings, so this results in no warnings.

(expect does the same as allow, except that it will warn you if there are zero warnings in the code block, which is useful for remembering to clean it up.)

1 Like
4

To take this all the way to what the original post asked (include a single warning to note the "WIP" marker's presence), would it make sense to have a pedantic clippy lint about the mere presence of #[expect(warnings)]?
(or of course, is there already such a lint?)

I imagine the lint would say something like "be more specific about the lint group expected, to avoid covering up unanticipated lints // may consider using this only as a sign that the marked code is a work in progress"

5

expect(warnings) usually swallows such meta-warnings too...

// No warnings (similar for built-in lints)
#[expect(warnings)]
#[warn(clippy::allow_attributes_without_reason)]
fn foo() {
    let x = ();
}

// No warnings (similar for built-in lints)
#[warn(clippy::allow_attributes_without_reason)]
#[expect(warnings)]
fn foo() {
    let x = ();
}

...but I did find a meta-warning that makes it through depending on attribute order:

// warning: unknown lint: `clippy::__function_in_progress`
// (Same with just `warn(__function_in_progress)` if you don't want to depend
// on running clippy to see it)
#[warn(clippy::__function_in_progress)]
#[expect(warnings)]
fn foo() {
    let x = ();
}

// No warnings (similar for non-scoped lint)
#[expect(warnings)]
#[warn(clippy::__function_in_progress)]
fn bar() {
    let x = ();
}

Probably it's a special case and not something an arbitrary lint could opt into, though? (Not actually sure.)

I also found this one, which amused me 
#[expect(unused)]
#[expect(unfulfilled_lint_expectations)]
fn foo() {
    let x = ();
}

warning: this lint expectation is unfulfilled
 --> src/lib.rs:3:10
  |
3 | #[expect(unfulfilled_lint_expectations)]
  |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: the `unfulfilled_lint_expectations` lint can't be expected and will always produce this message
  = note: `#[warn(unfulfilled_lint_expectations)]` on by default

(Like most others, this warning is swallowed by expect(warnings) regardless of attribute order.)

2 Likes