Macro invocations bypass new keyword identifier checks

[alexcrichton]

This code currently compiles on nightly:

#![warn(rust_2018_compatibility)]
#![feature(rust_2018_preview)]

macro_rules! r#async {
    () => ()
}

fn main() {
    async!();
}

.. with no warnings, but it should get a warning about the macro invocation!

cc @zackmdavis, do you know if there's a good location we can run lints before macro expansion? I think the bug here is that the macro is fully expanded by the time we hit the lint passes, so it's not even present in the AST.

[Centril]

So there's an unresolved question in #50412 about try!(..).
Depending on what we want, this may actually be the intended behavior for try!(..) at least.
For consistency, it may also be what we want for async.

cc @scottmcm, @nikomatsakis, and @est31.

[Centril]

Also cc @rust-lang/lang.

[Mark-Simulacrum]

Per #52602 (comment) I've nominated this and marked as p-high to ensure we can get some eyes on this; I've also added T-compiler to hopefully assign someone who can do the legwork once lang arrives at a decision (I believe it's not quite clear what we want here).

[eddyb]

@Centril I disagree in the general case, because Leyword Expr is not banned in the grammar, and Expr can start with !, so this is a significant distinction between keywords and other identifiers.

IMO you should have to use r#async! to invoke that macro, if we even allow it at all.
cc @petrochenkov

[Centril]

@eddyb hmm; for async you have to write async { .. }; i.e, there is no async <expr> expression form so you can't write async ! ( foo() ) or something like that.

I think we should try to be consistent in what we do, so if we say ixnay on async!(..) then we should say ixnay on try!(..) and if we allow one we should allow both. As for what we should do, I don't have any strong feelings either way.

However, a point for consideration is that throw!(..) exists in the failure crate. If we hypothetically would like throw $expr as an expression construct and throw as a keyword in the future, then we should consider whether we would allow throw!(..), and what bearing this would have on try!(..) and async!(..).

[eddyb]

@Centril Won't try! work only in Rust2015 and require r#try! in Rust2018?
Anything else seems quite inconsistent and complicating the grammar further.

[Centril]

@eddyb I mean, that's what the choice before us is. We can make try!(..) work in Rust 2018 if we want technically, can't we?

• I agree that not allowing try!(..) would be consistent thing to do.
• On the other hand, we might want to reduce breakage.
• However, another point is that it might be beneficial to break try!(expr) as further encouragement in favor of expr? and rustfix people towards the latter.

There's arguments in favor of and against each choice here. 🤔