False positive in non_exhaustive_omitted_patterns: matches!

[dtolnay]

#![feature(non_exhaustive_omitted_patterns_lint)]
#![warn(non_exhaustive_omitted_patterns)]

use core::sync::atomic::Ordering;

pub fn is_relaxed(ordering: Ordering) -> bool {
    matches!(ordering, Ordering::Relaxed)
}

warning: some variants are not matched explicitly
 --> src/lib.rs:7:14
  |
7 |     matches!(ordering, Ordering::Relaxed)
  |              ^^^^^^^^ patterns `std::sync::atomic::Ordering::Release`, `std::sync::atomic::Ordering::Acquire`, `std::sync::atomic::Ordering::AcqRel` and 1 more not covered
  |
  = help: ensure that all variants are matched explicitly by adding the suggested match arms
  = note: the matched value is of type `std::sync::atomic::Ordering` and the `non_exhaustive_omitted_patterns` attribute was found
note: the lint level is defined here
 --> src/lib.rs:2:9
  |
2 | #![warn(non_exhaustive_omitted_patterns)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I believe the lint should not trigger on this code. For comparison, it correctly does not trigger on this alternative implementation of the same function:

pub fn is_relaxed(ordering: Ordering) -> bool {
    if let Ordering::Relaxed = ordering {
        true
    } else {
        false
    }
}

Conceptually, for the purpose of exhaustiveness, matches! more closely resembles if let than match, even if the standard library implementation currently involves match internally in order to support guard expressions.

The non_exhaustive_omitted_patterns should only trigger on this variation of this function.

pub fn is_relaxed(ordering: Ordering) -> bool {
    match ordering {
        Ordering::Relaxed => true,
        _ => false, // warning: non exhaustive omitted patterns
    }
}

• Tracking issue: Tracking Issue for #![feature(non_exhaustive_omitted_patterns_lint)] #89554

[taiki-e]

I think this is the same issue as #117304.