Rename cfg_match! to cfg_select!

[tgross35]

@Nemo157 pointed out that cfg_match! syntax does not actually align well with match syntax, which is a possible source of confusion. The comment points out that usage is instead more similar to ecosystem select! macros. Rename cfg_match! to cfg_select! to match this.

Tracking issue: #115585

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[tgross35]

r? libs-api

[joshtriplett]

Nominating for discussion.

[joshtriplett]

Speaking for myself only: not in favor of this rename.

[bors]

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

[tgross35]

From the meeting notes, TC mentioned cfg_cond as an alternative.

[traviscross]

That is what I always called the macro myself, in my versions. It's probably the most correct PL theory name for the construct.

cond is what you get in Rust if you write:

match () {
    _ if predicate1 => ..,
    _ if predicate2 => ..,
    _ if predicate3 => ..,
    _ => ..,
}

(That is, as if let .. = .. else if let .. is to match, if .. else if .. is to cond.)

So it's in that sense that I think cfg_match! is fine too, as this is a kind of match that's been stripped down that way. But... yes, cfg_cond! is probably more correct.

[ChrisDenton]

I don't have a strong opinion here only that having "match" in the name when it is notably different to match is less than ideal. On the other hand it's not the end of the world if I have to teach and explain that this match is a bit different to that match. It's just kinda awkward.