Remove unstable cfg target(...) compact feature

[Urgau]

This PR removes the unstable cfg_target_compact feature from #96901, which permits compact target(...) cfgs (e.g. cfg(target(os = "linux")) -> cfg(target_os = "linux")).

The feature:

• is only used in one crate: GitHub Search (not even in the compiler)
• has received no activity on the tracking issue
• has not received any stabilization request since it's nightly introduction (~2yrs ago)
• was part of a bigger feature that was already withdrawn
• is limited to target_* cfgs
• is not implemented by Cargo (and rustdoc doc_cfg feature)
• it's only useful when one has multiple target_* cfgs consecutively
  as it will only save you the "target_" part on the second cfg
• one still need to do the mapping it's in head, not saving much
  target(os = "linux", env = "") means target_os = "linux", target_env = "" in every other place

All this to say that I don't think the feature pulls its weight.

@rustbot label +I-lang-nominated
Closes #96901

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[lqd]

Wasn’t this helping to remove some use cases for build scripts?

[Urgau]

The part that was supposed to help with build script was the cfg(target = "...") part of the RFC, but that part was already withdrawn.

[lqd]

IIRC the target abi was only matchable in build scripts, is that still the case today (with and without this PR)? To be able to lower the need for build scripts in the ecosystem we need cfgs to be at least isomorphic…

[Urgau]

This PR doesn't change anything for matching on specific target cfgs components. This PR only removes the shorthand cfg(target(os = "linux")) -> cfg(target_os = "linux").

As for the target abi, the target_abi cfg was stabilized in 1.78.

[lqd]

Good. Thank you for the clarifications.

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

[traviscross]

So, strictly speaking, removing something unstable from the compiler doesn't need our lang OK. If compiler wants to say, "we're not happy with the implementation, we're going to pull it out until someone tries again", or "this is in the way, and it's not on track to be stabilized soon, so we're going to pull it out", then that can just be done, though we appreciate a heads-up and CC on it, especially if it's in the critical path of something on our radar.

On this one though, I do read it as a lang request. (This is what I think you had in mind also; I'm saying this all for the benefit of others.) The implementation seems fine, and it's not a lot of code, and it doesn't seem in the way of anything. So it's basically just a prompt to ask the lang question of whether this is something we still want or not.

In that light, this is nominated, and we'll try to get to it (no promises on timing), but also, let's ping everyone and maybe we'll collect some thoughts.

@rust-lang/lang: What do we think? Do we still want #[cfg(target(..))]?

[joshtriplett]

I mildly appreciated the idea of the target shorthand syntax. I think it's not useful to count occurrences in code search, because (like most convenience features) nobody is going to use nightly just for a convenience feature; people will wait for it to be in stable before using it. That said, it's a small feature that provides a small amount of value; it's not going to be earth-shattering, whether it stays or goes. If anyone feels like it doesn't carry enough weight, or if it adds any non-trivial complexity to cfg, by all means let's drop it.

[traviscross]

Pulling it out drops only 28 lines of entirely plain and boring code. It all seems to come down, I think, to whether or not this is something we want to let people write.

Agreed that use in nightly is a poor metric, especially here. I'd never use this until we had stabilized it.