Reduce boilerplate with the matches! macro

[LingMan]

Replaces simple bool matches of the form

match $expr {
    $pattern => true
    _ => false
}

and their inverse with invocations of the matches! macro.

Limited to rustc_middle for now to get my feet wet.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @varkor (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[tesuji]

Does this affect compile time of compiler?

[tmandry]

@lzutao It's only a macro expansion, I doubt it would have any measurable effect on the compiler build.

[LingMan]

Since macro expansion already happens with ./x.py check, I did this to get an idea:

$ git switch master
$ ./x.py check
[snip, just to fill the cache]
$ git switch middle_matches
$ ./x.py check
Build completed successfully in 0:01:26
$ git switch master
$ ./x.py check
Build completed successfully in 0:01:26

Not perfectly scientific but hopefully this is enough to address your compile time concerns.

[Mark-Simulacrum]

I don't think we should worry about trivial compile time +/- like a few macros until we start tracking it (hopefully soon!).

I felt that the patch as a whole improved readability, and though I am not 100% sure we want to use matches! whenever a boolean output is expected, I think in the cases provided here it made sense to do so for the most part. I was uncertain if we should do so when we want !matches!(exp, pat), because I personally find the not blends in for me -- curious to here what others think. I think when looking at a particular case, it's not bad, but it does feel like it blends in a bit (in particular since there's already a ! sigil right after the macro).

cc @rust-lang/libs if y'all are interested in seeing some real-world examples of matches use or have thoughts on the !matches!(exp, pat) pattern (easily searched for in the diff if you want).

[varkor]

These all seem like improvements to me. I'll wait a while to see if anyone else has an opinion, but otherwise it looks good.

[LingMan]

I feel what @Mark-Simulacrum said regarding !matches!(exp, pat). It does blend in, although with the original expanded match blocks true/false and false/true also started to blend fairly quickly while writing this. Possibly because those two words are of similar length and the first case is far more common than the second.

Certainly made me check for something like matches_not!(exp, pat).

[varkor]

@bors r+ rollup

Thanks!

[bors]

📌 Commit a6ff925 has been approved by varkor

[joshtriplett]

I think the appearance of !matches! is one more good argument for a first-class operator like is. But until we have that, !matches!(...) doesn't seem unreasonable.