Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for the matches! macro #65721

Closed
SimonSapin opened this issue Oct 23, 2019 · 16 comments · Fixed by #67659
Closed

Tracking issue for the matches! macro #65721

SimonSapin opened this issue Oct 23, 2019 · 16 comments · Fixed by #67659
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) B-unstable Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. requires-nightly This issue requires a nightly compiler in some way. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@SimonSapin
Copy link
Contributor

@SimonSapin SimonSapin commented Oct 23, 2019

#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 SimonSapin added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. B-unstable Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Oct 23, 2019
SimonSapin added a commit to SimonSapin/rust that referenced this issue Oct 23, 2019
SimonSapin added a commit to SimonSapin/rust that referenced this issue Oct 23, 2019
@Centril Centril added the requires-nightly This issue requires a nightly compiler in some way. label Oct 24, 2019
@SimonSapin
Copy link
Contributor Author

@SimonSapin SimonSapin commented Oct 25, 2019

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
Copy link
Member

@eddyb eddyb commented Oct 25, 2019

cc @petrochenkov

@petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Oct 25, 2019

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
Copy link
Contributor Author

@SimonSapin SimonSapin commented Oct 25, 2019

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
Copy link
Contributor

@petrochenkov petrochenkov commented Oct 25, 2019

Yeah, that was for method resolution.

@SimonSapin
Copy link
Contributor Author

@SimonSapin SimonSapin commented Oct 25, 2019

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

@SimonSapin
Copy link
Contributor Author

@SimonSapin SimonSapin commented Dec 16, 2019

The 1.42 cycle starts soon. Any objection?

@rfcbot fcp merge

@rfcbot
Copy link

@rfcbot rfcbot commented Dec 16, 2019

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Dec 16, 2019
@jonhoo
Copy link
Contributor

@jonhoo jonhoo commented Dec 16, 2019

Should we also add a assert_matches! macro at the same time that Debug-prints the value if the match fails?

@SimonSapin
Copy link
Contributor Author

@SimonSapin SimonSapin commented Dec 16, 2019

I personally find that one less useful, but feel free to also propose it in a PR.

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Dec 16, 2019
@rfcbot
Copy link

@rfcbot rfcbot commented Dec 16, 2019

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added the finished-final-comment-period The final comment period is finished for this PR / Issue. label Dec 26, 2019
@rfcbot
Copy link

@rfcbot rfcbot commented Dec 26, 2019

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

@rfcbot rfcbot removed the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Dec 26, 2019
oli-obk added a commit to oli-obk/rust that referenced this issue Dec 27, 2019
@bors bors closed this as completed in 1c572a2 Dec 28, 2019
@jonhoo
Copy link
Contributor

@jonhoo jonhoo commented Dec 28, 2019

How do we feel about giving this the "relnotes" tag?

@tesuji
Copy link
Contributor

@tesuji tesuji commented Dec 28, 2019

Already on the stabilized PR: #67659

@SimonSapin
Copy link
Contributor Author

@SimonSapin SimonSapin commented Dec 28, 2019

@jonhoo I thought RELEASES.md listed all new(ly-stabilized) APIs? I added relnotes to the stabilization PR on that basis. That’s what the label is for, right? This is not to say this should necessarily be mentioned in the release blog post.

@danielhenrymantilla
Copy link
Contributor

@danielhenrymantilla danielhenrymantilla commented Mar 6, 2020

Could matches! be enhanced to also accept a leading |?

matches!(expr,
    | SomeFirstPattern
    | SomeOtherPattern
    ...
);

This would be consistent with the syntax of Rust accepting it where fallible patterns are accepted:

match expr {
    | SomeFirstPattern $(=> ...)?
    | SomeOtherPattern => ...
}

striezel added a commit to striezel/corona that referenced this issue Dec 24, 2020
The Rust compiler version on Debian 10 ("Buster") does not support
the matches_macro feature used in rusqlite 0.24.2. It fails with

    error[E0658]: use of unstable library feature 'matches_macro'
       --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/rusqlite-0.24.2/src/types/from_sql.rs:146:44
        |
    146 |         i64::column_result(value).map(|i| !matches!(i, 0))
        |                                            ^^^^^^^
        |
        = note: for more information, see rust-lang/rust#65721
    error: aborting due to previous error
    For more information about this error, try `rustc --explain E0658`.
    error: could not compile `rusqlite`.

when trying to compile rusqlite 0.24.2. However, it does compile
with the older version 0.23.1 of rusqlite. Until there is a more
recent Rust compiler version available in Debian 10, e.g. via the
backports repository, it will probably stay at this version.
myoung-ukcloud added a commit to UKCloud/create-vdc-with-edge-portal-api-demo that referenced this issue May 6, 2021
With rust 1.41 the build was failing with errors such as:

According to the following pages this is due to a minimum requirement
of rust 1.42

rust-lang/rust#65721
diem/diem#3558

Updated to almost latest rust 1.51. 1.52 was released today but
is not available in the docker repository
kodiakhq bot pushed a commit to sbdchd/squawk that referenced this issue Oct 31, 2021
For some reason ran into rust-lang/rust#65721 and rust-lang/rust#49146 along with some other misc compiler errors and lints

Feels like every time I come back to this project the rust versions get out of wack
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) B-unstable Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. requires-nightly This issue requires a nightly compiler in some way. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants