Tracking Issue for generic pattern types #136574

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?
  • Pattern types: Avoid having to handle an Option for range ends in the type system or the HIR #136922 (comment)
• Should we have an implied bound for all signatures that have such a pattern type?

Implementation history

• Allow using named consts in pattern types #136284 (named constants had some related discussion)