fix: extract rustc_test_marker attr in test_case

[bvanjoi]

Fixes #100263

To prevent ice caused by normal.tokens.as_ref.unwrap(), which attempts to unwrap the None generated by attr_name_value_str

[rustbot]

r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

[WaffleLapkin]

r? compiler
(I'm not really available this week)

[bvanjoi]

@petrochenkov I noticed that you were the reviewer for #53410. Could you assist in reviewing this PR?

[jackh726]

So, very unfamiliar with this code. But this doesn't seem right to me?

The behavior of this code on master seems to change item visibility to public and adds rustc_test_marker attr. With this change, the item is duplicated (without a visibility change) and the rustc_test_marker attr is added to that? And the actual item gets its visibility changed to public?

I think this needs at least a bit more explanation for me to feel comfortable. Let's see what @petrochenkov has to say though.

r? @petrochenkov

[petrochenkov]

I also don't understand why this PR generates an additional item.

If some built-in macro generates code (AST) visible to other macros as input, then it should set tokens in it as well (preferably correct tokens).
@rustbot author

[bvanjoi]

With this change, the item is duplicated (without a visibility change) and the rustc_test_marker attr is added to that?

Its goal is to prevent the attribute(generated by attr_name_value_str) from being appended to outer_attrs, which would then unwrap the token field and potentially trigger a panic.

If some built-in macro generates code (AST) visible to other macros as input, then it should set tokens in it as well (preferably correct tokens).

Thanks. I will look into this matter further.

I have a question: is this method applicable to the #[test] macro? Because these changes in this PR make #[test_case] more similar to #[test] by generating multiple attributes and ensuring that rustc_test_marker is not inserted into outer_attrs.

[petrochenkov]

Is test_case even used anymore?
It was originally emitted by #[test] and #[bench], but that's not the case anymore.
All this stuff may be an outdated garbage, and the whole system likely needs a redesign.
So it doesn't matter much how it works, as longs as nothing stable breaks, until some new future system is implemented.

So I suggest just setting the missing tokens to a new empty token stream and move on, nobody is using test_case with other proc macros anyway.
Or you can report an error when a non-builtin macro is found when expanding test_case.
I don't want to spend time on this.

[Dylan-DPC]

@bvanjoi any updates on this?

[bvanjoi]

Closing this as it doesn't provide substantial help.