This makes the deny(warnings) in the testsuite conditional on a new
"deny-warnings" feature, that is then enabled in CI.
Ideally I could use the (reasonably well established) CI env var (like
we do for proptests), but I don't know how to get the attribute to be
defined in terms of an env var.
There's no need to build and test the exact same commit twice between
bors's auto branch and master. Hopefully this will help reduce the
bors timeouts due to waiting on appveyor.
As discussed at the recent work week this is probably a bit too zealous at this
time, so let's hold off on it until it's either more stable or we figure out a
better way to deal with changes in rustfmt.
For now though it'll hopefully be easy to continue running rustfmt every so
often!
This commit adds CI to run `cargo fmt` over Cargo itself as well as the internal
`crates-io` crate. This should switch Cargo to the "default style" (aka whatever
rustfmt spits out) and ensure that we keep it that way via CI. Hopefully this
won't be too much of a bother to keep up and running in CI as it should just be
a `cargo fmt` away!
We've received a lot of intermittent bug reports historically about corrupt git
repositories. These inevitably happens as Cargo is ctrl-c'd or for whatever
other reason, and to provide a better user experience Cargo strives to
automatically handle these situations by blowing away the old checkout for a new
update.
This commit adds a new test which attempts to pathologically corrupt a git
database and checkout in an attempt to expose bugs in Cargo. Sure enough there
were some more locations that we needed to handle gracefully for corrupt git
checkouts. Notable inclusions were:
* The `fetch` operation in libgit2 would fail due to corrupt references. This
starts by adding an explicit whitelist for classes of errors coming out of
`fetch` to auto-retry by blowing away the repository. We need to be super
careful here as network errors commonly come out of this function and we don't
want to too aggressively re-clone.
* After a `fetch` succeeded a repository could fail to actual resolve a
git reference to the actual revision we want. This indicated that we indeed
needed to blow everything away and re-clone entirely again.
* When creating a checkout from a database the `reset` operation might fail due
to a corrupt local database of the checkout itself. If this happens we needed
to just blow it away and try again.
There's likely more lurking situations where we need to re-clone but I figure we
can discover those over time.
This commit deletes the old documentation now that the "official source" is the
main book. The book is now lifted up directly into `src/doc` instead of
`src/doc/book`.
The CI no longer builds documentation and has been updated to just run mdbook to
make sure there's no errors. The documentation will actually get published in
the rust-lang/rust repo
This commit enables incremental compilation by default in Cargo for all
dev-related profiles (aka anything without `--release` or `bench`. A
number of new configuration options were also added to tweak how
incremental compilation is exposed and/or used:
* A `profile.dev.incremental` field is added to `Cargo.toml` to disable
it on a per-project basis (in case of bugs).
* A `build.incremental` field was added in `.cargo/config` to disable
globally (or enable if we flip this default back off).
Otherwise `CARGO_INCREMENTAL` can still be used to configure one
particular compilation. The global `build.incremental` configuration
cannot currently be used to enable it for the release profile.
Explain why caching is only done on $HOME/.cargo/bin/ in Travis
After having experimented with the Travis and AppVeyor caches, I concluded that they don't really help here: they're large and take a very long time to both download when the build starts and upload after it is finished.
Lots of data build stuff is still here from awhile ago when this repo was
producing Cargo binaries, but the rust-lang/rust repo is now responsible for all
these binaries and build configurations. We no longer need to produce artifacts
or have tons of cross-compiles as rust-lang/rust does all that work, instead
let's just test the likely-to-regress platforms and have rust-lang/rust take
care of the rest.
This commit:
* Deletes the old `configure` script and `Makefile`
* Rewrites `src/doc` management as a shell script
* Trims down Travis/AppVeyor configuration
These two tests actually shouldn't have ever passed, but nightly Rust is more
principled about "$OUT_DIR" and doesn't leak it where possible, so these two
tests were accidentally compiling due to leaking '$OUT_DIR' for Cargo itself.
* Pass `--quiet` to all tests to have some quieter output
* Skip builds on branches other than `auto-cargo` as it's already checked
* Check the right env var for repo branches on appveyor
* Only run a few builds on PRs
Follow the same strategy as the compiler for now in basically every respect:
* Add new `--release-channel` configure option, defaulting to `dev`
* Remove old `--enable-nightly`
* Add `--enable-build-openssl` as an orthogonal option
* Hook up Travis/AppVeyor to stable/beta/master branches to do the right
channel builds.
I'm seeing a bunch of weird illegal instructions on OSX nightlies for
Cargo. My guess is that they're all related to OpenSSL linking. Right
now we're linking from Homebrew but I have a sneaking suspicion that it
compiles with `-march=native` rather than what we'd like as a portable
binary. To work around this compile OpenSSL ourselves and link it that
way.
Note that I believe this won't bring in the certificate trust store of
OpenSSL on OSX (or at least not the right one from the keychain). We
shouldn't need that, however, as OpenSSL is just used as the
cryptographic primitives in libssh2 and Cargo itself. So in that sense
we shouldn't need it for actually SSL at all.
