Replace `#[rustc_args_required_const(n)]` with per-argument attr

[ecstatic-morse]

RFC 2565, which was recently stabilized, allows individual function parameters to have attributes. One of the motivating examples for that RFC was the ugliness of #[rustc_args_required_const], which specifies the const argument(s) by index. We should transition away from #[rustc_args_required_const] to a per-argument attribute.

@petrochenkov has proposed #[rustc_required_const]. These attributes are perma-unstable so there are no backwards compatibility concerns.

[petrochenkov]

[triagebot] 👍

EDIT: I'm not attached to the mentioned naming.

[jakevossen5]

I would be willing to take this up. Are there any mentors out there who could be available if I have questions?

@rustbot claim

[LeSeulArtichaut]

@jakevossen5 Are you still working on this? Or can I take it up?

[jakevossen5]

@LeSeulArtichaut , Apologies, I have gotten a bit busy in the past week. I am still working on this and hopefully have a PR up sometime next week.

[eddyb]

Ironically, the benefit from this is pretty minor, and it'd be trickier to implement than today, because the param attributes aren't kept cross-crate, so they need to be encoded some other way.

Probably a decent way would be to add a Lazy<BitSet> to this, I guess?

rust/src/librustc_metadata/rmeta/mod.rs

Lines 327 to 331 in c6b172f

	struct FnData {
	asyncness: hir::IsAsync,
	constness: hir::Constness,
	param_names: Lazy<[ast::Name]>,
	}

[jakevossen5]

@eddyb Do you mean a new element of the struct, like param_consts that keeps track of which are constants? Do I understand that correctly?

[eddyb]

I think we should resolve #70271 first before touching #[rustc_args_required_const] further.

[jakevossen5]

Sounds good. I will watch that thread and when it it closed circle back to here.