syntax: move ast_map to librustc.

[eddyb]

Gets libsyntax one step closer to running on stable (see #24518).
Closes#24757, erickt's previous attempt at this.

[rust-highfive]

r? @nikomatsakis

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

[nikomatsakis]

@bors r+

[bors]

📌 Commit cdc182a has been approved by nikomatsakis

[eddyb]

@bors r=nikomatsakis

[bors]

📌 Commit 76eaed4 has been approved by nikomatsakis

[bors]

⌛ Testing commit 76eaed4 with merge a10aec6...

[bors]

💔 Test failed - auto-linux-32-opt

[eddyb]

@bors retry

[bors]

⌛ Testing commit 76eaed4 with merge d8a9570...

[bors]

💔 Test failed - auto-mac-32-opt

[eddyb]

@bors retry

[bors]

⚡ Previous build results for auto-linux-32-nopt-t, auto-linux-64-nopt-t, auto-linux-64-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt are reusable. Rebuilding only auto-linux-32-opt, auto-linux-64-x-android-t, auto-mac-32-opt...

[Manishearth]

Would it be worth/possible moving this to librustc_ast_map? Every bit helps :)

[eddyb]

@Manishearth it wouldn't help much because librustc depends on it. Most of the parallelism in building rustc starts after librustc.

[Manishearth]

Ah. Might it be reasonable to have some parallel crates in between syntax and rustc?

The way I see it, we can fan out after syntax, converge on rustc, and then fan out into the rustc_*s. Not a big win, but still could be a win.

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

[erickt]

thanks @eddyb! I'm still catching up from my vacation, and haven't gotten around to fixing my PRs yet :)