Skip to content

Rollup of 5 pull requests#152993

Closed
jhpratt wants to merge 11 commits intorust-lang:mainfrom
jhpratt:rollup-LDv6JR4
Closed

Rollup of 5 pull requests#152993
jhpratt wants to merge 11 commits intorust-lang:mainfrom
jhpratt:rollup-LDv6JR4

Conversation

@jhpratt
Copy link
Member

@jhpratt jhpratt commented Feb 22, 2026

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
@jhpratt
Copy link
Member Author

jhpratt commented Feb 22, 2026

closing in favor of #152992

@jhpratt jhpratt closed this Feb 22, 2026
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 22, 2026
@jhpratt jhpratt deleted the rollup-LDv6JR4 branch February 22, 2026 22:50
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 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