Add a dead code elimination pass

[catamorphism]

Add a pass that warns about non-exported functions that are never called.

[catamorphism]

as per IRC conversation w/ nmatsakis: The only trick is that many functions are "accidentally" exported due to the "export all by default" rule. One solution is to warn anyway if a function in a module with no export decls is unused (within the crate). Adding explicit export decls suppresses the warning.

[brson]

See also #1702

[graydon]

We've discussed in the past inverting the "everything exported by default" rule at crate top-level. That is: only export explicit stuff for linking. The intra-crate is intended to make code less chatty and bureaucratic, but linking is often the appropriate time for bureaucracy.

Also note: if you have an explicit export list from a crate, you have a lot fewer roots to run your dead-code analysis from.

[metajack]

Somewhat related is #2953

[Aatch]

Visiting for triage. There have been lots of changes to privacy and similar, but I think this is still true.

[ktt3ja]

I'm thinking of working on this for a class project but I'm unfamiliar with the internal of rustc. tjc has told me to focus on adding warning for now, and then work on eliminating dead code if I still have time, so I have been looking inside librustc/middle to figure out what to do. Since this issue is about adding a new pass and (I presume) the logic is similar to the liveness analysis in librustc/middle/liveness.rs, does that mean I'm supposed to create a new file in librustc/middle/ (say foo.rs) with a top-facing pub fn check_crate that does something similar to liveness.rs, and then call middle::foo::check_crate inside librustc/driver/driver.rs? Also, is there difficulty in checking for unused non-exported functions inside the existing liveness.rs rather than doing a separate pass?

(sorry if the above are stupid questions)

[kud1ing]

Can be closed?

[alexcrichton]

It can indeed, thanks @ktt3ja!