Remove unused rules from extension_trait macro

[lqd]

Hi,

as part of the initiative to improve compile times we've been looking at rustc benchmarks over a number of crates in the ecosystem.

We've noticed async-std was exercising rustc's macro expansion in surprising ways, and we're currently working on improving this part of the compiler. In the meantime, we thought we'd try to help by (hopefully) improving the extension_trait macro:

• some rules are unused: a single rule currently parses extension methods with and without lifetimes, in both the @doc and @ext contexts. However, a redundant rule handling a single lifetime remains, adding overhead to macro expansion: the one in the @ext context costs around 20% of the check time.
• I didn't do this in this PR but we've also discussed structuring the macro differently: adopting the push-down accumulation pattern should also improve things a bit (maybe in the order of an additional 10%).

By removing the unused rules, the compile time gains in builds of async-std itself (i.e. in regular day-to-day development, when dependencies are already built) are around 19-20% for a check build, 16% in debug builds, and 6-7% in release builds; it's expected that downstream crates could also see some improvements to compile times (but async-std is not that heavy to build in the first place) when they build their own dependencies: fresh checkouts or after a cargo clean, after a rustc update, after changing RUSTFLAGS, etc.

I'm opening this as a draft PR because I'm not sure this a correct fix. The original macro was fixed a couple years ago in #405, and these two rules remained: it's not clear to me in which cases the fake impl Future can or cannot borrow from its environment, making the inner mod borrowed and mod owned differentiation unused, and therefore making we wonder whether they can actually be removed wholesale or if the old fix was somehow incomplete ?

That being said, this PR seems to be indeed doing the same things as before, both for compilation and documentation, which is reassuring.

[fbstj]

am I right in thinking this was included in #1005 ?

[lqd]

You are indeed right, we opened them around the same time :)