Skip to content

Comments

Rollup of 5 pull requests#152992

Closed
JonathanBrouwer wants to merge 11 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-YUEJ4bE
Closed

Rollup of 5 pull requests#152992
JonathanBrouwer wants to merge 11 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-YUEJ4bE

Conversation

@JonathanBrouwer
Copy link
Contributor

Successful merges:

r? @ghost

Create a similar rollup

enthropy7 and others added 11 commits February 6, 2026 16:14
…=JonathanBrouwer

stabilize `cfg_select!`

*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)*

tracking issue: rust-lang#115585
closes rust-lang#115585
reference PR:

- rust-lang/reference#2103

# Request for Stabilization

## Summary

The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions.

```rust
cfg_select! {
    unix => {
        fn foo() { /* unix specific functionality */ }
    }
    target_pointer_width = "32" => {
        fn foo() { /* non-unix, 32-bit functionality */ }
    }
    _ => {
        fn foo() { /* fallback implementation */ }
    }
}

let is_unix_str = cfg_select! {
    unix => "unix",
    _ => "not unix",
};
println!("{is_unix_str}");
```
## Semantics

The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true.

This can be roughly expressed using this macro:
```rust
macro_rules! cfg_select {
    ({ $($tt:tt)* }) => {{
        $crate::cfg_select! { $($tt)* }
    }};
    (_ => { $($output:tt)* }) => {
        $($output)*
    };
    (
        $cfg:meta => $output:tt
        $($( $rest:tt )+)?
    ) => {
        #[cfg($cfg)]
        $crate::cfg_select! { _ => $output }
        $(
            #[cfg(not($cfg))]
            $crate::cfg_select! { $($rest)+ }
        )?
    }
}
```

The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position.

## Documentation

reference PR:

- rust-lang/reference#2103

## Tests

The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests:

- [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used.
- [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted.
## History

- rust-lang#115416
- rust-lang#117162
- rust-lang#133720
- rust-lang#135625
- rust-lang#137198
- rust-lang#138993
- rust-lang#138996
- rust-lang#143461
- rust-lang#143941
- rust-lang#145233
- rust-lang#148712
- rust-lang#149380
- rust-lang#149925

# Resolved questions

# Unresolved questions

The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323.

r? @traviscross

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_CONCERN-ISSUE_START -->

> [!NOTE]
> # Concerns (0 active)
>
> - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment))
>
> *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

<!-- TRIAGEBOT_CONCERN-ISSUE_END -->
<!-- TRIAGEBOT_END -->
…rtn, r=davidtwco

fix refining_impl_trait suggestion with return_type_notation

using `#![feature(return_type_notation)] `on top of `refining_impl_trait` made the lint suggest a pretty wild “wrap the body in `<Self as Trait>::f(..)”` fix instead of the simple “just copy the return type from the trait”. this patch makes the lint always suggest the plain return-type replacement based on the trait signature (by grabbing the original snippet when possible), so you don’t get RTN-style desugarings in the help

new test here

fixes rust-lang#151663
… r=jhpratt

Revert "Stabilize `str_as_str`"

Reverts rust-lang#151603, clean revert.
Fixes rust-lang#152961
…e-check, r=JonathanBrouwer

Remove redundant call to `check_codegen_attributes_extra` in Inliner

Inside `try_inlining`, `check_codegen_attributes` is called first. This function internally invokes `check_codegen_attributes_extra`.
However, immediately after that returns, `try_inlining` calls `check_codegen_attributes_extra` again.

First call:
https://github.com/rust-lang/rust/blob/7ec34defe9e62a1a6946d3e700b5903d8dc89ece/compiler/rustc_mir_transform/src/inline.rs#L800-L814

Second call:
https://github.com/rust-lang/rust/blob/7ec34defe9e62a1a6946d3e700b5903d8dc89ece/compiler/rustc_mir_transform/src/inline.rs#L598-L612

```rust
    // Inside try_inlining:
    check_codegen_attributes(inliner, callsite, callee_attrs)?; // Internally calls `check_codegen_attributes_extra`
    inliner.check_codegen_attributes_extra(callee_attrs)?;      // Called again here
```

In `try_inlining`, inliner is held as a shared reference (`&I`). Since `check_codegen_attributes_extra` takes `&self` and does not rely on interior mutability or external state, there does not seem to be any state change between the two calls.

Therefore, the second call appears to be redundant.

Currently, `check_codegen_attributes` is only called from `try_inlining`, and `check_codegen_attributes_extra` appears to be called only from these two locations. It seems reasonable for the `check_codegen_attributes` wrapper to handle the hook automatically.
…nBrouwer

Use `HashStable` derive in more places

This applies `HashStable` derive in a couple more places. Also `stable_hasher` is declared for `HashStable_NoContext`.
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Feb 22, 2026
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Feb 22, 2026
@JonathanBrouwer
Copy link
Contributor Author

@bors r+ rollup=never p=5

@rust-bors
Copy link
Contributor

rust-bors bot commented Feb 22, 2026

📌 Commit b48fee4 has been approved by JonathanBrouwer

It is now in the queue for this repository.

@rust-bors rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 22, 2026
@Zalathar
Copy link
Member

Yielding to newer/larger rollup at #153000, before I deal with the current #149366 which is probably stalled.

@Zalathar Zalathar closed this Feb 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants