Split up the unknown_or_malformed_diagnostic_attributes lint

[mejrs]

This splits up the lint into the following lint group:

• unknown_diagnostic_attributes - triggers if the attribute is unknown to the current compiler
• misplaced_diagnostic_attributes - triggers if the attribute exists but it is not placed on the item kind it's meant for
• malformed_diagnostic_attributes - triggers if the attribute's syntax or options are invalid
• malformed_diagnostic_format_literals - triggers if the format string literal is invalid, for example if it has unpaired curly braces or invalid parameters
• this pr doesn't create it, but future lints for things like deprecations can also go here.

This PR does not start emitting lints in places that previously did not.

Motivation

I want to have finer control over what unknown_or_malformed_diagnostic_attributes does

I have a project with fairly low msrv that is/will have a lower msrv than future diagnostic attributes. So lints will be emitted when I or others compile it on a lower msrv.

At this time, there are two options to silence these lints:

• #[allow(unknown_or_malformed_diagnostic_attributes)] - this risks diagnostic regressions if I (or others) mess up using the attribute, or if the attribute's syntax ever changes.
• write a build script to detect the compiler version and emit cfgs, and then conditionally enable the attribute:

  #[cfg_attr(rust_version_99, diagnostic::new_attr_in_rust_99(thing = ..))]`
  struct Foo;

  or conditionally allow the lint:

  // lib.rs
  #![cfg_attr(not(current_rust), allow(unknown_or_malformed_diagnostic_attributes))]

I like to avoid using build scripts if I can, so the following works much better for me. That is what this PR will let me do in the future:

    #[allow(unknown_diagnostic_attribute, reason = "attribute came out in rust 1.99 but msrv is 1.70")]
    #[diagnostic::new_attr_in_rust_99(thing = ..)]`
    struct Foo;

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

[mejrs]

I know creating a new lint requires lang team approval, but I'm unsure if splitting a lint needs it.

@rustbot labels +I-lang-nominated

[mejrs]

This is a duplicate of the one in ../on_unimplemented.rs, I think I accidentally copy pasted it in the past 😞

[oli-obk]

cc @estebank @weiznich you probably have opinions on this

[joshtriplett]

This seems consistent with how diagnostic attributes are intended to be used, and useful for ensuring that when you allow one of them because you know what you're doing, you still benefit from the other warnings.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[traviscross]

@rfcbot reviewed