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.

[Amanieu]

This was discussed in the @rust-lang/libs-api meeting last week. We decided to stick with the cfg_match name. Opinions were divided but in the end the syntax isn't any closer to select! than match.

[Amanieu]

As per the @rust-lang/libs-api decision in #115585 (comment), I'm re-opening this PR to rename cfg_match to cfg_select.

[Amanieu]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[tgross35]

Rebased, it looks like no bootstrap config is needed anymore.

@rustbot ready

[Amanieu]

@bors r+

[bors]

📌 Commit 999967a has been approved by Amanieu

It is now in the queue for this repository.

[bors]

⌛ Testing commit 999967a with merge 6eef33b...

[bors]

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing 6eef33b to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 5df0f72 (parent) -> 6eef33b (this PR)

Test differences

Show 28 test diffs

Stage 0

• macros::cfg_match_basic: pass -> [missing] (J0)
• macros::cfg_match_debug_assertions: pass -> [missing] (J0)
• macros::cfg_match_no_duplication_on_64: pass -> [missing] (J0)
• macros::cfg_match_options: pass -> [missing] (J0)
• macros::cfg_match_two_functions: pass -> [missing] (J0)
• macros::cfg_select_basic: [missing] -> pass (J0)
• macros::cfg_select_debug_assertions: [missing] -> pass (J0)
• macros::cfg_select_no_duplication_on_64: [missing] -> pass (J0)
• macros::cfg_select_options: [missing] -> pass (J0)
• macros::cfg_select_two_functions: [missing] -> pass (J0)

Stage 1

• macros::cfg_match_basic: pass -> [missing] (J1)
• macros::cfg_match_debug_assertions: pass -> [missing] (J1)
• macros::cfg_match_options: pass -> [missing] (J1)
• macros::cfg_match_two_functions: pass -> [missing] (J1)
• macros::cfg_select_basic: [missing] -> pass (J1)
• macros::cfg_select_debug_assertions: [missing] -> pass (J1)
• macros::cfg_select_options: [missing] -> pass (J1)
• macros::cfg_select_two_functions: [missing] -> pass (J1)
• macros::cfg_match_no_duplication_on_64: pass -> [missing] (J2)
• macros::cfg_select_no_duplication_on_64: [missing] -> pass (J2)

Additionally, 8 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: mingw-check
• J1: aarch64-apple, aarch64-gnu, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-apple-1, x86_64-gnu, x86_64-gnu-aux, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-1, x86_64-gnu-llvm-20-2, x86_64-gnu-llvm-20-3, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
• J2: aarch64-apple, aarch64-gnu, test-various, x86_64-apple-1, x86_64-gnu, x86_64-gnu-aux, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-1, x86_64-gnu-llvm-20-2, x86_64-gnu-llvm-20-3, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 6eef33bb399cabfab16aa4e0825895f5f32f4e26 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-apple-2: 4888.6s -> 5807.5s (18.8%)
2. aarch64-apple: 5119.1s -> 4287.7s (-16.2%)
3. dist-apple-various: 6446.4s -> 7217.2s (12.0%)
4. dist-x86_64-msvc-alt: 7405.5s -> 8228.3s (11.1%)
5. dist-aarch64-apple: 5421.3s -> 5952.6s (9.8%)
6. x86_64-apple-1: 8252.9s -> 8782.1s (6.4%)
7. armhf-gnu: 4421.9s -> 4698.2s (6.2%)
8. dist-x86_64-musl: 7160.2s -> 7516.8s (5.0%)
9. dist-x86_64-apple: 8737.7s -> 9150.5s (4.7%)
10. x86_64-mingw-2: 7376.8s -> 7050.0s (-4.4%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (6eef33b): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -1.7%, secondary -3.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.7%	[-1.7%, -1.7%]	1
Improvements ✅ (secondary)	-3.7%	[-3.7%, -3.7%]	1
All ❌✅ (primary)	-1.7%	[-1.7%, -1.7%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 776.959s -> 777.17s (0.03%)
Artifact size: 365.55 MiB -> 365.60 MiB (0.01%)