Auto merge of #7131 - ehuss:remove-unused-opt-feature, r=alexcrichton
Remove unused feature filter.
NOTE: Do not merge this lightly. This upended my understanding of how the resolver handles features, and I'm still not sure about it.
Remove an unused check that an optional dependency is activated.
This was originally added 4 years ago in #1812, during a time when this code iterated over the actual dependencies from `Package.dependencies()`. In #5415 this was refactored so that it gets the `deps` list directly from the Resolver, which AFAIK has already filtered out the features. IIUC, this filtering is done [here](https://github.com/rust-lang/cargo/blame/705009eb3828123cc9dbcf5b28988cc63f60b03b/src/cargo/core/resolver/dep_cache.rs#L270-L272).
Auto merge of #7118 - alexcrichton:patch-bug, r=Eh2406
Handle activation conflicts for `[patch]` sources
This commit updates the resolver to ensure that it recognizes conflicts
when `[patch]` is used to augment an older version of what's already in
a source, for example. Previously the deduplication based on
semver-compatible versions didn't actually work when `[patch]` was used.
This meant that when you used `[patch]` it might not transitively affect
the entire crate graph, instead just giving you a version of a
dependency and everyone else. This violates the intention of `[patch]`!
The fix here is to catch this use case happening, when a `Dependency`
source specification mismatches an activated package we need to list a
second activation in the resolver to prevent major versions from being
selected from both the original source as well as the source of the id.
Alex Crichton [Wed, 10 Jul 2019 18:18:10 +0000 (11:18 -0700)]
Handle activation conflicts for `[patch]` sources
This commit updates the resolver to ensure that it recognizes conflicts
when `[patch]` is used to augment an older version of what's already in
a source, for example. Previously the deduplication based on
semver-compatible versions didn't actually work when `[patch]` was used.
This meant that when you used `[patch]` it might not transitively affect
the entire crate graph, instead just giving you a version of a
dependency and everyone else. This violates the intention of `[patch]`!
The fix here is to catch this use case happening, when a `Dependency`
source specification mismatches an activated package we need to list a
second activation in the resolver to prevent major versions from being
selected from both the original source as well as the source of the id.
This removes the `byteorder`-dependency, which was used in a few tests only anyway and is not needed since 1.32; also removes the `derive`-feature from the `failure`-crate, which is not needed also.
Auto merge of #7057 - hugwijst:apple-depinfo, r=ehuss
Fix overwriting .d file for binary with dSYM on apple targets.
When building a binary on targets containing `-apple-`, the resulting `.d` file gets overwritten with the dependencies of the `.dSYM` file. Eg. in the changed unit test, `foo.d` would start with `p.bin(foo).with_extension("dSYM")` instead of `p.bin(foo)`.
This PR fixes that problem by not generating `.d` dependency information files for outputs of the `DebugInfo` flavor.
Auto merge of #7083 - sekhat:issue/7003-allow-dirty, r=alexcrichton
improve uncommitted changes cargo-package message
fixes #7003
Explicitly state what the suggested flag `--allow-dirty`
actually does when packaging/publishing the crate. Primarily,
that the uncommitted changes are included within the resulting
package.
Explicitly state what the suggested flag `--allow-dirty`
actually does when packaging/publishing the crate. Primarily,
that the uncommited changes are included within the resulting
package.
bors [Sat, 29 Jun 2019 23:09:15 +0000 (23:09 +0000)]
Auto merge of #7082 - ehuss:git-fetch-with-cli-env-clean, r=Eh2406
Clean environment when git-fetch-with-cli is used.
When the GIT_DIR environment variable is set, git-the-cli will use that instead of looking at cwd. This can happen, for example, when using the `exec` command in `git rebase` to call cargo. This causes cargo to fetch into the wrong directory.
bors [Tue, 25 Jun 2019 06:28:12 +0000 (06:28 +0000)]
Auto merge of #7062 - goffrie:master, r=alexcrichton
Fix exponentiality in depend_on_deps_of_deps.
With `CARGO_BUILD_PIPELINING=true`, cargo was spending a long time (15 seconds) before starting any compilation. That is caused by a naive graph traversal in `depend_on_deps_of_deps`. Instead, let's make sure not to keep traversing the same deps. With this patch, things are fast again.
bors [Sat, 22 Jun 2019 18:12:51 +0000 (18:12 +0000)]
Auto merge of #7060 - lzutao:zsh-complete-package, r=ehuss
_cargo: Make function style consistent
They are just white-space changes. I'm planning to bring back Zsh completion
for `-p` (package) option, which was disabled in #1713. This PR is the first
stepping stone towards that goal.
A disadvantageous is that I am just starting to learn Zsh completion system.
Guess how far can I go?
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.
projects / cargo.git / log