cargo (publish) should complain about unused source files

[oli-obk]

Originally proposed in rust-lang/rust#28711, attempted as a clippy lint in https://github.com/Manishearth/rust-clippy/pull/544. The clippy lint is not really feasible, since it requires knowledge about all other files in the project (main.rs and lib.rs don't know about each other, since they are of different rustc invocations).

Cargo could invoke rustc with --emit dep-info and compile a list of all files mentioned in the resulting .d file. Then, once all required files are collected, it could check that list against the .rs files in the src (and test?) folders and notify the user of any extra files that aren't used in any compilation.

[alexcrichton]

Sounds reasonable to me!

[aturon]

@oli-obk Is this something you'd be interested in implementing, with some guidance from @alexcrichton?

[oli-obk]

Sure. I'll cook up a PR and see what issues arise

[oli-obk]

This was already implemented by @regexident in https://github.com/regexident/cargo-modules

cargo publish could call cargo modules --orphans and complain about leftover files.

[oli-obk]

Any opinions on including cargo modules in the default set of cargo subcommands?

[regexident]

cc @steveklabnik

[steveklabnik]

I am very pro cargo modules as a standard subcommand.

[alexcrichton]

I'm not personally a fan of stabilizing the current implementation which is to just use syntex_syntax to parse the crate. That's a pretty weighty dependency for Cargo to pull in and is not guaranteed to work with the version of Rust that Cargo is working with.

To stabilize this command in Cargo itself I think we'd need more support in the compiler to emit metadata information about the module structure for Cargo to read/understand rather than parsing the source code in Cargo.

[dwijnand]

In order to move this issue forward it would probably be useful to create an upstream issue in rustc detailing the required module structure metadata information emitting API.

[matklad]

@dwijnand to solve this specifically, and not the general cargo modules issue, I think the dep-info should be enough. We already handle it in Cargo.

However, I am not sure how this should work in general... If you have cfg(unix) / cfg(windows) split, for example, some of files would be genuinely unused.