bors [Tue, 18 May 2021 20:47:05 +0000 (20:47 +0000)]
Auto merge of #9498 - ehuss:rustup-windows-workaround, r=alexcrichton
Add temporary fix for rustup on windows in CI.
This adds a temporary fix for rustup on the Windows CI runners. The GitHub image updated to rustup 1.24.1 which has an issue (https://github.com/rust-lang/rustup/issues/2759) causing them to fail. This is fixed in 1.24.2. I believe the images are updated on roughly a weekly basis, and from what I can see the image just downloads the most recently release, so hopefully this will be fixed on GitHub's side in roughly a week. Until then, this will force rustup to update.
Note: Self updates aren't available on macOS images, but they seem to work on the others.
bors [Tue, 11 May 2021 18:12:23 +0000 (18:12 +0000)]
Auto merge of #9468 - PaulDance:fix-rustdoc-warnings, r=ehuss
Fix rustdoc warnings
Change some small parts of the unit documentation in order to resolve warnings emitted when running `cargo doc` from the root of this project. It should help reduce the noise when checking that new or updated documentation builds correctly.
See the commit messages for details about the modifications themselves, although they should be rather simple.
bors [Tue, 11 May 2021 14:22:21 +0000 (14:22 +0000)]
Auto merge of #9478 - ehuss:faster-git-status, r=alexcrichton
Improve performance of git status check in `cargo package`.
The check for a dirty repository during packaging/publishing is quite slow. It was calling `status_file` for every packaged file, which is very expensive. I have a directory that had about 10,000 untracked files. Previously, cargo would hang for over 2 minutes without any output. With this PR, it finishes in 0.3 seconds.
The solution here is to collect the status information once, and then compare the package list against it.
One subtle point is that it does not use `recurse_untracked_dirs`, and instead relies on a primitive `starts_with` comparison, which I believe should be equivalent.
This still includes an inefficient n^2 algorithm, but I am too lazy to make a better approach.
I'm moderately confident this is pretty much the same as before (at least, all the scenarios I could think of).
bors [Mon, 10 May 2021 23:32:46 +0000 (23:32 +0000)]
Auto merge of #9477 - ehuss:link-test-chapter, r=alexcrichton
Link to the new rustc tests chapter.
There's a new chapter in the rustc book on how the libtest harness works, and the command-line options it offers. This adds a few links to that new chapter in the cargo book.
bors [Mon, 10 May 2021 23:04:32 +0000 (23:04 +0000)]
Auto merge of #9476 - ehuss:index-cache-bump, r=alexcrichton
Bump index cache version to deal with semver metadata version mismatch.
#9467 has uncovered an issue with how versions are handled in the index cache. When using a debug build of Cargo, it may panic due to the [cache contents changing](https://github.com/rust-lang/cargo/blob/5c455130b6001c7f54e872e161c27f6e996aff1f/src/cargo/sources/registry/index.rs#L606-L619). The particular problem I am running into is that the index has an entry for `openssl-src 110.0.0` and `110.0.0+1.1.0f`. This is due to an issue with crates.io where it allows publishing multiple versions with the same metadata (https://github.com/rust-lang/crates.io/issues/1059). Cargos before #9467 would populate the index cache with two entries, both with version `110.0.0`. Afterwards, there are two separate entries (`110.0.0` and `110.0.0+1.1.0f`).
The change here is to bump the index cache version so that new versions of cargo will clear the cache, and won't trigger the assertion.
This may be a bit of a heavy-handed solution, as I think this only affects debug builds of cargo. However, I instantly started running into this problem, so I suspect it will be a real annoyance for anyone developing cargo. Happy to discuss other possible solutions.
bors [Mon, 10 May 2021 21:39:52 +0000 (21:39 +0000)]
Auto merge of #9475 - PaulDance:fix-test-support-warning, r=ehuss
Fix Url::into_string deprecation warning
```rust
warning: use of deprecated associated function `url::Url::into_string`: use Into<String>
--> src/registry.rs:183:26
|
183 | dl_url().into_string(),
| ^^^^^^^^^^^
|
= note: `#[warn(deprecated)]` on by default
```
is being emitted when running `cargo build` directly from the `crates/cargo-test-support` or the `crates/mdman` crate. This simply proposes a switch to the recommended method in order to resolve the deprecation warning.
bors [Mon, 10 May 2021 17:26:27 +0000 (17:26 +0000)]
Auto merge of #9469 - PaulDance:fossil-local-settings, r=ehuss
Fix #4482 and #9449: set Fossil ignore and clean settings locally
This aims to close #4482 and close #9449.
Context: currently, the Fossil extension for `cargo new` would call `fossil settings [...]` in order to configure the created repository to ignore and allow cleaning the `target` build directory. However, as #9449 shows, it is ran from the CWD, which is probably outside of the repo, therefore it modifies global settings instead of local ones. This PR fixes that by writing the settings to local versioned files as the issue recommends.
Furthermore, as #9449 notes, configuring the repository's ignore settings only in `util::vcs::FossilRepo::init` means it is not done when the repository is not new and makes it harder to maintain equivalent support for VCS ignore system implementations. It also completely ignores the `--lib` CLI option which adds `Cargo.lock` to the ignore list for Git and Mercurial.
Therefore, the following modifications have been performed, using [the Fossil documentation](https://fossil-scm.org/home/doc/trunk/www/globs.md) as a reference for the ignore syntax:
* All settings logic has been removed from `FossilRepo::init`.
* `ops::cargo_new::IgnoreList::push` now requires a third argument for Fossil-specific glob syntax that is stored in a new `fossil_ignore` field.
* `IgnoreList::format_new` uses the `fossil_ignore` field when needed just like any other VCS.
* `IgnoreList::format_existing` handles Fossil separately for a few operations as its glob syntax does not support comments, so any lines starting with `#` cannot be included: the configurations can only be merged here.
* `write_ignore_file` has been modified a bit as well to enable writing to two files for Fossil specifically in order to keep supporting its cleaning feature. The return type of the function is now `CargoResult<()>` instead `CargoResult<String>`: it makes the implementation easier and as the return value was actually not used, I figured it would be okay to do so, plus that return value would not make too much sense anymore for Fossil because of the two possibly different file contents.
* `mk` has been updated to provide the correct ignore glob to `IgnoreList::push` for Fossil.
bors [Mon, 10 May 2021 15:35:17 +0000 (15:35 +0000)]
Auto merge of #9472 - r00ster91:bettererrors, r=alexcrichton
Improve two error messages
The first error message saying "an integer" is confusing because if you give it `4` it's an integer but it will still complain that it must be an integer. So it's more specific now and tells you that it actually needs to be `1`, `2` or `3`.
In the second error there was a space missing. It says `is not a valid setting,must be`.
bors [Mon, 10 May 2021 13:47:40 +0000 (13:47 +0000)]
Auto merge of #9467 - ehuss:install-metadata, r=alexcrichton
Fix `cargo install` with a semver metadata version.
This fixes an issue where `cargo install cargo-c --version 0.8.0+cargo-0.51` fails (returns a 404 error when downloading) when the index has not yet been populated through other means. The crux of the issue is that the `PackageId` interner was treating `0.8.0+cargo-0.51` and `0.8.0` the same. Due to a chain of events, the interner was getting populated with `0.8.0` first, and then from there on always returned `0.8.0`. The full version information is needed to construct the download URL, so it was failing.
The reason the interner was getting populated with a version without the metadata is the following sequence of events:
1. There is [this "fast path" code path](https://github.com/rust-lang/cargo/blob/d1baf0d81d0e4f91881de8e544c71fb49f623047/src/cargo/ops/cargo_install.rs#L570) which checks if a version of a package is already installed *before updating the index*.
2. Since the index doesn't exist yet, the resolver query returns zero entries (because the Registry Source is empty) [here](https://github.com/rust-lang/cargo/blob/d1baf0d81d0e4f91881de8e544c71fb49f623047/src/cargo/ops/common_for_install_and_uninstall.rs#L546-L550).
3. That code checks if the package has been yanked (because it can't tell the difference between "yanked" and "index not downloaded, yet").
4. It constructs a `PackageId` using a `VersionReq` where the build metadata has been removed (because version reqs don't have build metadata).
5. When the real install continues (the error here is ignored for the purpose of this fast-path check if it is already installed), it downloads the index. However, the `PackageId` values created when parsing the index JSON files are now missing the build metadata because the interner is returning the wrong entries.
6. When the download starts, the URL is built from the `PackageId` missing the build metadata.
I only changed `PackageIdInner` to pay attention to the build metadata. This seems a bit fragile, as perhaps `PackageId` should also pay attention to it. However, I don't really want to do an audit of every use of `PackageId`, and offhand I can't think of other situations where it would matter.
Paul Mabileau [Sun, 9 May 2021 20:13:55 +0000 (22:13 +0200)]
Set Fossil ignore and clean settings locally
Previously, the Fossil extension for `cargo new` would call `fossil
settings [...]` in order to configure the created repository to ignore
and allow cleaning the `target` build directory. However, as #9449
shows, it is ran from the CWD, which is probably outside of the repo,
therefore it modifies global settings instead of local ones. This aims
to fix that by writing the settings to local versioned files as the
issue recommends.
Signed-off-by: Paul Mabileau <paulmabileau@hotmail.fr>
Paul Mabileau [Sun, 9 May 2021 17:37:13 +0000 (19:37 +0200)]
Resolve doc warnings for RegistryData
Specify `Self::finish_download` instead of just `finish_download` and
link to `crate::core::package::Downloads` instead of `Download` as
`Downloads` is the public one, does the actual stuff and `Download` only
stores data.
Signed-off-by: Paul Mabileau <paulmabileau@hotmail.fr>
bors [Fri, 7 May 2021 21:29:52 +0000 (21:29 +0000)]
Auto merge of #9375 - vojtechkral:tests-target-dir, r=ehuss
Add CARGO_TARGET_TMPDIR env var for integration tests & benches
Hi.
Recently I [ran into](https://github.com/vojtechkral/bard/blob/main/tests/util/mod.rs#L32) the problem that integration tests don't have a good way to figure out where `target` dir is.
Knowing where `target` is is useful for integration tests that need to setup some filesystem structure for test cases. In fact `cargo` itself does this too (and figures out the path rather clumsily).
Another popular way of doing this is to create a directory in `/tmp` (or quivalent on other systems), however, I believe using subdirectory in `target` is better as testcases are easier to debug that way and temporary locations aren't polluted.
I think this would also address some concerns in #2841
Another solution might be to provide a dedicated subdirectory in `target` for this, something like `target/scratchpad`, but I'm not convinced this is warranted... Edit: That's what was decided to do, see below...
Let me know what you think :slightly_smiling_face:
Vojtech Kral [Thu, 6 May 2021 21:04:52 +0000 (23:04 +0200)]
Add CARGO_TARGET_TMPDIR env var for integration tests & benches
The variable is set to $target_dir/$config/tmp
This is a directory where tests & benches can place testcasei-related data
for use by the tests.
cargo makes sure the directory exists when building tests/benches.
bors [Wed, 5 May 2021 14:04:05 +0000 (14:04 +0000)]
Auto merge of #9457 - ehuss:unstable-doc-updates, r=alexcrichton
Some updates to the unstable documentation
* Extends the future-incompat docs.
* Adds `cargo rustc --print`
* Adds a table of contents. The chapter is really long and unorganized, so I hope this can maybe help make things easier to discover.
bors [Mon, 3 May 2021 14:41:36 +0000 (14:41 +0000)]
Auto merge of #9438 - ehuss:report-subcommand, r=alexcrichton
Add `report` subcommand.
This renames the `cargo describe-future-incompatibilities` subcommand to `cargo report future-incompatibilities`. The intent here is to have a general `report` subcommand that can be used for other reports in the future. This helps avoid the proliferation of top-level subcommands, and to help keep the CLI a little more organized.
bors [Sat, 1 May 2021 15:35:48 +0000 (15:35 +0000)]
Auto merge of #9186 - weihanglo:issue-9054, r=alexcrichton
Respect Cargo.toml `[package.exclude]` even not in a git repo.
May resolves #9054
This bug (or feature?) has been lingering for a while. #7680 fixed the `cargo package` part but `cargo vendor` is still affected by the heuristic rule of ignoring dotfiles. ~~I propose to drop the rule and include dotfiles by default even if the package is not under git-controlled~~. See below.
## Updated: Changes Summary
`cargo vendor` vendors dependencies without git-controlled but `cargo package` often runs under a VCS like git. [These lines](https://github.com/rust-lang/cargo/blob/1ca930b/src/cargo/sources/path.rs#L161-L168) are where they diverges: `fn list_files_walk_except_dot_files_and_dirs` builds [its own ignore instance], which cannot merge with other filter rules from `[package.exclude]`. This causes some patterns to not work as expected, such as re-including file after ignoring dotfiles `[.*, !negated_file]`.
To make re-include (negate) rule works, this patch adds the excluding dotfiles rule directly into the `package.exclude` ignore instance if **_no include option nor git repo exists_**. Other old behaviors should not change in this patch.
[its own ignore instance]: https://github.com/rust-lang/cargo/blob/1ca930b6/src/cargo/sources/path.rs#L364-L366
Auto merge of #9440 - ehuss:fix-metrics-test, r=Eh2406
Fix problem with metrics test.
The `counter_zero_slot` test was checking for an assertion that only fires in a debug build. However, upstream `rust-lang/rust` runs tests in `--release` mode. This unblocks the upstream update.
Auto merge of #9434 - ehuss:collision-doc-j1, r=Eh2406
Fix collision doc tests randomly failing.
This fixes some tests that were randomly failing on CI. The cause is that #9419 added a remove_dir_all on the `doc` directory. However, if two jobs are trying to write to that directory at the same time, this can cause errors. The failure rate is low (a little over 1%), and I was unable to reproduce locally (only on GitHub's CI and only on the Windows job).
The solution is to run the jobs with -j1 so they run serially.
I only saw errors for `collision_doc_sources`, but to be on the safe side I added j1 to similar tests.
Auto merge of #9421 - lf-:meowwwwww, r=alexcrichton
Fix dep-info files emitting paths relative to deps' roots
Sample `shoo.d` file prior to this change is below, note the `build.rs`
at the end, which was not from my package.
From booping the debugger, I found this was coming from
`compiler_builtins`. This is not really their bug though: if a build.rs
asks for rerun-if-changed on some crate relative path, this will happen
in general. So I've fixed it in Cargo and added a test to prevent it
regressing.
Auto merge of #9428 - rust-lang:dependabot/add-v2-config-file, r=alexcrichton
Upgrade to GitHub-native Dependabot
_Dependabot Preview will be shut down on August 3rd, 2021. In order to keep getting Dependabot updates, please merge this PR and migrate to GitHub-native Dependabot before then._
Dependabot has been fully integrated into GitHub, so you no longer have to install and manage a separate app. This pull request migrates your configuration from Dependabot.com to a config file, using the [new syntax][new_syntax]. When merged, we'll swap out `dependabot-preview` (me) for a new `dependabot` app, and you'll be all set!
With this change, you'll now use the [Dependabot page in GitHub][dependabot_page], rather than the [Dependabot dashboard][dashboard], to monitor your version updates, and you'll configure Dependabot through the new config file rather than a UI.
If you've got any questions or feedback for us, please let us know by creating an issue in the [dependabot/dependabot-core][issues] repository.
[Learn more about migrating to GitHub-native Dependabot][learn]
Please note that regular ``@dependabot`` commands do not work on this pull request.
Auto merge of #9419 - ehuss:doc-meta-rebuild, r=alexcrichton
Fix rebuild issues with rustdoc.
This fixes two issues related to rebuilds with rustdoc:
* Switching features when running `cargo doc` would result in Cargo not rebuilding the documentation. This is because it was keeping the fingerprints in separate directories based on the features used. However, the rustdoc output isn't keyed off the metadata hash, so although the old fingerprint seemed "up to date", in reality the documentation was rewritten and needs to be rebuilt. The solution is to use a simplified hash for the fingerprint directory name.
* Removing items does not remove the files from the doc directory. This changes it to clear the package's doc directory before running rustdoc, to ensure any stale files are removed.
I'm a little concerned about potential performance impact of running `remove_dir_all`, but I think it shouldn't be too bad?
Auto merge of #9418 - ehuss:always-meta, r=alexcrichton
Always use full metadata hash for -C metadata.
This changes it so that cargo always uses the full metadata hash for `-C metadata`. This ensures that even if a unit isn't using `-C extra-filename` that the symbol hashing uses all the fields used in the other cases.
This fixes an issue on macOS where a combination of split-debuginfo and incremental caused the same `.o` filenames to be used, which caused corruption in the incremental cache (see issue for details).
Fix dep-info files emitting paths relative to deps' roots
Sample `shoo.d` file prior to this change is below, note the `build.rs`
at the end, which was not from my package.
From booping the debugger, I found this was coming from
`compiler_builtins`. This is not really their bug though: if a build.rs
asks for rerun-if-changed on some crate relative path, this will happen
in general. So I've fixed it in Cargo and added a test to prevent it
regressing.
Auto merge of #9030 - Ekleog:target-setting, r=alexcrichton
Expose build.target .cargo/config setting as packages.target in Cargo.toml
Hey!
I'm trying to do my first cargo contribution by implementing per-crate target settings as per [the irlo thread](https://internals.rust-lang.org/t/proposal-move-some-cargo-config-settings-to-cargo-toml/13336) ; and I think I have a draft that looks good-ish (the root units returned by `generate_targets` have the right kinds set).
Closes #7004
**_Edit: the below problem description is now solved in the latest version of this PR, please ignore_**
But for some reason running on a test project now blocks on `Blocking waiting for file lock on build directory` and I have literally no idea how my changes could trigger this… would anyone have an idea of how the changes could lead to infinitely blocking there? (I already tried cargo clean just in case and it didn't appear to help)
FWIW, the output that looks hopeful to me is, on my testbed workspace:
```
Root units [out of generate_targets] are [...]:
- package ‘smtp-client’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘smtp-server’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘yuubind-config’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘smtp-message-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘yuubind-rpc’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘yuubind-config-example’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘smtp-message-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘yuubind-config-example’ with kind ‘Target(CompileTarget { name: "wasm32-unknown-unknown" })’
- package ‘smtp-queue’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘smtp-message-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘smtp-message’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘smtp-server-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘yuubind-config’ with kind ‘Target(CompileTarget { name: "wasm32-unknown-unknown" })’
- package ‘yuubind’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
- package ‘smtp-queue-fs’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
```
(where both `yuubind-config` and `yuubind-config-example` are being configured to be `wasm32-unknown-unknown` and the other ones stay as host).
Interestingly enough, if I remove the `target` setting from `yuubind-config` (and leave it on `yuubind-config-example`) then it does no longer block on waiting for file lock on build directory, even though it does not actually compile with `wasm32-unknown-unknown`. And it does appear to correctly build yuubind-config-example as wasm32.
My investigation shows that it appears to happen iff there is a package with `package.target` being set that has dependencies.
This most likely is a bug in my code (eg. I build only the root units and not the whole unit graph maybe?), and am going to keep investigating it as such, but maybe someone would already know how dependency resolution could interact with build lock acquisition and give me hints?
Auto merge of #9404 - ehuss:rustdoc-fingerprint-remove-dir, r=alexcrichton
Some changes to rustdoc fingerprint checking.
#8640 introduced a check which deletes the `doc` directory if cargo detects it has stale contents from a different toolchain version. Rustdoc has some shared files (js and css for example) that can get corrupted between versions. Unfortunately that caused some problems with rustbuild which does a few unusual things. Rustbuild will:
* Create the `doc` directory before running `cargo doc` and places a `.stamp` file inside it.
* Creates symlinks of the `doc` directory so that they can be shared across different target directories (in particular, between rustc and rustdoc).
In order to address these issues, this PR does several things:
* Adds `-Z skip-rustdoc-fingerprint` to disable the `doc` clearing behavior.
* Don't delete the `doc` directory if the rustdoc fingerprint is missing. This is intended to help with the scenario where the user creates a `doc` directory ahead of time with pre-existing contents before the first build. The downside is that cargo will not be able to protect against switching from pre-1.53 to post-1.53.
* Don't delete the `doc` directory itself (just its contents). This should help if the user created the `doc` directory as a symlink to somewhere else.
* Don't delete hidden files in the `doc` directory. This isn't something that rustdoc creates.
Only the `-Z` change is needed for rustbuild. The others I figured I'd include just to be on the safe side in case there are other users doing unusual things (and I had already written them thinking they would work for rustbuild). Hopefully the rustbuild `.stamp` mechanism will be enough protection there.
Eric Huss [Sat, 24 Apr 2021 15:22:44 +0000 (08:22 -0700)]
Add -Zskip-rustdoc-fingerprint
This is a hidden flag intended to only be used by rustbuild which will
skip the rustdoc fingerprint check. rustbuild does some funky things
with sharing the doc directory across multiple target directories via
symlinks, and that causes problems where after building in one target
directory, then switching to the second one, it will clear the contents.
Eric Huss [Sat, 24 Apr 2021 15:07:57 +0000 (08:07 -0700)]
rustdoc fingerprint: don't delete the top directory
In some cases, the directory may actually be a symlink created by the
user, and we don't want to delete it. Also, skip any hidden files added
by the user as well.
Auto merge of #9397 - alexcrichton:fix-hash, r=ehuss
Restore crates.io's `SourceId` hash value to before
This commit restores the hash value of the crates.io `SourceId` to what
it was before #9384. In #9384 the enum variants of `SourceKind` were
reordered which accidentally changed the hash value of the `SourceId`
for crates.io. A change here means that users with a new version of
Cargo will have to redownload the index and all crates, which is
something that we strive to avoid forcing.
In changing this, though, it required a manual implementation of `Ord`
to still contain the actual fix from #9384 which is to sort `SourceKind`
differently from how it's defined. I was curious as to why this was
necessary since it wasn't ever necessary in the past and this led to an
odd spelunking which turned up some interesting information. Turns out
Rust 1.47 and after had a breaking change where Cargo would sort
dependencies differently. This means that #9334 *could* have been opened
up much earlier, but it never was. We ironically only saw an issue when
we fixed this regression (although we didn't realize we were fixing a
regression). This means that we are now permanently codifying the
regression in Cargo.
Alex Crichton [Fri, 23 Apr 2021 18:59:18 +0000 (11:59 -0700)]
Restore crates.io's `SourceId` hash value to before
This commit restores the hash value of the crates.io `SourceId` to what
it was before #9384. In #9384 the enum variants of `SourceKind` were
reordered which accidentally changed the hash value of the `SourceId`
for crates.io. A change here means that users with a new version of
Cargo will have to redownload the index and all crates, which is
something that we strive to avoid forcing.
In changing this, though, it required a manual implementation of `Ord`
to still contain the actual fix from #9384 which is to sort `SourceKind`
differently from how it's defined. I was curious as to why this was
necessary since it wasn't ever necessary in the past and this led to an
odd spelunking which turned up some interesting information. Turns out
Rust 1.47 and after had a breaking change where Cargo would sort
dependencies differently. This means that #9334 *could* have been opened
up much earlier, but it never was. We ironically only saw an issue when
we fixed this regression (although we didn't realize we were fixing a
regression). This means that we are now permanently codifying the
regression in Cargo.
Auto merge of #9392 - alexcrichton:fix-patch-git-head-issue, r=ehuss
Fix loading `branch=master` patches in the v3 lock transition
This commit fixes an issue pointed out during #9352 where in the v2->v3
lock file transition (currently happening on nightly) Cargo will not
correctly use the previous lock file entry for `[patch]` directives that
point to git dependencies using `branch = 'master'` explicitly. The
reason for this is that Cargo previously, with the v2 format, considered
`branch=master` and `DefaultBranch` to be equivalent dependencies. Now
that Cargo treats those as distinct resolve nodes we need to load lock
files that use `DefaultBranch` and transparently use those for
`branch=master` dependencies.
These lock file nodes do not naturally unify so we have to go out of our
way to get the two to line up in modern Cargo. This was previously done
for the lock file at large, but the previous logic didn't take `[patch]`
into account. Unfortunately almost everything to do with `[patch]` and
lock files is pretty complicated, and this is no exception. The fix here
is wordy, verbose, and quite subtle in how it works. I'm pretty sure it
does work though and I think that this should be good enough to at least
transition most users off the v2 lock file format. Once this has baked
in Cargo for some time (on the scale of a year) I would hope that we
could just remove this logic since it's only really here for a
transitionary period.
Auto merge of #9393 - ehuss:build-std-updating, r=alexcrichton
Fix build-std updating the index on every build.
https://github.com/rust-lang/rust/pull/83776 has caused a problem where build-std will update the index on every build. That PR added `std_detect` from the `stdarch` submodule as a path dependency of `std`. However, since `stdarch` has a workspace of its own, an exclusion had to be added to `Cargo.toml` so that it does not treat `std_detect` as a workspace member (because nested workspaces are not supported).
The problem is that the std `Cargo.lock` file is built thinking that `std_detect` is *not* a workspace member. This means that its dev-dependencies are not included. However, when cargo resolves the std workspace, it doesn't know that `std_detect` should be excluded, so it considers it a workspace member (because it is a path dependency). This means that it expects the dev-dependencies to be in Cargo.lock. Because they are missing, it ends up poisoning the registry and triggering an update:
> poisoning registry `https://github.com/rust-lang/crates.io-index` because std_detect v0.1.5 (/Users/eric/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/stdarch/crates/std_detect) looks like it changed auxv
The solution here is to skip dev-dependencies if they are not actively being resolved, even if the package is a workspace member.
This has happened before (#8962), so I have updated the test to check for it.
There are some alternative solutions I considered:
* Add support for nested workspaces. 😄
* Use a symlink to `std_detect` in the `rust-lang/rust` repository so that it appears to cargo as-if it is "outside" of the stdarch workspace, and thus can be treated like a normal workspace member (and remove the "exclude"). That seems a little hacky.
projects / cargo.git / log