Permit . after macro invocations at the starts of statements

[ftxqxd]

This fixes the most commonly-encountered case of #5941.

[blaenk]

As an example of something that this would improve the ergonomics of, consider @reem's rust-enforce library.

Excerpt:

describe! vec {
    describe! push {
        before_each {
            let mut v = vec![1u, 2, 3];
        }

        it "should increase the length by 1" {
            let old = v.len();
            v.push(4u);
            // Fluid chain with informative error messages.
            (enforce!(old + 1)).is().equal(v.len());
        }

Would be this instead:

enforce!(old + 1).is().equal(v.len());

[alexcrichton]

Thanks for the PR @P1start! We currently, however, require an RFC to modify the macro system (small though this may be). The story around macros ever-developing, and at this time we would like to put more time and discussion into modifications than just a PR to the rust repository itself.

We're also quite hesitant to extend the macro system much farther without having a clear design going forward, as opposed to patching it up here and there as we go along.

In light of this, I'm going to close this PR, but you may of course feel free to open an RFC.

[ftxqxd]

Since this change would require an RFC, should #5941 be moved to an issue in the RFCs repo? I don’t think it’s possible to solve that issue without an RFC, so it seems strange (and possibly misleading) to leave it as an issue in the Rust repository if it actually requires an RFC to be fixed.

[alexcrichton]

Good idea!