Match guard pattern as macro output is unused

[krzysiek4321]

guard patterns tracking issue: #129967

Edit history:

• corrected (0 -> 7) discriminant in code snippet to match expanded snippets

I tried this code:

#![feature(guard_patterns)]

macro_rules! guard {
    ($disc:literal if $cond:expr) => { $disc if $cond };
}

pub fn test(left: u64, right: u64) {
    match left {
        guard!(7 if 3 == right >> 1 & 0xf) => panic!("Bingo"),
        guard!(7 if 4 == right >> 1 & 0xf) => panic!("Bongo"),
        _ => (),
    }
}

I expected the guard macro to expand like this:

pub fn test(left: u64, right: u64) {
    match left {
        7 if 3 == right >> 1 & 0xf => {
            ::core::panicking::panic_fmt(format_args!("Bingo"));
        }
        7 if 4 == right >> 1 & 0xf => {
            ::core::panicking::panic_fmt(format_args!("Bongo"));
        }
        _ => (),
    }
}

Instead, this happened:

pub fn test(left: u64, right: u64) {
    match left {
        (7 if 3 == right >> 1 & 0xf) => {
            ::core::panicking::panic_fmt(format_args!("Bingo"));
        }
        (7 if 4 == right >> 1 & 0xf) => {
            ::core::panicking::panic_fmt(format_args!("Bongo"));
        }
        _ => (),
    }
}

Which caused the `right` parameter to be marked as unused and second match arm to be marked as unreachable.

cargo build

warning: the feature `guard_patterns` is incomplete and may not be safe to use and/or cause compiler crashes
 --> src/lib.rs:1:12
  |
1 | #![feature(guard_patterns)]
  |            ^^^^^^^^^^^^^^
  |
  = note: see issue #129967 <https://github.com/rust-lang/rust/issues/129967> for more information
  = note: `#[warn(incomplete_features)]` on by default

warning: unreachable pattern
  --> src/lib.rs:10:16
   |
 9 |         guard!(7 if 3 == right >> 1 & 0xf) => panic!("Bingo"),
   |                - matches all the relevant values
10 |         guard!(7 if 4 == right >> 1 & 0xf) => panic!("Bongo"),
   |                ^ no value can reach this
   |
   = note: `#[warn(unreachable_patterns)]` (part of `#[warn(unused)]`) on by default

warning: unused variable: `right`
 --> src/lib.rs:7:24
  |
7 | pub fn test(left: u64, right: u64) {
  |                        ^^^^^ help: if this is intentional, prefix it with an underscore: `_right`
  |
  = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

warning: `macro_test` (lib) generated 3 warnings (run `cargo fix --lib -p macro_test` to apply 1 suggestion)

In latest version of nightly in assembly even the left == 7 check is dropped

.section .text.unlikely.macro_test::test,"ax",@progbits
	.globl	macro_test::test
	.p2align	4
.type	macro_test::test,@function
macro_test::test:
	.cfi_startproc
	push rbp
	.cfi_def_cfa_offset 16
	.cfi_offset rbp, -16
	mov rbp, rsp
	.cfi_def_cfa_register rbp
	lea rdi, [rip + .Lanon.3d08d0a897f173f2df1f3db7ed6d9c12.0]
	lea rdx, [rip + .Lanon.3d08d0a897f173f2df1f3db7ed6d9c12.2]
	mov esi, 11
	call qword ptr [rip + core::panicking::panic_fmt@GOTPCREL]

In version from december 2025 the left check was still present

.section .text.macro_test::test,"ax",@progbits
	.globl	macro_test::test
	.p2align	4
.type	macro_test::test,@function
macro_test::test:
	.cfi_startproc
	cmp rdi, 7
	je .LBB0_2
	ret
.LBB0_2:
	push rbp
	.cfi_def_cfa_offset 16
	.cfi_offset rbp, -16
	mov rbp, rsp
	.cfi_def_cfa_register rbp
	lea rdi, [rip + .Lanon.bfdb341b1ef1d5aa463dafe853c0b238.0]
	lea rdx, [rip + .Lanon.bfdb341b1ef1d5aa463dafe853c0b238.2]
	mov esi, 11
	call qword ptr [rip + core::panicking::panic_fmt@GOTPCREL]

rustc 1.94.0-nightly (24139cf84 2025-12-20)
binary: rustc
commit-hash: 24139cf844095e574708faf406034dc78cb39143
commit-date: 2025-12-20
host: x86_64-unknown-linux-gnu
release: 1.94.0-nightly
LLVM version: 21.1.8

Meta

rustc --version --verbose:

rustc 1.96.0-nightly (f66622c7e 2026-03-23)
binary: rustc
commit-hash: f66622c7eca7fc48ccc4dac848ff911b09a4d566
commit-date: 2026-03-23
host: x86_64-unknown-linux-gnu
release: 1.96.0-nightly
LLVM version: 22.1.0

[bjorn3]

At the MIR level already this becomes an unconditional panic:

fn test(_1: u64, _2: u64) -> () {
    debug left => _1;
    debug right => _2;
    let mut _0: ();
    let _3: !;
    let mut _4: std::fmt::Arguments<'_>;

    bb0: {
        _4 = Arguments::<'_>::from_str(const "Bingo") -> [return: bb1, unwind continue];
    }

    bb1: {
        _3 = std::rt::panic_fmt(move _4) -> unwind continue;
    }
}

[theemathas]

FYI, currently, guard_patterns is basically not implemented at all. It is completely non-functional.

[bjorn3]

Shouldn't it be marked as incomplete feature then?

[theemathas]

It's already marked as an incomplete feature.

[bjorn3]

Indeed. Missed that.

[theemathas]

@krzysiek4321 To explain the current compiler behavior, the if syntax there isn't a part of patterns. It's a part of the match syntax. And macros can expand only to expressions, types, statements, items, and patterns (and a couple more things). Macros cannot expand into "a pattern plus an if". Except that with the guard_patterns feature, a pattern can have an if in it, although it's currently nonfunctional.

[theemathas]

Also, macro outputs are treated as if they have "invisible parentheses" around them.

[krzysiek4321]

@theemathas Please, tell me if I understood wrong. The AST doesn't yet recognize the guard_pattern as a pattern therefore it got expanded into an expression and wrapped in parens "()"?

[theemathas]

Sorry, but I don't understand what you're saying.

Currently, with the guard_patterns feature enabled, the compiler can parse guard patterns, but won't compile them into actually behaving as guards.

[theemathas]

The parentheses in the expansion being visible (instead of "invisible") is probably just a quirk of cargo expand or whatever method you used to inspect the macro expansion.

[krzysiek4321]

Yes I used cargo expand. I was thinking about how rust interprets the macro output. I'm wondering why in previous version the compiler actually included the check left == 7 while the current nightly didn't.

[theemathas]

I don't know. If you want to, you could use cargo-bisect-rustc to find out which PR changed the behavior.