matches macro conflicts with matches crate

[Mark-Simulacrum]

cc #65721

https://crater-reports.s3.amazonaws.com/beta-1.40-1/beta-2019-11-06/reg/bronzedb-protocol-0.1.0/log.txt

Any(?) crate using the matches crate from crates.io is likely to have breakage as the macro there will be ignored in favor of the std macro at least in some cases.

[Mark-Simulacrum]

cc @rust-lang/libs

[SimonSapin]

Any(?) crate using the matches crate from crates.io

It’s not any crate. Servo’s dependency graph includes a number of users of matches, but we didn’t run into this particular issue.

We did run into glob imports becoming ambiguous servo/html5ever#402, but this is different. This code is already importing use matches::matches; specifically:

https://github.com/Hexilee/BronzeDB/blob/8ac9214633872e6869645b027595396d18781b2d/bronzedb-protocol/src/request.rs#L129

The only thing of note I see is that matches! is used inside the expansion of a local macro_rules! macro assert_delete, which in turned is used in the arguments (and presumably these tokens are forwarded as-is in the expansion) of an external procedural macro speculate:

https://github.com/utkarshkukreti/speculate.rs/blob/4e1a6f4c6dfc325dd9609ba890fc5f0bb4c6e2c8/src/lib.rs#L141-L142

That part of the macro’s input is parsed as syn::Block, then the syn::Stmt’s in the block are extracted and used in quote::quote_spanned!. I don’t know if any of this affects name resolution / hygiene.

It looks like the “connection” between the import and the use is “lost”. But what’s surprising is that this (seemingly) happens in 1.40.0 whereas the same code in 1.39.0 does resolve to the import, it doesn’t fail to resolve.

Does 1.40 also include changes to macro hygiene?

[jonas-schievink]

cc @petrochenkov

[pnkfelix]

triage: P-high; need to at least determine scope of what changed here. And preferably do a bisection. Leaving nominated for now.

[petrochenkov]

what changed here

matches was added to the standard library prelude.
The compiler / language didn't change.

We did run into glob imports becoming ambiguous servo/html5ever#402, but this is different.

The error says

error[E0659]: `matches` is ambiguous (glob import vs any other name from outer scope during import/macro resolution)

so it looks like the same issue?
The error even shows the glob's span, but it points to some macro arguments, so the glob is probably produced by a macro.

[SimonSapin]

Oh sorry, I was looking at the first errors which do not mention ambiguity or glob and missed that later errors do.

[INFO] [stderr] error[E0658]: use of unstable library feature 'matches_macro'
[INFO] [stderr]    --> src/request.rs:152:21
[INFO] [stderr]     |
[INFO] [stderr] 152 |             assert!(matches!(&new_request, Request::Delete(ref _key)));
[INFO] [stderr]     |                     ^^^^^^^
[INFO] [stderr] ...
[INFO] [stderr] 162 |                 assert_delete!(b"name");
[INFO] [stderr]     |                 ------------------------ in this macro invocation
[INFO] [stderr]     |
[INFO] [stderr]     = note: for more information, see https://github.com/rust-lang/rust/issues/65721

… and there is the glob import:

https://github.com/utkarshkukreti/speculate.rs/blob/4e1a6f4c6dfc325dd9609ba890fc5f0bb4c6e2c8/src/generator.rs#L40-L47

        quote_spanned!(name.span() =>
            mod #name {
                #[allow(unused_imports)]
                use super::*;

So yes it’s the same issue. Thanks @petrochenkov.

I’ve already written my thoughts on this at #65721 (comment).

[pnkfelix]

okay, based on the dialogue here, I'm treating this as not a T-compiler thing.

(@SimonSapin did propose some compiler/diagnostic changes to try to mitigate the effect of additions like this, in #65721, but that doesn't change the fact that this is still just a library issue, not a compiler or language one.)

Removing T-compiler label.

[Mark-Simulacrum]

Closing as we've "eaten" this at this point as it's landed into stable.