rustc_feature cleanups

[nnethercote]

Various cleanups. Details in individual commits.

r? @JonathanBrouwer

[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.

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

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

cc @jdonszelmann, @JonathanBrouwer

rustc-dev-guide is developed in its own repository. If possible, consider making this change to rust-lang/rustc-dev-guide instead.

cc @BoxyUwU, @tshepang

[nnethercote]

LLM disclosure: these changes were mostly identified by an LLM. I did all the code and text changes myself.

[mejrs]

FWIW this field only really exists to statically check that the feature actually exists - Features::doesnt_exist can't be found because that's not a feature.

You could remove this field if you can do that check in another way.

View changes since the review

[JonathanBrouwer]

@bors r+ rollup
Thanks!

View changes since this review

[JonathanBrouwer]

This new dependency already existed transitively through rustc_data_structures so is fine :)

[rust-bors]

📌 Commit 60be562 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[rust-timer]

Finished benchmarking commit (9aa1b10): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf +perf-regression

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
Regressions ❌ (secondary)	0.4%	[0.3%, 0.6%]	21
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: missing data
Artifact size: 400.59 MiB -> 400.55 MiB (-0.01%)

[JonathanBrouwer]

Huh, I wonder what caused the regression here?

[nnethercote]

• This PR contains only very minor refactorings that you wouldn't expect to affect perf.
• I can't reproduce the regression when I build locally.
• I can reproduce the regression from the downloaded CI artifacts. A Cachegrind diff shows it's entirely in parse_expr_assoc_after_attrs, which this PR doesn't touch.
• The icount regressions are tiny and mostly affect deep-vector, which is a parsing stress test. tuple-stress and ucd also show up, and they are also parsing stress tests.

All of this strongly suggests this is just PGO/BOLT Brownian motion. I did one experiment in #162163 that didn't find anything of note; I don't think it's worth doing more.