bors [Fri, 29 Oct 2021 14:45:06 +0000 (14:45 +0000)]
Auto merge of #10018 - Some-Dood:chore/use-hashmap-from, r=alexcrichton
Chore: prefer `HashMap::from` rather than collecting `Vec` of tuples
Hello there! Since Cargo upgraded to the 2021 Edition recently (which implies a `rust-version` of `1.56` or greater), I figured now may be a good time to use the new [`HashMap::from` shortcut](https://doc.rust-lang.org/stable/std/collections/struct.HashMap.html#impl-From%3C%5B(K%2C%20V)%3B%20N%5D%3E) of rust-lang/rust#84111. There should be no change in behavior here, but it does make the code a little bit neater! 🎉
bors [Fri, 29 Oct 2021 14:07:40 +0000 (14:07 +0000)]
Auto merge of #10017 - willcrichton:example-analyzer, r=alexcrichton
Change --scrape-examples flag to -Z rustdoc-scrape-examples
I'm working on getting the scrape examples feature working on docs.rs. However, docs.rs uses `cargo rustdoc` instead of `cargo doc`, and right now the `--scrape-examples` flag is only allowed for `cargo doc`. So this PR changes it to a `-Z` flag that can be passed to either command.
Will Crichton [Thu, 28 Oct 2021 07:35:34 +0000 (00:35 -0700)]
Change scraping to apply to all workspace packages instead of just
root units. Only attach Docscrape unit dependencies to workspace Doc
units. Add test for scraping examples with complex reverse dependencies.
Will Crichton [Wed, 27 Oct 2021 18:42:13 +0000 (11:42 -0700)]
Fix several bugs when checking wasmtime repo:
* Docscrape unit not having dev-dependencies included
* Sources for reverse-dependencies generated to the wrong directory
* Incorrect features being selected for Docscrape units
* Panics from Docscrape-dependent packages not being available
bors [Sat, 23 Oct 2021 18:08:27 +0000 (18:08 +0000)]
Auto merge of #10000 - alexcrichton:upgrade-edition, r=Eh2406
Upgrade Cargo to the 2021 edition
While I was poking around in the manifests I also went ahead and removed the `authors` entries since at least the one for Cargo itself is quite outdated and Cargo otherwise doesn't use these any more.
bors [Sat, 23 Oct 2021 08:18:01 +0000 (08:18 +0000)]
Auto merge of #9991 - Byron:fix-test-failure-due-to-echo-resolution, r=joshtriplett
Don't canonicalize executable path
Otherwise symbolic links may also accidentally be resolved which may lead to unexpected results in the case of 'coreutils', a binary that depends on the executable name being a symbolic link.
This means a path like /bin/echo being canonicalized to /bin/coreutils will loose all information about the desired functionality.
For example, test failures will occur if 'echo' is resolved that way and it's not trivial to find the cause of it in the provided error messages. For example`doc_workspace_open_different_library_and_package_names` did fail for me on MacOS, Nix packages in PATH, but works with this patch.
With this patch, there is still the possibility that a path gets canonicalized for its relative path components, but still results in changing the name of the binary. I could imagine to check for binary name changes and panic if `coreutils` or `busybox` is encountered, which are known to fail without a symlink telling them which program to emulate.
Sebastian Thiel [Thu, 21 Oct 2021 09:03:58 +0000 (17:03 +0800)]
Only canonicalize executable path if it has relative directories
Otherwise symbolic links may also accidentally be resolved which may
lead to unexpected results in the case of 'coreutils', a binary
that depends on the executable name being a symbolic link.
This means a path like /bin/echo being canonicalized to /bin/coreutils
will loose all information about the desired functionality.
Test failures will occur if 'echo' is resolved that way and it's
not trivial to find the cause of it in the provided error messages.
bors [Tue, 19 Oct 2021 02:16:48 +0000 (02:16 +0000)]
Auto merge of #9953 - Aaron1011:nicer-incompat-report, r=ehuss
Make future-incompat-report output more user-friendly
When the user enables `--future-incompat-report`, we now display
a high-level summary of the problem, as well as several suggestions
for fixing the affected crates.
The command `cargo report future-incompatibilities` now takes
a `--crate` option, which can be used to display a report
(including the actual lint messages) for a single crate.
When this option is not used, we display the report for all
crates.
```
Finished dev [unoptimized + debuginfo] target(s) in 2.09s
warning: the following packages contain code that will be rejected by a future version of Rust: actix v0.11.1 (/home/aaron/repos/actix/actix), ahash v0.7.4, arc-swap v0.4.4, autocfg v1.0.0, crossbeam-utils v0.8.5, futures-macro v0.3.17, futures-util v0.3.17, lazy_static v1.4.0, libc v0.2.103, lock_api v0.4.5, log v0.4.8, mio v0.7.13, parking_lot_core v0.8.5, signal-hook-registry v1.2.0, smallvec v1.7.0, syn v1.0.77, tokio v1.12.0, tokio-util v0.6.8, unicode-xid v0.2.0, version_check v0.9.3
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 2`
```
Finished dev [unoptimized + debuginfo] target(s) in 2.12s
warning: the following packages contain code that will be rejected by a future version of Rust: actix v0.11.1 (/home/aaron/repos/actix/actix), ahash v0.7.4, arc-swap v0.4.4, autocfg v1.0.0, crossbeam-utils v0.8.5, futures-macro v0.3.17, futures-util v0.3.17, lazy_static v1.4.0, libc v0.2.103, lock_api v0.4.5, log v0.4.8, mio v0.7.13, parking_lot_core v0.8.5, signal-hook-registry v1.2.0, smallvec v1.7.0, syn v1.0.77, tokio v1.12.0, tokio-util v0.6.8, unicode-xid v0.2.0, version_check v0.9.3
note:
To solve this problem, you can try the following approaches:
- Some affected dependencies have newer versions available.
You may want to consider updating them to a newer version to see if the issue has been fixed.
ahash v0.7.4 has the following newer versions available: 0.7.5
arc-swap v0.4.4 has the following newer versions available: 0.4.8, 1.1.0, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.4.0
autocfg v1.0.0 has the following newer versions available: 1.0.1
log v0.4.8 has the following newer versions available: 0.4.11, 0.4.13, 0.4.14
signal-hook-registry v1.2.0 has the following newer versions available: 1.2.1, 1.2.2, 1.3.0, 1.4.0
syn v1.0.77 has the following newer versions available: 1.0.78, 1.0.79, 1.0.80
unicode-xid v0.2.0 has the following newer versions available: 0.2.1, 0.2.2
- If the issue is not solved by updating the dependencies, a fix has to be
implemented by those dependencies. You can help with that by notifying the
maintainers of this problem (e.g. by creating a bug report) or by proposing a
fix to the maintainers (e.g. by creating a pull request):
- If waiting for an upstream fix is not an option, you can use the `[patch]`
section in `Cargo.toml` to use your own version of the dependency. For more
information, see:
https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section
note: this report can be shown with `cargo report future-incompatibilities -Z future-incompat-report --id 3`
```
`> RUSTFLAGS="-Z future-incompat-test" ~/repos/cargo/target/debug/cargo report future-incompatibilities -Z future-incompat-report --color never | head -n 100`
```
The following warnings were discovered during the build. These warnings are an
indication that the packages contain code that will become an error in a
future release of Rust. These warnings typically cover changes to close
soundness problems, unintended or undocumented behavior, or critical problems
that cannot be fixed in a backwards-compatible fashion, and are not expected
to be in wide use.
Each warning should contain a link for more information on what the warning
means and how to resolve it.
- Some affected dependencies have newer versions available.
You may want to consider updating them to a newer version to see if the issue has been fixed.
ahash v0.7.4 has the following newer versions available: 0.7.5
arc-swap v0.4.4 has the following newer versions available: 0.4.8, 1.1.0, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.4.0
autocfg v1.0.0 has the following newer versions available: 1.0.1
log v0.4.8 has the following newer versions available: 0.4.11, 0.4.13, 0.4.14
signal-hook-registry v1.2.0 has the following newer versions available: 1.2.1, 1.2.2, 1.3.0, 1.4.0
syn v1.0.77 has the following newer versions available: 1.0.78, 1.0.79, 1.0.80
unicode-xid v0.2.0 has the following newer versions available: 0.2.1, 0.2.2
The package `actix v0.11.1 (/home/aaron/repos/actix/actix)` currently triggers the following future incompatibility lints:
> warning: use of deprecated struct `utils::Condition`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:25:9
> |
> 25 | impl<T> Condition<T>
> | ^^^^^^^^^
> |
> note: the lint level is defined here
> --> actix/src/lib.rs:30:10
> |
> 30 | #![allow(deprecated)]
> | ^^^^^^^^^^
>
> warning: use of deprecated struct `utils::Condition`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:42:21
> |
> 42 | impl<T> Default for Condition<T>
> | ^^^^^^^^^
>
> warning: use of deprecated struct `utils::Condition`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:47:9
> |
> 47 | Condition {
> | ^^^^^^^^^
>
> warning: use of deprecated struct `utils::Condition`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/lib.rs:120:28
> |
> 120 | pub use crate::utils::{Condition, IntervalFunc, TimerFunc};
> | ^^^^^^^^^
>
> warning: use of deprecated associated function `std::sync::atomic::AtomicUsize::compare_and_swap`: Use `compare_exchange` or `compare_exchange_weak` instead
> --> actix/src/address/channel.rs:512:49
> |
> 512 | let actual = self.inner.num_senders.compare_and_swap(curr, next, SeqCst);
> | ^^^^^^^^^^^^^^^^
>
> warning: use of deprecated associated function `std::sync::atomic::AtomicUsize::compare_and_swap`: Use `compare_exchange` or `compare_exchange_weak` instead
> --> actix/src/address/channel.rs:636:49
> |
> 636 | let actual = self.inner.num_senders.compare_and_swap(curr, next, SeqCst);
> | ^^^^^^^^^^^^^^^^
>
> warning: use of deprecated associated function `std::sync::atomic::AtomicUsize::compare_and_swap`: Use `compare_exchange` or `compare_exchange_weak` instead
> --> actix/src/address/channel.rs:697:49
> |
> 697 | let actual = self.inner.num_senders.compare_and_swap(curr, next, SeqCst);
> | ^^^^^^^^^^^^^^^^
>
> warning: use of deprecated field `utils::Condition::waiters`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:31:9
> |
> 31 | self.waiters.push(tx);
> | ^^^^^^^^^^^^
>
> warning: use of deprecated field `utils::Condition::waiters`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:36:23
> |
> 36 | for waiter in self.waiters {
> | ^^^^^^^^^^^^
>
> warning: use of deprecated field `utils::Condition::waiters`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:48:13
> |
> 48 | waiters: Vec::new(),
> | ^^^^^^^^^^^^^^^^^^^
>
> warning: unused variable: `ctx`
> --> actix/src/actor.rs:78:27
> |
> 78 | fn started(&mut self, ctx: &mut Self::Context) {}
> | ^^^ help: if this is intentional, prefix it with an underscore: `_ctx`
> |
> note: the lint level is defined here
> --> actix/src/actor.rs:72:9
> |
> 72 | #[allow(unused_variables)]
> | ^^^^^^^^^^^^^^^^
```
bors [Mon, 18 Oct 2021 22:00:14 +0000 (22:00 +0000)]
Auto merge of #9979 - ehuss:git-fetch-force, r=alexcrichton
Fix fetching git repos after a force push.
Users have been reporting that the index has not been updating for them. This was caused by the update to libgit2 1.3 (from 1.1) which has changed some behavior around force pushes. The index was squashed on 2021-09-24, and if a user had the index fetched from before that point, and they used nightly-2021-10-14 or newer, then the fetch would succeed, but the `refs/remotes/origin/HEAD` would not get updated. Cargo uses the `origin/HEAD` ref to know what to look at, and thus was looking at old data.
The solution here is to use `+` on the refspec to force libgit2 to do a forced update (a fast-forward). I think this may have been introduced in libgit2 1.2 via https://github.com/libgit2/libgit2/pull/5854, though that is just a guess.
bors [Tue, 12 Oct 2021 21:59:48 +0000 (21:59 +0000)]
Auto merge of #9955 - ehuss:benchsuite, r=Eh2406
Add the start of a basic benchmarking suite.
This adds the start of a basic benchmarking suite for cargo. This is fairly rough, but I figure it will change and evolve over time based on what we decide to add and how we use it.
There is some documentation in the `benches/README.md` file which gives an overview of what is here and how to use it.
Aaron Hill [Fri, 27 Aug 2021 18:16:17 +0000 (13:16 -0500)]
Make future-incompat-report output more user-friendly
When the user enables `--future-incompat-report`, we now display
a high-level summary of the problem, as well as several suggestions
for fixing the affected crates.
The command `cargo report future-incompatibilities` now takes
a `--crate` option, which can be used to display a report
(including the actual lint messages) for a single crate.
When this option is not used, we display the report for all
crates.
bors [Tue, 12 Oct 2021 15:11:01 +0000 (15:11 +0000)]
Auto merge of #9970 - ehuss:issue-template-forms, r=alexcrichton
Use forms for issue templates.
This switches the GitHub issue templates to use the new forms functionality. This makes it so that the user doesn't need to fuss with editing the placeholder text, and instead can just start writing text.
I'm mostly just curious how this will work out. If people have trouble with it, or there are complaints, it can be reverted pretty easily.
bors [Tue, 12 Oct 2021 14:40:34 +0000 (14:40 +0000)]
Auto merge of #9967 - flip1995:rust_version_meta, r=alexcrichton
Add rust_metadata to SerializedPackage
After the rust_version field was stabilized in #9732 this adds the
rust_version as output to the `cargo metadata` command, so tools like
Clippy can read and use it as well.
We will probably need this for rust-lang/rust-clippy#7765
flip1995 [Fri, 8 Oct 2021 17:00:39 +0000 (19:00 +0200)]
Add rust_metadata to SerializedPackage
After the rust_version field was stabilized in #9732 this adds the
rust_version as output to the `cargo metadata` command, so tools like
Clippy can read and use it as well.
And enables the use of the `--profile` CLI option to choose a profile by name.
Another key change here is that cargo now only uses a single profile per command. Previously, some commands such as `cargo test` would use a mix of profiles based on which package and target were being built.
### Summary of new behavior
* Profiles can now have arbitrary names. New profiles require the `inherits` key.
* The `--profile` flag is now available on all build commands.
* The `CompileMode` is no longer considered for choosing the profile, only one profile will be used. Previously, building a test, benchmark, or doctest would use the test or bench profile, and all dependencies would use the dev/release profiles. This change is done to arguably make it easier to understand, and to possibly give more desired and intuitive behavior.
* The `test` profile now inherits settings from the `dev` profile (and `bench` from `release`).
### Deviations from the original RFC and implementation
* The original RFC indicated that `--all-targets` without `--profile` would retain the old behavior where it would use different profiles for different targets. However, the implementation uses a single profile, to avoid confusion and to keep things simple.
* The `dir-name` key is not exposed to the user. The implementation is retained to handle mapping of built-in profile names (test/dev→debug, bench→release). This can be exposed in the future if necessary.
### Notes about this PR
* Fixed an issue where the duplicate package override check would randomly return matches for inherited profiles like `test`.
* I left some of the old, vestigial code behind to possibly make it easier to revert this PR if necessary. If this does land, I think it can be eventually removed (code using `Feature::named_profiles` and various things using `named_profiles_enabled`).
* Added `target` to reserved list, just because.
* Adds a warning if `--release` is combined with `--profile` in `cargo rustc`, `check`, or `fix`. The `--release` flag was being ignored.
### Hazards and concerns
* This has had very little real-world testing.
* Custom profile directories may conflict with other things in the `target` directory. We have reserved profile names that currently conflict (such as `doc` or `package`). However, they can still collide with target names. This also presents a hazard if Cargo ever wants to add new things to that top directory. We decided to proceed with this because:
* We currently have no plans to add new built-in profiles.
* We have reserved several profile names (including anything starting with "cargo"), and the profile name syntax is deliberately limited (so cargo is still free to add `.` prefixed hidden directories).
* A user creating a profile that collides with a target name resides in the "don't do that" territory. Also, that shouldn't be catastrophic, as the directories are still somewhat organized differently.
* Artifacts may no longer be shared in some circumstances. This can lead to substantially increased `target` directory sizes (and build times), particularly if the `test` profile is not the same as the `dev` profile. Previously, dependencies would use the `dev` profile for both. If the user wants to retain the old behavior, they can use an override like `[profile.test.package."*"]` and set the same settings as `dev`.
* This may break existing workflows. It is possible, though unlikely, that changes to the profile settings will cause changes to how things build in such a way to break behavior.
* Another example is using something like `cargo build` to prime a cache that is used for `cargo test`, and there is a custom `test` profile, the cache will no longer be primed.
* The legacy behavior with `cargo rustc`, `cargo check`, and `cargo fix` may be confusing. We may in the future consider something like a `--mode` flag to formalize that behavior.
* The `PROFILE` environment variable in build scripts may cause confusion or cause problems since it only sets `release` or `debug`. Some people may be using that to determine if `--release` should be used for a recursive `cargo` invocation. Currently I noted in the documentation that it shouldn't be used. However, I think it could be reasonable to maybe add a separate environment variable (`PROFILE_NAME`?) that exposes the actual profile used. We felt that changing the existing value could cause too much breakage (and the mapping of debug→dev is a little awkward).
bors [Tue, 5 Oct 2021 18:16:42 +0000 (18:16 +0000)]
Auto merge of #9847 - weihanglo:issue-9840, r=Eh2406
Distinguish lockfile version req from normal dep in resolver error message
Resolves #9840
This PR adds a new variant `OptVersionReq::Locked` as #9840 described.
The new variant represents as a locked version requirement that contains
an exact locked version and the original version requirement.
Previously we use exact version req to synthesize locked version req.
Now we make those need a truly locked to be `OptVersionReq::Locked`,
including:
- `[patch]`: previous used exact version req to emulate locked version,
and it only need to lock dep version but not source ID, so we make
an extra method `Dependency::lock_version` for it.
- Dependencies from lock files: No need to change the call site.
bors [Fri, 1 Oct 2021 16:59:58 +0000 (16:59 +0000)]
Auto merge of #9951 - relrelb:completion, r=alexcrichton
Add shell completion for shorthand commands
Currently `cargo` has shell completion for most (if not all) builtin commands such as `build`, `run`, `check` etc.
However, it doesn't have shell completion for the short forms of these commands, such as `b`, `r`, `c` etc.
This PR adds both bash and zsh completions for command shorthands.
relrelb [Fri, 1 Oct 2021 08:14:45 +0000 (11:14 +0300)]
Add shell completion for shorthand commands
Currently `cargo` has shell completion for most (if not all) builtin
commands such as `build`, `run`, `check` etc.
However, it doesn't have shell completion for the short forms of these
commands, such as `b`, `r`, `c` etc.
This commit adds both bash and zsh completions for command shorthands.
Auto merge of #9945 - ehuss:update-precise-metadata, r=alexcrichton
Allow `cargo update --precise` with metadata.
`cargo update --precise` would require that the version matches *exactly*, including build metadata. Usually the build metadata is ignored (like in dependency declarations), but in this circumstance it isn't. This can be awkward in some cases where it can be more convenient to type just the version number without the build metadata.
This changes it so that if the metadata isn't provided, then it will be ignored when matching. Otherwise, it will be honored. This is slightly different from a version requirement like `=1.2.3+foo` which ignores the metadata completely.
This also adds a slightly better error message if you don't type in valid syntax for a version number (previously it would just emit the `no matching package` error).
Auto merge of #9866 - nipunn1313:pkg_in_repo2, r=ehuss
Support path_in_vcs as part of cargo_vcs_metadata
Depends on #9865 - this PR will look simpler once that one lands. I can't target my PR to the base branch of #9865 as an external contributor (since it's in my fork). For now just review the latest commit of this one.
This is a backward compatible change that is an alternative to #9837
projects / cargo.git / log