Syntactically permit postfix macros to reject them later

[est31]

Change the parser to syntactically permit postfix bang macros (foo.bar!()) to be parsed by rustc, but still reject them later on before they would be expanded or even resolved.

Similar prior work: #75857 and #66183.

The intention of this PR is to allow attribute macros to lower the postfix macro syntax to something of their choosing.

For everyone else, it improves error messages.

error: expected one of `(`, `.`, `::`, `;`, `?`, `}`, or an operator, found `!`
  --> $DIR/postfix-macros.rs:2:5
   |
LL |     "Hello, world!".to_string().println!();
   |                                        ^ expected one of 7 possible tokens

becomes

error: forbidden postfix macro call `println`
  --> $DIR/postfix-macros.rs:2:5
   |
LL |     "Hello, world!".to_string().println!();
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^--------^^
   |                                 |
   |                                 macros can't be called postfix position

[rust-highfive]

r? @lcnr

(rust_highfive has picked a reviewer for you, use r? to override)

[jyn514]

See https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/documenting.20Rust.20syntax - has this been run by lang team?

[est31]

@jyn514 I can't find an FCP for #75857 but #66183 had an FCP, so I guess one is needed. cc @joshtriplett who has authored an RFC about postfix macros.

[jyn514]

cc @ehuss too

[lcnr]

r? @petrochenkov

[petrochenkov]

I'll reroute this to the lang team immediately.
This is a much larger change from the category "accepted syntactically, but always rejected semantically" than the previous precedents.
I think merging an RFC like rust-lang/rfcs#2442 and stating that "yes, we will accept postfix macros semantically sooner or later" is a pre-requisite for landing something like this.

[est31]

@petrochenkov that RFC won't get merged any time soon, but not because of disagreements on the syntax, but because of disagreement on the semantics. I haven't read a single comment in that thread which disagreed about the proposed invocation syntax. It's basically obvious how it should be.

As to the size of the change, the current diff is smaller by one line than #75857. So I wouldn't really say it's bigger :). Edit: I guess you meant semantic size, which is indeed larger for this change.

[lcnr]

I feel that unlike #75857 this is at least partially an expression of intent, so I do believe it requires at least an FCP

[joshtriplett]

While I would love to have postfix macros (I proposed RFC 2442 in the first place), I don't think we should parse them if we're not going to accept them.

I would love to see RFC 2442 revived. I've just rewritten that RFC to bring it up to date with current Rust.

Thank you for working on this, @est31!

[est31]

@joshtriplett thanks for the kind words and thanks for reviving the RFC. I hope that this time it gets through, but I'm doubtful, given the contents of the thread. Parsing postfix macros would allow experimentation with attribute macros outside of the main language.

[petrochenkov]

The intention of this PR is to allow attribute macros to lower the postfix macro syntax to something of their choosing.

One more general solution to this problem is to delay parsing of anything inside delimited groups ((), [], {}) until expansion (#75820 (comment), #65860).

This way people will be able to use pretty much any arbitrary syntax (modulo the the requirement on balanced delimiters) under #[cfg(FALSE)] or in proc macro input.

[est31]

@petrochenkov that'd be a great idea IMO. The main reason these syntax extensions are proposed are attribute macros. Most use cases would benefit tremendously from being able to do a lot of things inside delimitered groups. Would help my proposal and also would have helped #66183, but not #75857 as the attr is directly on the module. I'm not sure about formatters, but imo it should be easy for formatters to speculatively treat something as Rust and if it isn't then just bail out somehow.

[joshtriplett]

@petrochenkov That seems like a great idea for many reasons, not least of which improving handling of conditional compilation so that it works to hide new features from old compilers.

[est31]

Closing in favour of a more general approach: #78849 (comment)