Infrastructure for lints during attribute parsing, specifically duplicate usages of attributes

[jdonszelmann]

r? @oli-obk

This PR adds a new field to OwnerInfo to buffer lints which are generated during attribute parsing and ast lowering in general. They can't be emitted at this stage because at that point there's no HIR yet, and early lints are already emitted.

This also adds the generic S: Stage to attribute parsers. Currently we don't emit any lints during early attribute parsing, but if we ever want to that logic will be different. That's because there we don't have hir ids yet, while at the same time still having access to node ids and early lints. Even though that logic isn't completely there in this PR (no worries, we don't use it), that's why the parameter is there.

With this PR, we also add 2 associated consts to SingleAttributeParser. Those determine what logic should be applied when finding a duplicate attribute.

This PR was getting pretty large, so the first code using this logic is in #138165. This code is all new things that weren't possible before so it also doesn't break any behaviour. However, some of it will be dead code right now. I recommend reviewing both before merging, though in some sense that doubles the size of the review again, and the other PR might be more controversial. Let me know how you want to do this @oli-obk

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[jdonszelmann]

(am aware of merge commits, was just an easy way to get those changes in before they're on master so we can run CI on this PR. will obviously remove once those changes are on master and this PR can be merged)

[bors]

☔ The latest upstream changes (presumably #138388) made this pull request unmergeable. Please resolve the merge conflicts.

[jdonszelmann]

@rustbot review

[jdonszelmann]

@bors r=oli_obk

[bors]

📌 Commit e2afe04 has been approved by oli_obk

It is now in the queue for this repository.

[fmease]

@bors r=oli-obk

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Rollup of 9 pull requests #142399

[bors]

📌 Commit e2afe04 has been approved by oli-obk

It is now in the queue for this repository.

[workingjubilee]

There are several open PRs touching adjacent areas that will conflict with this, and there is somewhat-timing-sensitive work that is strictly blocked on this. Bumping its priority accordingly.

@bors p=1 rollup=iffy

[workingjubilee]

( Ideally it just lands in the rollup currently trying to land though. )

[bors]

⌛ Testing commit e2afe04 with merge 573a015...

[jdonszelmann]

@workingjubilee I'm happy this gets merged but some of those I deliberately didn't r+ yet to wait for this one but this makes sure it work :)

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 573a015 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 6c8138d (parent) -> 573a015 (this PR)

Test differences

Show 147 test diffs

Stage 1

• session_diagnostics::verify_attr_parsing_empty_confusables_30: pass -> [missing] (J0)
• session_diagnostics::verify_attr_parsing_empty_confusables_31: [missing] -> pass (J0)
• session_diagnostics::verify_attr_parsing_repr_ident_31: pass -> [missing] (J0)
• session_diagnostics::verify_attr_parsing_repr_ident_32: [missing] -> pass (J0)
• session_diagnostics::verify_attr_parsing_stability_outside_std_29: pass -> [missing] (J0)
• session_diagnostics::verify_attr_parsing_stability_outside_std_30: [missing] -> pass (J0)
• session_diagnostics::verify_attr_parsing_unrecognized_repr_hint_32: pass -> [missing] (J0)
• session_diagnostics::verify_attr_parsing_unrecognized_repr_hint_33: [missing] -> pass (J0)
• session_diagnostics::verify_attr_parsing_unused_duplicate_29: [missing] -> pass (J0)

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

Job group index

• J0: aarch64-apple, aarch64-gnu, i686-gnu-2, i686-gnu-nopt-2, i686-msvc-2, x86_64-apple-1, x86_64-gnu, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-1, x86_64-gnu-llvm-20-3, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-2, x86_64-msvc-2

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 573a01569000d395498a5f98f916d6e5305ac81a --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: 5058.2s -> 6576.6s (30.0%)
2. x86_64-apple-1: 7328.3s -> 9029.2s (23.2%)
3. dist-x86_64-msvc-alt: 7179.2s -> 8838.4s (23.1%)
4. dist-various-1: 4293.5s -> 4917.7s (14.5%)
5. dist-x86_64-apple: 9693.9s -> 10934.9s (12.8%)
6. dist-android: 2388.0s -> 2613.8s (9.5%)
7. dist-apple-various: 6971.2s -> 6390.0s (-8.3%)
8. dist-x86_64-solaris: 5465.3s -> 5020.7s (-8.1%)
9. dist-aarch64-linux: 6155.9s -> 5682.4s (-7.7%)
10. x86_64-mingw-1: 9148.9s -> 8527.6s (-6.8%)

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 (573a015): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.1%, 1.0%]	107
Regressions ❌ (secondary)	1.0%	[0.1%, 3.1%]	56
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[0.1%, 1.0%]	107

Max RSS (memory usage)

Results (primary 1.7%, secondary 3.1%)

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

	mean	range	count
Regressions ❌ (primary)	1.7%	[0.4%, 7.3%]	9
Regressions ❌ (secondary)	4.4%	[1.0%, 13.6%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-8.5%	[-8.5%, -8.5%]	1
All ❌✅ (primary)	1.7%	[0.4%, 7.3%]	9

Cycles

Results (primary -1.0%, secondary 1.7%)

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

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

Binary size

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

Bootstrap: 754.987s -> 754.801s (-0.02%)
Artifact size: 372.08 MiB -> 372.21 MiB (0.03%)