[jieyouxu]

I'm actually not sure if these are supposed to be compiler FCP, lang FCP, or dual compiler/lang FCP. I'm going to use compiler/lang dual FCP since that's what we are doing in rust-lang/rust#160877.

cc @RalfJung
r? @davidtwco / @BoxyUwU (compiler co-lead)
cc @tmandry (lang lead)

Rendered

[RalfJung]

I'm going to use compiler/lang dual FCP since that's what we are doing in rust-lang/rust#160877.

That is more the exception than the norm though. Most target feature stabilizations I saw were just t-lang.

Most target features are fairly straight-forward on the implementation side. They just forward things to LLVM. The tricky part is ensuring that there are no ABI issues or other incompatibilities that could arise when mixing code with and without the feature. I don't know if pinging the t-compiler FCP group will help catch those problems, ideally we'd have a more targeted group of experts specifically for that area (wg-abi or whatever).

OTOH target features are also mostly trivial on the lang side, it's just yet another value in an attribute that already accepts many values (and a cfg). If the Reference just said "there exists a target-specific implementation-defined list of target features; they can be enabled/disabled globally via -Ctarget-feature, their global status can be queried via cfg(target_feature), and they can be enabled locally via #[target_feature]" -- then arguably adding a new one wouldn't really be a language change. I don't know much much t-lang discusses the details of these target features when they are part of the FCP. Maybe this is something where we can reduce their load a little, at least for the "boring" features.

[tmandry]

I agree that by the time they get to us, most target features are small reviews from a lang perspective. I still see value in having lang review though. For one, the process of preparing a stabilization report for the team is valuable in itself. We also need someone to specifically review the names, and it's unclear who else would do it.

I would like to break out specialized groups for reviewing lang items like this. That should improve the turnaround time and the load on the team.

If the Reference just said "there exists a target-specific implementation-defined list of target features; they can be enabled/disabled globally via -Ctarget-feature, their global status can be queried via cfg(target_feature), and they can be enabled locally via #[target_feature]" -- then arguably adding a new one wouldn't really be a language change.

I wouldn't go so far as to say the list is implementation-defined. I don't want to encourage a situation where different implementations define their own set of names for the same features. At best I would say it's an "implementation-defined subset", but in practice alternative implementations are all subsets anyway.

[RalfJung]

Thanks! Makes sense.

Let's see what @davidtwco / @BoxyUwU are thinking for the compiler side here.