Crater should read the same metadata as docs.rs for doc runs

[jyn514]

There was a regression in rust-lang/rust#73566 not caught because crater didn't pass the same --feature docs as docs.rs. It would be great if crater added those features so we could catch regressions early instead of after they land.

rust-lang/rust#73566 (comment)

[jyn514]

To be clear - the feature request is to read [package.metadata.docs.rs], not to pass --feature docs for every crate.

[jyn514]

It wouldn't be too hard to separate this out of https://github.com/rust-lang/docs.rs/blob/master/src/docbuilder/metadata.rs as a library. Not sure where it should live though - maybe under rust-lang/crates-build-metadata to match https://github.com/rust-lang/crates-build-env?

[pietroalbini]

I'd simply create a docsrs-metadata crate inside the https://github.com/rust-lang/docs.rs repository and publish it on crates.io. A minimal API for that crate could be:

pub struct Metadata {
    // Private fields
}

impl Metadata {
    pub fn discover_from_crate_root(root: &Path) -> Result<Self, Error> {}
   	pub fn parse(manifest: &str) -> Result<Self, Error> {}
    pub fn cargo_args(&self) -> Vec<String> {
        // --features, --no-default-features, --all-features
        // *NOT* --target
    }
    pub fn environment_variables(&self) -> Vec<(String, String)> {
        // RUSTFLAGS, RUSTDOCFLAGS, DOCS_RS=1
    }
    pub fn default_target(&self) -> &str {}
    pub fn additional_targets(&self) -> Vec<&str> {}
}

Crater would then depend on the crate, and take into account everything but the targets.

[jyn514]

Looks great! I think additional_targets should return HashSet and environment_variables should return Vec<(String, String)> so you can use set_env or something like that.

[jyn514]

Why wouldn't crater read the default target? e.g. winapi is an empty crate when compiled for Linux.

[pietroalbini]

Because try builds don't have additional targets unless you mess with the CI config.

[jyn514]

Docs.rs needs to have owned strings for cargo_args() because it concatenates the features together. But then it can't return Vec<&str>. It can either return Vec<String> or Vec<Cow<str>>. The first copies, the second is annoying to work with. Which would you prefer?

[jyn514]

environment_variables is also painful to work with because you have to look for RUSTDOCFLAGS yourself if you want to modify it. I think I'll change it to return a struct instead.

[jyn514]

Oh hold on, I can just make the rustdocflags and rustflags arguments public instead. I like that better. No, that forces you to clone the metadata to add arguments.