Port #[target_feature] to new attribute parsing infrastructure

[JonathanBrouwer]

Ports target_feature to the new attribute parsing infrastructure for #131229 (comment)

r? @jdonszelmann

[JonathanBrouwer]

I've changed ConvertFn to an enum so I can also keep track of the span of the first attribute. I use this span to lint on the attribute itselfs (rather than one of the elements) for a few of the diagnostics. Does this seem reasonsable?

[obi1kenobi]

This should probably bump the rustdoc JSON FORMAT_VERSION too. This attribute is used by cargo-semver-checks today, and should probably also be in the rustdoc JSON test suite as well.

cc @aDotInTheVoid purely for awareness

[JonathanBrouwer]

Ah, I missed it because it's not part of the tests for rustdoc-json. I'll make sure to give this attribute the nice formatting too, and to bump the FORMAT_VERSION

[obi1kenobi]

Ah, I missed it because it's not part of the tests for rustdoc-json. I'll make sure to give this attribute the nice formatting too, and to bump the FORMAT_VERSION

You are my favorite person!

Just noting that this attribute has three valid forms:

• it can be repeated on the same item, like #[target_feature(enable = "one")] #[target_feature(enable = "another")]
• it can have multiple enable clauses, like #[target_feature(enable = "one", enable = "another")], and
• it can have multiple features in the same enable clause, like #[target_feature(enable = "one,another")]

I believe any mix of these is also legal. For nice formatting, I don't have strong feelings how we normalize so long as we do normalize if at all possible. The last form is the most compact and IIRC how the attribute is explained in the docs, so all else equal that's what I'd pick if I were choosing. But feel free to do whatever is easiest.

And yes, entirely reasonable to miss it since we never tested it. We never tested it because it's only the new cargo-semver-checks releasing ~this week that uses it :)

[JonathanBrouwer]

I encountered these the hard way when writing the attribute :p I discover so much about Rust when doing these refactorings
Actually, since I do the pretty printing, does the FORMAT_VERSION even need to be bumped? Or does the normalizing count as a change?

[rustbot]

These commits modify tests/rustdoc-json.
rustdoc-json is a public (but unstable) interface.

Please ensure that if you've changed the output:

• It's intentional.
• The FORMAT_VERSION in src/librustdoc-json-types is bumped if necessary.

cc @aDotInTheVoid, @obi1kenobi

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_codegen_ssa/src/codegen_attrs.rs

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_attr_data_structures

cc @jdonszelmann

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

cc @jdonszelmann

[JonathanBrouwer]

This push should fix the pretty printing for rustdoc. Thanks for the feedback <3
I didn't end up bumping the FORMAT_VERSION but if I need to lmk

[obi1kenobi]

I think normalizing to an already-valid form doesn't need to bump the format version, since any downstream consumers would have had to be able to handle it already.

[JonathanBrouwer]

@rustbot ready
r? @jdonszelmann

[rustbot]

jdonszelmann is currently at their maximum review capacity.
They may take a while to respond.

[jdonszelmann]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[bors]

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

[JonathanBrouwer]

Fixed the issues above & rebased on master
@rustbot ready