`#[ignore(lint_name)]` errors should suggest using `#[allow(lint_name)]` instead

[Zalathar]

Code

#![ignore(clippy::single_match)]

Current output

error: valid forms for the attribute are `#![ignore = "reason"]` and `#![ignore]`
 --> src/lib.rs:1:1
  |
1 | #![ignore(clippy::single_match)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #57571 <https://github.com/rust-lang/rust/issues/57571>
  = note: `#[deny(ill_formed_attribute_input)]` (part of `#[deny(future_incompatible)]`) on by default

Desired output

help: if you meant to silence a warning, consider `#![allow(clippy::single_match)]` or `#![expect(clippy::single_match)]`

Rationale and extra context

Recently I mixed up the name of the attribute used to silence warnings, and accidentally wrote #[ignore(..)] instead of #[allow(..)].

The compiler was right to reject my program, but I was briefly confused by why it wasn't working, because the error message doesn't give any indication of what the ignore attribute is for. That made it harder for me to correct my misunderstanding.

Other cases

Rust Version

$ rustc --version --verbose
rustc 1.94.0 (4a4ef493e 2026-03-02)
binary: rustc
commit-hash: 4a4ef493e3a1488c6e321570238084b38948f6db
commit-date: 2026-03-02
host: aarch64-apple-darwin
release: 1.94.0
LLVM version: 21.1.8

Anything else?

No response

[JayanAXHF]

@rustbot claim

[kpreid]

FWIW, I think it would also be useful if the error prioritized mentioning that #[ignore] is being used in the wrong syntactic position, and not just that it has the wrong arguments, because this is a reliable sign that either the user doesn’t know what ignore is for, or that they have typoed the placement of the ignore attribute, both of which are more fundamental problems than giving the right argument to ignore. That is, follow this logic:

1. if the argument is a lint name { suggest allow }
2. else if the attribute is not on a test { error "#[ignore] is for tests" }
3. else if the attribute is not well-formed { attribute syntax error }

(This might be best considered a separate issue, or easy to do in the same change — I don’t know.)

[JayanAXHF]

@kpreid I think that this could be a good addition. IMO it makes more sense as a separate issue, maybe even consider a small zulip thread