3 typos and some capitalization
3 typos and...
Most of the docs use "command-line" instead of "commandline", changed where it made sense (in plain text).
Most of the docs also use "SemVer" instead of "semver", changed for consistency except for the "semver trick" (consistent with context).
I believe these are the correct files to change, since none of these changes are in doc/man?
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.
Cheers,
Paul.
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).
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.
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](5c455130b6/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.
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.
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.
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`.
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](d1baf0d81d/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](d1baf0d81d/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.
Closes#9410
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>
Specify `Self::finish_download` instead of just `finish_download` and
link to `crate::core:📦: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>
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 🙂
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.
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.
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.
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
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.
Show transfer rate when fetching/updating registry index
Possibly fixes#8483.
To avoid blinking too frequently, update rate is throttled by one second.
I am not sure how to write tests for it 😂
<img width="896" alt="image" src="https://user-images.githubusercontent.com/14314532/115879831-ac62fb00-a47c-11eb-9b12-735ce8192ebe.png">
# Updated (2020-04-28)
Current looking
```
Updating crates.io index
Fetch [==> ] 14.50%, 258.45KiB/s
Updating crates.io index
Fetch [======> ] 40.50%, (1234/282342) resolving deltas
```
