Tracking issue for the `matches!` macro

[SimonSapin]

#65479 adds this macro to the prelude:

#[macro_export]
macro_rules! matches {
    ($expression:expr, $( $pattern:pat )|+ $( if $guard: expr )?) => {
        match $expression {
            $( $pattern )|+ $( if $guard )? => true,
            _ => false
        }
    }
}

Example usage:

let foo = 'f';
assert!(matches!(foo, 'A'..='Z' | 'a'..='z'));

let bar = Some(4);
assert!(matches!(bar, Some(x) if x > 2));

[SimonSapin]

This caused a regression in html5ever because the prelude macro becomes ambiguous with a macro that was brought into scope by a glob import: servo/html5ever#402

@rust-lang/lang, could we make that situation not an error? It seems that we could resolve the ambiguity in favor of the glob import since it is "more local" to the rest of the code in the module.

[eddyb]

cc @petrochenkov

[petrochenkov]

could we make that situation not an error?

For macros (and imports) it's hard to do.

To remove the ambiguity error we need to prove that with any expansion order and any import resolution order matches materializes from the use mac::* glob "not later" than from prelude.

Otherwise we'll get code that compiles today but not tomorrow depending on random implementation details. (Making e.g. things like this impossible.)

[SimonSapin]

I have a memory of a change made to treat differently during name resolution items that are unstable, so that new standard library addition can (at first) warn instead of error when they conflict with existing code. However I couldn’t find this again. Maybe it was only for traits?

[petrochenkov]

Yeah, that was for method resolution.

[SimonSapin]

Would a similar special case for unstable prelude items make sense?

[SimonSapin]

The 1.42 cycle starts soon. Any objection?

@rfcbot fcp merge