Tracking Issue for generic pattern types

The feature gate for the issue is #![feature(generic_pattern_types)].

We do not correctly wf-check pattern types in generic contexts:

#![feature(generic_pattern_types)]
#![feature(pattern_type_range_trait)]
#![feature(const_trait_impl)]
#![feature(pattern_types)]
#![feature(pattern_type_macro)]
use std::pat::pattern_type;

fn foo<const A: u32>() -> pattern_type!(u32 is A..10) {
    assert!(A < 10);
    unsafe {
        std::mem::transmute(9)
    }
}

only errors (during monomorphization, with a very unreadable error) if foo is used with an A >= 10.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Use the associated zulip thread for discussions.

Steps

• Write an RFC
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Should we allow these at all?
• How can we solve this with min const generic expressions?
  • https://github.com/rust-lang/rust/pull/136922#issuecomment-2683310080
• Should we have an implied bound for all signatures that have such a pattern type?

Implementation history

• https://github.com/rust-lang/rust/pull/136284 (named constants had some related discussion)

Start with the generic_pattern_types example and the associated Zulip thread linked in the issue. Review the unresolved questions and the tracking checklist, including the RFC, documentation, formatting, and stabilization steps. Done means the design is resolved and the relevant implementation and stabilization work has been completed.