Show library version in documentation generated by rustdoc

[gsingh93]

I recently was using a library whose online documentation was out of date. One of the method signatures had changed and that wasn't reflected in the documentation. I checked the source code of the project to confirm that the signature had changed, but it also would have been nice to see on the documentation page that the version I was using didn't match up to the documentation version.

[tomjakubowski]

There will need to be some coordination with cargo because "crate versions" are not something even rustc knows about.

[tomjakubowski]

The --html-after-content argument might be useful.

[bluss]

cargo issue: rust-lang/cargo/issues/1681

[steveklabnik]

Triage: no change.

docs.rs kinda does this.

[QuietMisdreavus]

From the info in rust-lang/cargo#1681 (comment), a "quick" patch for this would involve checking env::var("CARGO_PKG_VERSION"), and if it's Ok, finding a good place in the page template to put it. For bonus points, you could also check env::var("CARGO_PKG_NAME") to put both the crate name and version all over the place.

The major drawback to this would be that it codifies it around Cargo, rather than making it some kind of neutral setup that could easily be pulled out into other build systems. It's still just a couple environment variables, but they also have "Cargo" in the name. >_> A "proper" solution likely involves adding new command-line options and making Cargo use them, and this is possibly RFC territory? cc @rust-lang/dev-tools, i want to double-check my reasoning.

[GuillaumeGomez]

@QuietMisdreavus: Your logic seems ok. I just don't find this very useful but why not...

[QuietMisdreavus]

We talked about this in today's dev-tools meeting, and we figured that adding new command-line flags for this won't require an RFC. I'd like to make a first-pass PR that adds them as unstable flags so we can hash out the particulars within that thread.

[QuietMisdreavus]

That PR is live at #44989.