bors [Wed, 16 Jun 2021 14:51:06 +0000 (14:51 +0000)]
Auto merge of #9588 - ehuss:edition2021-force-warns, r=alexcrichton
Enable support for fix --edition for 2021.
This adds support for using `cargo fix --edition` to migrate to 2021.
This also uses the new, currently unstable, `--force-warns` flag. This was added because there were a significant number of crates that were "allow"ing lints that are required for migrating the edition. This wasn't a problem for 2018, because its lints were new, and all "allow" to start. For 2021, several older "warn" lints are becoming hard errors. "allow"ing them would cause the migration to fail.
bors [Sat, 12 Jun 2021 18:00:01 +0000 (18:00 +0000)]
Auto merge of #9577 - ehuss:json-test, r=alexcrichton
Fix package_default_run test.
The `package_default_run` test was checking the output of `cargo metadata`, which included the "targets" field. Unfortunately the order of the targets in this test depend on the filesystem order, so the test may randomly fail.
The fix here is to just check for the one field that this test was interested in.
An alternate solution would be to sort the targets. Another alternate solution would be to use `"{...}"` for the targets to ignore them. I kinda liked simplifying it to check just one field.
This includes a series of commits that are just general changes to the test infrastructure:
* Change cargo-test-support to use anyhow.
* Remove unused `ErrMsg`.
* Fix a bug with `verify_checks_output`.
* Remove the weird Debug impl for Execs.
* Added a helper function for getting the JSON output from cargo. (I can imagine a lot of possible enhancements here.)
Eric Huss [Fri, 11 Jun 2021 23:08:20 +0000 (16:08 -0700)]
Fix `package_default_run`.
The output was checking the `targets`, whose order depends on the
filesystem order. Instead of checking all the output, just
check the one field this test is for.
Eric Huss [Fri, 11 Jun 2021 20:12:30 +0000 (13:12 -0700)]
Fix verify_checks_output.
This was accidentally broken in
https://github.com/rust-lang/cargo/commit/cc5e9df64a7ed6b3657e9dd790e2e34387d33df5
causing it to not check in the error case (which is the only case that mattered).
bors [Fri, 11 Jun 2021 00:00:14 +0000 (00:00 +0000)]
Auto merge of #9571 - sunjay:fix_deny_warnings_but_not_others, r=alexcrichton
Change how the fix_deny_warnings_but_not_others test works
This changes how the `fix_deny_warnings_but_not_others` test works to avoid breakage from a new compiler suggestion that affects rustfix. It should still test the same thing, but through a slightly different mechanism to avoid breaking when new compiler suggestion are added.
Relevant PR for rust-lang/rust: https://github.com/rust-lang/rust/pull/83004
Full explanation in this comment: https://github.com/rust-lang/rust/pull/83004#issuecomment-859155118
Please let me know if you have a better suggestion for this fix. I believe [we're trying to land this ASAP because the beta is being cut tomorrow](https://github.com/rust-lang/rust/pull/83004#issuecomment-858481702), so I will try to get back to any feedback as soon as possible.
bors [Thu, 10 Jun 2021 16:12:42 +0000 (16:12 +0000)]
Auto merge of #9565 - KubaP:doc-fix, r=ehuss
Add mising documentation regarding `cargo doc`
It seems that the `--document-private-items` flag for `cargo doc` is automatically set when documenting a binary target. This change mentions that in the doc page.
The documentation did not mention this before, and it got me confused whilst I was trying to track down something going wrong.
bors [Thu, 10 Jun 2021 14:15:18 +0000 (14:15 +0000)]
Auto merge of #9566 - ehuss:relative-rustc-path, r=alexcrichton
Fix rustc/rustdoc config values to be config-relative.
The `rustc`, `rustdoc`, `rustc_wrapper`, and `rustc_workspace_wrapper` config values (in the `[build]` table) were being interpreted literally. This caused a problem if you used a relative path like `foo/rustc`. This would be interpreted as a relative path from whatever cwd cargo launches rustc from, which changes for different scenarios, making it essentially unusuable (since crates.io dependencies wouldn't be buildable).
Additionally, due to https://github.com/rust-lang/rust/issues/37868, it is a bad idea to use relative paths.
This changes it so that those paths are config-relative. Bare names (like "my-rustc-program") still use PATH as before.
This also includes a commit to centralize the rustc-wrapper program used by several tests so that it isn't built multiple times (and to allow several tests to work on windows).
bors [Thu, 10 Jun 2021 02:55:53 +0000 (02:55 +0000)]
Auto merge of #9567 - ehuss:new-rustfix, r=alexcrichton
Update rustfix.
This updates rustfix to 0.6.0. There are a few changes since 0.5.0, the following are noticeable changes:
* https://github.com/rust-lang/rustfix/pull/185 — Fix some panics in edge cases.
* https://github.com/rust-lang/rustfix/pull/195 — Revert revert multiple suggestions fix
The important one is https://github.com/rust-lang/rustfix/pull/195 which is necessary to handle some 2021 edition migration support. I have added a test to check that it works correctly.
bors [Wed, 9 Jun 2021 18:00:26 +0000 (18:00 +0000)]
Auto merge of #9549 - Bryysen:master, r=ehuss
Warn if an "all" target is specified, but we don't match anything
If a combination of --bins, --benches, --examples, --tests flags have
been specified, but we didn't match on anything after resolving the unit-list,
we emit a warning to make it clear that cargo didn't do anything and that the
code is unchecked.
This is my first PR and there are a couple things that I'm unsure about
* The integration test covers only one case (ideally it should cover every combination of the above mentioned flags the user can pass). I figured since the warning function is so simple, it'd best not to clog the testsuite with unnecessary `p.cargo().runs()` and whatnot. If I should make the test more comprehensive I can do that, it's also very easy to write unit tests so i can do that as well if needed.
* I figure we don't actually have to check the `--all-targets`, but i'm doing so for consistency. I also didn't check for the `--lib` flag at all because (I'm assuming) if the user passes `--lib` and there are no libraries, we error.
Edit: I notice (among other things) we sometimes silently skip certain units that have incompatible feature flags (see [here](https://github.com/rust-lang/cargo/blob/ed0c8c6d66e36fafbce4f78907a110838797ae39/src/cargo/ops/cargo_compile.rs#L1140)) so maybe we should be checking the `--lib` flag after all, in the event that a library was silently skipped and we no-opped :thinking:
And thanks to `@ehuss` for taking the time to answer my questions and helping me through the contribution process, much appreciated
Bryysen [Sun, 6 Jun 2021 23:36:36 +0000 (01:36 +0200)]
Warn if an "all" target is specified, but we don't match anything
If a combination of --bins, --benches, --examples, --tests flags have
been specified, but we didn't match on anything after resolving the unit-list,
we emit a warning to make it clear that cargo didn't do anything and that the
code is unchecked.
bors [Wed, 9 Jun 2021 00:28:53 +0000 (00:28 +0000)]
Auto merge of #9520 - weihanglo:tree-prune, r=ehuss
Add `--prune` option for cargo-tree
Part of #8105
Prune the given package from the display of the dependency tree. Also providing a nice suggestion if the package is not within the resolved dependency graph.
bors [Sat, 5 Jun 2021 17:21:05 +0000 (17:21 +0000)]
Auto merge of #9515 - pickfire:patch-1, r=ehuss
Add additional test for CJK progress width
Not clear if CJK test hit boundary, since CJK characters have double width,
if we show an example with an extra single width means one of them hit
character boundary to be able to test ellipsis handling.
bors [Fri, 4 Jun 2021 16:29:57 +0000 (16:29 +0000)]
Auto merge of #9544 - dtolnay-contrib:semverx, r=alexcrichton
Pull in semver 1.0.3 'x' fix
As requested in https://github.com/rust-lang/rust/pull/85983#issuecomment-854682640 -- a Cargo.toml update to ensure Cargo-the-library users always get https://github.com/dtolnay/semver/pull/247. Fixes https://github.com/rust-lang/cargo/issues/9543.
Ivan Tham [Thu, 27 May 2021 17:19:22 +0000 (01:19 +0800)]
Add additional test for CJK progress width
Not clear if CJK test hit boundary, since CJK characters have double width,
if we show an example with an extra single width means one of them hit
character boundary to be able to test ellipsis handling.
bors [Tue, 1 Jun 2021 17:26:35 +0000 (17:26 +0000)]
Auto merge of #9523 - ehuss:link-args-validate, r=alexcrichton
Add some validation to rustc-link-arg
This adds some validation, so that if a `cargo:rustc-link-arg-*` build script instruction specifies a target that doesn't exist, it will generate an error. This also changes a parse warning to an error if the `=` is missing from BIN=ARG.
I intentionally did not bother to add the validation to config overrides, as it is a bit trickier to do, and that feature is very rarely used (AFAIK), and I'm uncertain if rustc-link-arg is really useful in that context.
bors [Tue, 1 Jun 2021 14:35:20 +0000 (14:35 +0000)]
Auto merge of #9524 - ehuss:rustflags-compatibility, r=alexcrichton
Add a note about rustflags compatibility.
Over time, Cargo occasionally starts issuing new flags that may conflict with flags the user is passing directly to the compiler. Some recent examples are `-C embed-bitcode` (which broke anyone passing `-Clto` manually), and `-C prefer-dynamic` (which is kind of a mess). Future conflicts might be things like `--remap-path-prefix` or `--extern-html-root-url` (for rustdoc). This adds a note to mention these potential conflicts.
Although we try to maintain backwards compatibility as much as possible throughout all of Cargo, this particular area I think is dangerous enough that it is prudent to have some kind of warning somewhere. It is very rare that conflicts arise in practice, but they can happen.
I also added a note about passing in flags that Cargo itself issues, which can cause problems. Closes #9358.
bors [Tue, 1 Jun 2021 14:12:14 +0000 (14:12 +0000)]
Auto merge of #9526 - ehuss:doc-collision-resolve, r=alexcrichton
Consolidate doc collision detection.
This removes the separate collision detection pass (in cargo_doc.rs) and uses the global collision detection instead. This removes the separate pass for running the resolver (which resulted in running the resolver four times every time `cargo doc` was run).
The `--open` option needs to know which path to open, so this is passed in a roundabout way via `Compilation`. Since this method uses the root units, I added a sort on the roots so that the crate that is opened is consistent between runs. This results in some slight behavioral changes.
This also makes the collision check slightly more stringent. The test `doc_multiple_targets_same_name` now generates an error instead of a warning because the old code did not check for collisions between libs and bins across packages (which should be very rare).
bors [Fri, 28 May 2021 14:55:26 +0000 (14:55 +0000)]
Auto merge of #9488 - weihanglo:issue-9165, r=ehuss
`cargo tree -e no-proc-macro` to hide procedural macro dependencies
Probably resolves #9165
`cargo tree -e no-proc-macro` now hides procedural macro dependencies.
Note that when passed with `--invert <spec>`, the spec's reverse proc-macro dependencies are also hidden. Is this desired result?
Also, since I want `-p <spec>` and `-i <spec>` works with any valid package-id in the project, the filter logic is written in print stage instead of graph build stage
bors [Thu, 27 May 2021 22:34:28 +0000 (22:34 +0000)]
Auto merge of #9508 - dtolnay-contrib:semver, r=ehuss
Update to semver 1.0.0
I am working on a 1.0.0 of the `semver` crate some time this week. It would be good to confirm Cargo will be able to use it, beforehand!
It's a from-scratch rewrite, but https://github.com/dtolnay/semver/issues/237 has code to compare against 0.10.0 (currently used by Cargo) how every possible version requirement currently published to crates.io matches against every possible crate version. The differences are all broken syntax like `^0-.11.0` previously parsing with ".11.0" as a pre-release string (which is invalid, because pre-release are not allowed to contain empty dot-separated identifiers) and `~2.0-2.2` previously parsing with "2.2" as a pre-release string, when the user almost certainly meant `>=2.0, <=2.2`. I'm not sure how much of those you want to add code into Cargo to preserve behavior, but I would be happy to do it.
bors [Mon, 24 May 2021 16:17:27 +0000 (16:17 +0000)]
Auto merge of #9486 - Dirbaio:link-arg-bin, r=ehuss
Add `cargo:rustc-link-arg-bin` flag.
This PR implements a `cargo:rustc-link-arg-bin` command to specify per-binary link args from build scripts. This follows the suggestion from the tracking issue #9426.
Syntax is `cargo:rustc-link-arg-bin=BIN_NAME=ARG`
This was previously possible to do using the `#[link_args=".."]` attribute, but it was removed in rust-lang/rust#83820 in favor of the Cargo extra-link-args feature, which can currently not specify different link args for different bins in the same crate. This PR adds back the ability to do that.
bors [Mon, 24 May 2021 15:54:16 +0000 (15:54 +0000)]
Auto merge of #9473 - lf-:meow, r=ehuss
Add a cargo-doc.browser config option
The idea of this option is to allow cargo to use a separate browser from
the rest of the system. My motivation in doing this is that I want to
write a script that adds a symbolic link in some web root on my system
such that I can access my docs via the http protocol to avoid the
limitations of the file protocol that are accessibility problems for me.
For instance, zoom is not retained across multiple pages and Stylus
filters don't work well.