cargo update, pin "cargo" to 6a8eb71f6

[alexheretic]

Lots of our dependencies are somewhat behind on patch versions. Some of these do affect us, like having env_logger 0.5.3. I would have thought the lock file was for ensuring one developers experience is the same as anothers & as the release - rather than longer term freezing of dependencies.

If the reason for the lack of wholesale semver-compatible updates is some specific ones we want to carefully control, would it be better to declaratively control these in the Cargo.toml file?

For this pr I've assumed cargo is the only such crate & have put a reference to the commit hash we're locked to & updated the rest.

[dependencies]
cargo = { git = "https://github.com/rust-lang/cargo", rev = "848eb156" }
# ...

Are they're others we want to control? Or perhaps I am missing a good reason to rarely update in this way?

[alexheretic]

On the point of cargo maybe we should consider generally using the commit hash that matches the current nightly. After all this hash will actually be sure to compile with the toolchain it was delivered with.

# cargo +nightly -vV
cargo 0.26.0-nightly (6a8eb71f6 2018-01-13)
release: 0.26.0
commit-hash: 6a8eb71f6d226f9ac869dbacd5ff6aa76deef1c4
commit-date: 2018-01-13

As such I'll update the cargo hash to this one. We could even test / warn that the cargo version is outdated to help us keep track of it.

[nrc]

The point of the committed lock file is to have predictable breakage. I don't think we should put off doing updates, ideally we would do them frequently. Cargo in particular can cause problems when we update because of breaking changes in its API.

[nrc]

Thanks for the PR!

[alexheretic]

Ok thanks! The explicit rev = HASH for cargo should allow cargo update to be less of an issue then.

What do you think of trying to keep the cargo version in line with cargo +nightly version, perhaps we could warn on build if the build cargo version is newer than the rls/Cargo.toml one?

[nrc]

Given that this has not been too much of a problem in practice, and when it has it has required a non-trivial amount of effort to fix, I don't think it is worth expending too much effort on this kind of solution.