Pull rustdoc_ng into mainline.

[emberian]

This doesn't enable it by default yet, or include the frontend. But the tool
is pretty much done, and it'd be nice to stave off bitrot.

I couldn't get it to actually build with the Makefile though. I don't really
understand what is going on in that makefile at all. Could @graydon or
@pnkfelix lend a hand?

[emberian]

Also, it'd be cool to build it with rustpkg (because it can be), but I don't know how that would work with staging or anything else.

[graydon]

Try to grab me during the week, I'll see what I can do.

[pnkfelix]

(My usual first piece of advice applies here: Install GNU remake and use its --trace option to get better feedback about what make is doing when it processes a clever makefile like this.)

[pnkfelix]

@cmr I'm guessing you probably made your changes to mk/tools.mk based on duplicating what you saw already in place for the old rustdoc. In addition to grepping through mk/*.mk, you also need to look at Makefile.in, which is what configure uses as a template from which to generate the Makefile it puts into the object-file build tree.

[pnkfelix]

@cmr Ah, looking at the situation more carefully now, I realized that your outermost structure for rustdoc_ng does not match what the other rust tools are doing; in particular, most (every?) other tool builds a library as its primary crate type, and those all link into the main rust driver library. Your rustdoc_ng's main.rs has no library target; it is going straight to a binary.

We can probably integrate what you have as it stands, but I'm not sure if that's a great idea; there's value in the existing pattern, and it might behoove you to switch to it.

[emberian]

@pnkfelix does that look better?

[pnkfelix]

@cmr yes I think so. I'll see if I can finish incorporating it into the makefile infrastructure, so that we at least test that it builds.

[pnkfelix]

@cmr this commit will finish the job: pnkfelix/rust@7a6a912

(At least an invocation of make seems to do a full build that includes librustdoc_ng library, but not the rustdoc_ng binary.)

I tried to open a Pull Request directly over to your own repo, but cmr/rust did not appear in the github interface for the base fork. But you should be able to pull the commit over yourself and add it to this pull request. (Though you probably should rebase it first, since I am pretty sure I've made some changes to the Makefiles that you'll want to merge in.)

[emberian]

@pcwalton each_path was removed; I use/used it with https://github.com/cmr/rust/blob/27de8b5467a6f2a10294737cb15e2d233c6aa305/src/rustdoc_ng/clean.rs#L993, what should that be updated to use?

[pnkfelix]

@cmr I infer from SHA: 1bbb1e0 (where each_path was actually removed) that you should replace uses of each_path with some combination of each_top_level_item_of_crate and/or each_child_of_item, no?

[catamorphism]

@cmrmake tidy please :-)

[klutzy]

See #9055 for the win32 failure