resolve: Collapse macro_rules scope chains on the fly

[petrochenkov]

Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports.
Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815

[rust-highfive]

Some changes occurred in intra-doc-links.

cc @jyn514

[rust-highfive]

r? @estebank

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

[petrochenkov]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 9221079 with merge 2f473715c794d9062bd0439b02d25f098de6acb5...

[bors]

☀️ Try build successful - checks-actions
Build commit: 2f473715c794d9062bd0439b02d25f098de6acb5 (2f473715c794d9062bd0439b02d25f098de6acb5)

[rust-timer]

Queued 2f473715c794d9062bd0439b02d25f098de6acb5 with parent a601302, future comparison URL.

[rust-timer]

Finished benchmarking try commit (2f473715c794d9062bd0439b02d25f098de6acb5): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-perf

[eddyb]

Looking over the implementation, I believe it is similar to the "path compression" optimization for union-find (collapsing redirects in a chain, i.e. replacing A -> B -> C -> D with A -> D where B and C are semantically noops, mere "aliases").

Here the chain is that of lexical (can only be seen "below" the definition, like let) macro_rules! names (as opposed to macro, which works like other Rust definitions), and the "noops" entries in the chain come from "there is a macro invocation which could expand to macro_rules! definitions" entries that got expanded (and don't themselves define macro_rules! macros).

Unlike union-find, however, this optimization is done eagerly (on every expansion), as opposed to lazily (when traversing these chains). I'm trusting @petrochenkov that this is more efficient, even though it might be clearer as an optimization to lazily cache-in-place during traversal, the way union-find "path compression" tends to work. Either way, I trust I can:

@bors r+

[bors]

📌 Commit 9221079 has been approved by eddyb

[petrochenkov]

@eddyb
I'll try using lazy compression in a follow up.
I'm not sure what would be more efficient, on one hand I suspect that all these scopes are going to be traversed in the end, on another hand the eager update like it's done now can result in multiple updates where lazy one could result in one.

[bors]

⌛ Testing commit 9221079 with merge 4cf4348857446540c82e56139dc70301730d7dae...

[bors]

💔 Test failed - checks-actions

[petrochenkov]

#78665 - spurious, but known to fail often.
Let's @bors retry anyway.

[jyn514]

Network error (rust-lang/cargo#8517).

@bors retry

[bors]

⌛ Testing commit 9221079 with merge 50589431d4b535b1edc7925f9d726652c213c3e5...

[bors]

💔 Test failed - checks-actions

[jyn514]

Same error :/ @ehuss mentioned in rust-lang/cargo#8517 (comment) that this happens more during GitHub outages and YouTube went down for a bit around an hour ago, so maybe that's the issue? Going to avoid retrying for now.

[ehuss]

It's not related to outages, it's just a case of bad luck. The pack files in the git repositories are in flux as they are constantly updated (each time a crate is published) and periodically recompressed. If it happens to recompress the pack file in such a way that it hits an edge condition, then it will fail. The only options are to run again and hope that the load balancer picks a different server that packed it differently, or to wait for the affected server to rebuild its pack files (which seems to happen every hour or two? I'm not sure) and hope it doesn't hit the edge case again.

[kennytm]

@bors retry

A PR has been successfully merged, assuming the error has been fixed.

[bors]

⌛ Testing commit 9221079 with merge 4eb07ca60aff0364d21f2be1d080dce86e3b2ec5...

[bors]

💔 Test failed - checks-actions

[petrochenkov]

warning: spurious network error (1 tries remaining): error inflating zlib stream; class=Zlib (5)

@bors retry

[bors]

⌛ Testing commit 9221079 with merge a38f8fb...

[bors]

☀️ Test successful - checks-actions
Approved by: eddyb
Pushing a38f8fb to master...