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

[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

[weiznich]

Just to add the context why this was implemented as a single lint: #114452 (comment)

Which means @petrochenkov might still have opinions about this.

[tmandry]

@rfcbot reviewed

I think we definitely want to split out the "unknown" case for the reason given in the description. I feel less strongly about the other cases, but I can imagine wanting to allow those because of version skew, e.g. when a lint doesn't apply to certain item kinds in older versions of the compiler but does in newer versions.

[estebank]

Responding to the earlier ping, I'm always in favor of more targeted lints, so I'm in favor of turning this into a group.

[tmandry]

@rfcbot reviewed

Trying again.

[traviscross]

@rfcbot ping

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bors]

📌 Commit f975708 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit f975708 with merge 25c1ecc...

[bors]

💔 Test failed - checks-actions

[oli-obk]

@bors r+

[bors]

📌 Commit a7bf5c4 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit a7bf5c4 with merge b1d2f2c...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing b1d2f2c to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 288e94c (parent) -> b1d2f2c (this PR)

Test differences

Show 277 test diffs

277 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard b1d2f2c64c6254b2a935d6a2d29b68f4511cf500 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-apple-2: 4054.2s -> 5567.4s (37.3%)
2. dist-x86_64-apple: 7720.1s -> 10386.6s (34.5%)
3. dist-aarch64-apple: 5498.4s -> 6454.7s (17.4%)
4. aarch64-apple: 4631.3s -> 5132.8s (10.8%)
5. x86_64-msvc-1: 9445.1s -> 8515.5s (-9.8%)
6. dist-apple-various: 6656.2s -> 7285.2s (9.5%)
7. x86_64-rust-for-linux: 2798.3s -> 3001.5s (7.3%)
8. dist-aarch64-msvc: 5791.5s -> 5388.0s (-7.0%)
9. x86_64-apple-1: 7663.0s -> 7178.3s (-6.3%)
10. aarch64-msvc-2: 5194.1s -> 5459.9s (5.1%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (b1d2f2c): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 1.6%, secondary -0.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.6%	[1.6%, 1.6%]	1
Regressions ❌ (secondary)	1.5%	[1.5%, 1.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.7%	[-2.7%, -2.7%]	1
All ❌✅ (primary)	1.6%	[1.6%, 1.6%]	1

Cycles

Results (primary 2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.4%	[2.4%, 2.4%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.4%	[2.4%, 2.4%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 468.578s -> 466.487s (-0.45%)
Artifact size: 374.72 MiB -> 374.73 MiB (0.00%)