bors [Fri, 21 Jun 2019 20:53:30 +0000 (20:53 +0000)]
Auto merge of #7056 - ehuss:default-run-stabilize, r=alexcrichton
Stabilize default-run
This stabilizes the default-run feature.
I've included some error message changes. If `default-run` specifies an unknown binary, it now tells you that the `default-run` field is incorrect and which manifest it is located in, instead of just saying "could not determine which binary to run".
I also consolidated some of the suggestion code so it is not repeated all over.
The newly introduced [test](https://github.com/rust-lang/cargo/pull/7050/commits/9aa7a4dce5f47e49c4100ff18a9dc0dc5a47efc4) is [failing](https://travis-ci.com/rust-lang/cargo/jobs/209849725#L2569-L2580) as discussed in https://github.com/rust-lang/cargo/issues/6972#issuecomment-502241124 (replicating the issue). Removing the `touching of intermediate artifacts` as suggested fixes the issue, but makes the old test `simple_deps_cleaner_does_not_rebuild` fail. The `simple_deps_cleaner_does_not_rebuild` test is not needed anymore so it's removed.
Now that the `mtime` of intermediate artifacts is not updated there's no need
for this test anymore (it now fails because without the `mtime`s it cannot
perform the intended GC operation).
bors [Fri, 21 Jun 2019 01:30:05 +0000 (01:30 +0000)]
Auto merge of #7045 - Eh2406:resolver-test/debug-cleanup, r=alexcrichton
Resolver test/debug cleanup
This is several small things salvaged from abandoned PRs and implemented on top of #7011
In working on this I noted that the prop tests are very sensitive to whether backtrace are turned on. Maybe we should set that env to 0 for that builder?
bors [Wed, 19 Jun 2019 16:22:59 +0000 (16:22 +0000)]
Auto merge of #7042 - ehuss:no-global-rm-rf, r=alexcrichton
Revert test directory cleaning change.
#6900 changed it so that the entire `cit` directory was cleaned once when tests started. Previously, each `t#` directory was deleted just before each test ran. This restores the old behavior due to problems on Windows.
The problem is that the call to `rm_rf` would fail with various errors ("Not found", "directory not empty", etc.) if you run `cargo test` twice. The first panic would poison the lazy static initializer, causing all subsequent tests to fail.
There are a variety of reasons deleting a file on Windows is difficult. My hypothesis in this case is that services like the indexing service and Defender swoop in and temporarily hold handles to files. This seems to be worse on slower systems, where presumably these services take longer to process all the files created by the test suite. It may also be related to how files are "marked for deletion" but are not immediately deleted.
The solution here is to spread out the deletion over time, giving Windows more of an opportunity to release its handles. This is a poor solution, and should only help reduce the frequency, but not entirely fix it.
I believe that this cannot be solved using `DeleteFileW`. There are more details at https://github.com/rust-lang/rust/issues/29497, which is a long-standing problem that there are no good Rust implementations for recursively deleting a directory.
An example of something that implements a "safe" delete is [Cygwin's unlink implementation](https://github.com/cygwin/cygwin/blob/ad101bcb0f55f0eb1a9f60187f949c3decd855e4/winsup/cygwin/syscalls.cc#L675-L1064). As you can see, it is quite complex. Of course our use case does not need to handle quite as many edge cases, but I think any implementation is going to be nontrivial, and require Windows-specific APIs not available in std.
Note: Even before #6900 I still get a lot of errors on a slow VM (particularly "directory not empty"), with Defender and Indexing off. I'm not sure why. This PR should make it more bearable, though.
bors [Tue, 18 Jun 2019 17:51:36 +0000 (17:51 +0000)]
Auto merge of #7011 - alexcrichton:resolver-extract, r=Eh2406
Extract resolver tests to their own crate
These tests take a good amount of time to run locally and they're also
causing a lot of dependencies to get pulled into rust-lang/rust, so
let's have a separate crate that we just test on our own CI
Alex Crichton [Wed, 5 Jun 2019 19:54:56 +0000 (12:54 -0700)]
Extract resolver tests to their own crate
These tests take a good amount of time to run locally and they're also
causing a lot of dependencies to get pulled into rust-lang/rust, so
let's have a separate crate that we just test on our own CI
bors [Fri, 14 Jun 2019 23:36:31 +0000 (23:36 +0000)]
Auto merge of #7030 - Mark-Simulacrum:support-new-dep-info, r=alexcrichton
Support absolute paths in dep-info files
These changes are a little more invasive then I would've liked, but I couldn't come up with a significantly better way to structure this. Comments (or backwards-compat) concerns are appreciated, of course!
Mark Rousskov [Wed, 12 Jun 2019 19:14:54 +0000 (13:14 -0600)]
Support rustc emitting dep-info for binary dependencies
rustc wants to provide sysroot dependencies and perhaps eventually
statically/dynamically linked C libraries discovered in library serach
paths to Cargo. Mostly this is only useful today for rustbuild as
otherwise Cargo's assumption that the sysroot is only changed if `rustc`
itself changes is pretty much always correct.
bors [Tue, 11 Jun 2019 14:06:10 +0000 (14:06 +0000)]
Auto merge of #7026 - ehuss:publish-lockfile-stabilize, r=alexcrichton
Stabilize publish-lockfile.
This stabilizes the publish-lockfile feature. Specifically:
- Makes `Cargo.lock` included by default for packages with executables.
- Deprecates the `publish-lockfile` manifest key. It is no longer used.
Additional notes:
- Fixed issue where if a `Cargo.lock` file didn't exist, `cargo package` would fail the
VCS dirty check.
- Changed it so that `cargo publish` or `cargo package` will now show manifest
warnings. I believe this was an oversight.
bors [Fri, 7 Jun 2019 20:31:55 +0000 (20:31 +0000)]
Auto merge of #6900 - jethrogb:nonconcurrent-tests, r=ehuss
Fix nonconcurrent tests
The cargo testsuite relies on a clean test “root” for every test (i.e. `#[test]`-annotated function). It relied on the `test` crate's behavior to spawn a new thread for each test, which isn't done when tests aren't run concurrently, breaking the test suite. In this PR, I'm using backtraces to figure out which test is being run, which is much more robust. I also cleaned up the root initialization logic so that it no longer recursive calls the `init` function.
bors [Thu, 6 Jun 2019 21:17:48 +0000 (21:17 +0000)]
Auto merge of #6966 - ehuss:reamp-path-prefix-hash, r=@alexcrichton
Ignore remap-path-prefix in metadata hash.
Including this flag in the metadata hash causes problems with reproducible builds.
I spent some time considering the different alternatives (such as providing a config option, or an unhashed RUSTFLAGS alternative), and decided this might be the best option.
- It is a very simple, small change.
- It should be safe.
- It is transparent to the user, they don't need to do anything special.
- It doesn't expand Cargo's interface.
bors [Wed, 5 Jun 2019 17:34:40 +0000 (17:34 +0000)]
Auto merge of #7010 - alexcrichton:less-features, r=ehuss
Don't synthesize feature diretives for non-optional deps
Currently when Cargo is invoked on the command like `cargo build
--features foo/bar` then it will actually always compile the current
crate with `feature = "foo"` even if `foo` is a non-optional dependency.
This isn't intended because the crate doesn't actually have a `foo`
feature as so no directive should be emitted or passed to the compiler.
This was discovered in rust-lang/rust where Cargo is being built with
the `rustc-workspace-hack` feature but when the RLS depends on Cargo it
doesn't enable the same feature. This feature, however, doesn't actually
exist for Cargo!
bors [Wed, 5 Jun 2019 17:05:58 +0000 (17:05 +0000)]
Auto merge of #7008 - alexcrichton:less-pipelining, r=ehuss
Handle pipelined tests of libraries
The previous implementation of pipelining accidentally forgot to account
for rlibs being compiled in `--test` mode. The compilations would be
pipelined to where all the dependencies of an rlib might not be
available yet, but `--test` actually performs linking in rustc!
This commit fixes the issue by refactoring slightly and removing
`Target::requires_upstream_objects` (moving it to `TargetKind`) and then
making the source of truth a `Unit::requires_upstream_objects` method
which takes into account the value from `TargetKind` as well as the
`CompileMode`.
Alex Crichton [Wed, 5 Jun 2019 16:10:10 +0000 (09:10 -0700)]
Don't synthesize feature diretives for non-optional deps
Currently when Cargo is invoked on the command like `cargo build
--features foo/bar` then it will actually always compile the current
crate with `feature = "foo"` even if `foo` is a non-optional dependency.
This isn't intended because the crate doesn't actually have a `foo`
feature as so no directive should be emitted or passed to the compiler.
This was discovered in rust-lang/rust where Cargo is being built with
the `rustc-workspace-hack` feature but when the RLS depends on Cargo it
doesn't enable the same feature. This feature, however, doesn't actually
exist for Cargo!
Alex Crichton [Tue, 4 Jun 2019 15:40:24 +0000 (08:40 -0700)]
Handle pipelined tests of libraries
The previous implementation of pipelining accidentally forgot to account
for rlibs being compiled in `--test` mode. The compilations would be
pipelined to where all the dependencies of an rlib might not be
available yet, but `--test` actually performs linking in rustc!
This commit fixes the issue by refactoring slightly and removing
`Target::requires_upstream_objects` (moving it to `TargetKind`) and then
making the source of truth a `Unit::requires_upstream_objects` method
which takes into account the value from `TargetKind` as well as the
`CompileMode`.
bors [Mon, 3 Jun 2019 17:03:44 +0000 (17:03 +0000)]
Auto merge of #6869 - alexcrichton:vendor, r=ehuss
Import the cargo-vendor subcommand into Cargo
This commit imports the external [alexcrichton/cargo-vendor
repository][repo] into Cargo itself. This means it will no longer be
necessary to install the `cargo-vendor` subcommand in order to vendor
dependencies. Additionally it'll always support the latest feature set
of Cargo as it'll be built into Cargo!
All tests were imported as part of this commit, but not all features
were imported. Some flags have been left out that were added later in
the lifetime of `cargo vendor` which seem like they're more questionable
to stabilize. I'm hoping that they can have separate PRs adding their
implementation here, and we can make a decision of their stabilization
at a later date.
The current man page for `cargo vendor -h` will look like:
cargo-vendor
Vendor all dependencies for a project locally
USAGE:
cargo vendor [OPTIONS] [--] [path]
OPTIONS:
-q, --quiet No output printed to stdout
--manifest-path <PATH> Path to Cargo.toml
--no-delete Don't delete older crates in the vendor directory
-s, --sync <TOML>... Additional `Cargo.toml` to sync and vendor
--respect-source-config Respect `[source]` config in `.cargo/config`
-v, --verbose Use verbose output (-vv very verbose/build.rs output)
--color <WHEN> Coloring: auto, always, never
--frozen Require Cargo.lock and cache are up to date
--locked Require Cargo.lock is up to date
-Z <FLAG>... Unstable (nightly-only) flags to Cargo, see 'cargo -Z help' for details
-h, --help Prints help information
ARGS:
<path> Where to vendor crates (`vendor` by default)
This cargo subcommand will vendor all crates.io and git dependencies for a
project into the specified directory at `<path>`. After this command completes
the vendor directory specified by `<path>` will contain all remote sources from
dependencies specified. Additionally manifest beyond the default one can be
specified with the `-s` option.
The `cargo vendor` command will also print out the configuration necessary
to use the vendored sources, which when needed is then encoded into
`.cargo/config`.
Since this change is not importing 100% of the functionality of the
existing `cargo vendor` this change does run a risk of being a breaking
change for any folks using such functionality. Executing `cargo vendor`
will favor the built-in command rather than an external subcommand,
causing unimplemented features to become errors about flag usage.
bors [Mon, 3 Jun 2019 14:24:35 +0000 (14:24 +0000)]
Auto merge of #6998 - ehuss:doc-duplicate-tracking, r=alexcrichton
Catch filename output collisions in rustdoc.
This does some general cleanup so that rustdoc output is computed correctly. This allows the collision detection code to work. There are some known issues with rustdoc creating collisions (rust-lang/rust#61378, rust-lang/rust#56169). This is related to issue #6313.
This includes a change that `CompileMode::is_doc` no longer returns `true` for doc tests. This has bothered me for a while, as various points in the code was not handling it correctly. Separating it into `is_doc` and `is_doc_test` I think is better and more explicit.
Note for reviewing: There is a big diff in `calc_outputs`, but this is just rearranging code. Everything in `calc_outputs_rustc` is unchanged from the original.
The only functional changes should be:
- A warning is emitted for colliding rustdoc output.
- Don't create an empty fingerprint directory for doc tests.
bors [Thu, 30 May 2019 14:45:51 +0000 (14:45 +0000)]
Auto merge of #6995 - Eh2406:new-test-is-worng, r=@alexcrichton
the testing SAT solver was messed up by a refactor
This fixes a mistake in #6980 introduced in [this commit](https://github.com/rust-lang/cargo/pull/6980/commits/c68334ff4a78382feb8b07730b46f75e0866e41a#diff-4317936c037e49f70800a86656c67569L308).
This also reverts [84586611](https://github.com/rust-lang/cargo/pull/6980/commits/84586611af27515f5f10692f52f0cc8eeb480692) with some test cases to show that it was wrong.
This only causes problems when proptest is set to make public dependencies (witch is not true on master) and it gens a `reverse_alphabetical` example. Despite the low impact of these bugs, I would like it to be left incorrect as short as possible.
bors [Tue, 28 May 2019 15:13:28 +0000 (15:13 +0000)]
Auto merge of #6980 - Eh2406:varisat, r=alexcrichton
Test the Resolver against the varisat Library
Resolution can be reduced to the SAT problem. So this is an alternative implementation of the resolver that uses a SAT library for the hard work. This is intended to be easy to read, as compared to the real resolver, and run as part of the test sweet to make sure the real resolver works as expected. Part of #6120.
Some notes on performance:
The initial version did not support public & private deps:
~64 loc, `O(nln(n))` vars, `O(nln(n) + n*d)` clauses, 0.5x slower on `prop_passes_validation`
The final version:
~163 loc, `O(dn^2`) vars, `O(dn^3)` clauses, 1.5x slower on `prop_passes_validation`
That comparison makes me feel better about spending months trying to get public & private deps to be fast enough for stabilization.
bors [Thu, 23 May 2019 17:08:40 +0000 (17:08 +0000)]
Auto merge of #6973 - exphp-forks:check-directory, r=ehuss
cargo package: detect new empty directories
Detect the creation of directories in a build script, which is currently a very tempting workaround for the fact that a crate built from a package will be missing any empty directories.
Maybe it would be better to only include directories in the map of hashes if they are completely empty.
The removal of a directory that is initially empty cannot be tested because, as stated above, a crate built from a package will not *have* any empty directories.