bors [Mon, 25 Jan 2021 16:16:43 +0000 (16:16 +0000)]
Auto merge of #9097 - ehuss:tracking-issue-template-update, r=alexcrichton
Minor update to tracking issue template.
Just some minor tweaks, move the "about" to the bottom since it isn't that important (I think the summary should be first). Also add a link to an RFC if it is an RFC.
bors [Thu, 21 Jan 2021 21:04:12 +0000 (21:04 +0000)]
Auto merge of #9092 - ehuss:unstable-updates, r=alexcrichton
Unstable updates
This is a collection of updates for unstable/nightly feature support, intended to provide better messages for users and better internal and external documentation. Separated by commit, in summary:
* Added comments and new docstrings for improved internal documentation.
* Added new documentation to the reference guide on how unstable things work.
* Also added redirects for stabilized features so any external links won't be broken.
* Add a targeted error message if you put `cargo-features` in the wrong place in `Cargo.toml`.
* Remove `publish-lockfile`. The feature was stabilized without the key in #7026 about 1.5 years ago. Also added "removed" support for features, which prints out a more helpful error message.
* Add help messages about stabilized `-Z` flags (instead of spitting out an unhelpful error message).
* Add help messages about stabilized `cargo-features` features.
* Add more context to the error when using `cargo-features` on stable.
* Unhide nightly CLI flags. I changed my mind on how these should work. I think it is useful to "advertise" the existence of these options on stable. The error message if you try to use it should help guide on what to do.
Eric Huss [Thu, 21 Jan 2021 03:46:50 +0000 (19:46 -0800)]
Add more helpful message with stabilized -Z flags.
Previously, when something was stabilized, Cargo would spit out a very
unhelpful error message about an unknown -Z flag. This changes it so
that it displays a helpful warning (or error).
Eric Huss [Thu, 21 Jan 2021 03:16:54 +0000 (19:16 -0800)]
Unhide nightly-only flags.
I changed my mind on how these should work. I think it is useful to
"advertise" the existence of these options on stable. The error message
if you try to use it should help guide on what to do.
bors [Wed, 20 Jan 2021 19:02:26 +0000 (19:02 +0000)]
Auto merge of #9077 - ehuss:fix-doc-resolver2-proc-macro, r=alexcrichton
Fix some issues with `cargo doc` and the new feature resolver.
This contains two related commits fixing some issues with `cargo doc` and the new feature resolver.
The first commit fixes a panic. The old code was using `UnitFor::new_normal` when computing doc units, but this was wrong. That essentially circumvents the new feature resolver, and breaks determining the correct features to use. I don't remember exactly what I was thinking when I wrote that, other than "rustdoc shouldn't care", but it does matter.
Unfortunately changing that makes collisions worse because it aggravates #6313, so the second commit adds some logic for removing some collisions automatically. Specifically:
- Prefers dependencies for the target over dependencies for the host (such as proc-macros).
- Prefers the "newest" version if it comes from the same source.
There are still plenty of situations where there can be collisions, but I'm uncertain on the best way to handle those.
bors [Wed, 20 Jan 2021 16:12:56 +0000 (16:12 +0000)]
Auto merge of #8037 - djc:rfc-2495, r=ehuss
Implement support for rust-version field in project metadata
Needs a bunch more work, but I'd like some early feedback! Remaining work:
- [x] Bikeshedding name (picked `rust-version` here over `msrv` or `min-rust-version`)
- [x] Failing test for local dependency with unsatisfied MSRV
- [x] Requirement cannot be smaller than 1.27
- [x] Requirement cannot be smaller than initial release of edition used
- [x] Check for `run`, `verify` and `publish` subcommands
- [x] More tests (would love feedback on this)
- [x] Handle pre-release identifiers
- [x] Disallow semver range operators
- [x] Feature gate it
- [x] Add documentation for unstable feature
Minimal version of `@moxian's` earlier take in #7801.
bors [Mon, 18 Jan 2021 19:51:07 +0000 (19:51 +0000)]
Auto merge of #9075 - alexcrichton:fix-cycles, r=ehuss
Fix a bug in Cargo's cyclic dep graph detection
Cargo's cyclic dependency graph detection turns out to have had a bug
for quite a long time as surfaced by #9073. The bug in Cargo has to do
with how dev-dependencies are handled. Cycles are "allowed" through
dev-dependencies because the dev-dependency can depend on the original
crate. Our cyclic graph detection, however, was too eagerly flagging a
package as known to not have a cycle before we had processed everything
about it.
The fix here was basically to just simplify the graph traversal. Instead
of traversing the raw `Resolve` this instead creates an alternate
in-memory graph which has the actual edges we care about for cycle
detection (e.g. every edge that wasn't induced via a dev-dependency).
With this simplified graph we then apply the exact same algorithm, but
this time it should be less buggy because we're not trying to do funky
things about switching sets about what's visited halfway through a
traversal.
Eric Huss [Thu, 14 Jan 2021 21:12:24 +0000 (13:12 -0800)]
Remove some doc collisions.
There are some cases where `cargo doc` will try to document two things
with the same crate_name. This attempts to automatically remove some of
those duplicates based on some rules:
- Prefers dependencies for the target over dependencies for the host
(such as proc-macros).
- Prefers the "newest" version if it comes from the same source.
There are still plenty of situations where there can be collisions, but
I'm uncertain on the best way to handle those.
Alex Crichton [Thu, 14 Jan 2021 16:40:12 +0000 (08:40 -0800)]
Fix a bug in Cargo's cyclic dep graph detection
Cargo's cyclic dependency graph detection turns out to have had a bug
for quite a long time as surfaced by #9073. The bug in Cargo has to do
with how dev-dependencies are handled. Cycles are "allowed" through
dev-dependencies because the dev-dependency can depend on the original
crate. Our cyclic graph detection, however, was too eagerly flagging a
package as known to not have a cycle before we had processed everything
about it.
The fix here was basically to just simplify the graph traversal. Instead
of traversing the raw `Resolve` this instead creates an alternate
in-memory graph which has the actual edges we care about for cycle
detection (e.g. every edge that wasn't induced via a dev-dependency).
With this simplified graph we then apply the exact same algorithm, but
this time it should be less buggy because we're not trying to do funky
things about switching sets about what's visited halfway through a
traversal.
bors [Tue, 12 Jan 2021 23:45:39 +0000 (23:45 +0000)]
Auto merge of #9066 - rubenrua:hotfix_sort_bins, r=ehuss
Sort available binaries when multiple
From:
```
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: basic-tutorial-13, basic-tutorial-6, basic-tutorial-1, basic-tutorial-4, basic-tutorial-9, basic-tutorial-2, basic-tutorial-3, basic-tutorial-5, basic-tutorial-12, playback-tutorial-4, basic-tutorial-8, basic-tutorial-7
```
To:
```
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: basic-tutorial-1, basic-tutorial-12, basic-tutorial-13, basic-tutorial-2, basic-tutorial-3, basic-tutorial-4, basic-tutorial-5, basic-tutorial-6, basic-tutorial-7, basic-tutorial-8, basic-tutorial-9, playback-tutorial-4
```
bors [Tue, 12 Jan 2021 17:14:29 +0000 (17:14 +0000)]
Auto merge of #9065 - alexcrichton:fix-build-bug-again, r=ehuss
Fix `links` vars showing up for testing packages
If a package is tested and the library for the package wasn't built
(e.g. only tested or it wasn't present) then the `links` env vars from
dependencies weren't showing up to the build script by accident. This
was an accidental regression from #8969.
The intention of #8969 was to exclude connections to build scripts
connected via dev-dependencies, but it only applied a heuristic because
the unit graph doesn't retain information about dev-dependencies. The
fix here is to instead actually retain information about
dev-dependencies which is only used for constructing the unit graph and
connecting build script executions to one another.
Alex Crichton [Mon, 11 Jan 2021 18:42:38 +0000 (10:42 -0800)]
Fix `links` vars showing up for testing packages
If a package is tested and the library for the package wasn't built
(e.g. only tested or it wasn't present) then the `links` env vars from
dependencies weren't showing up to the build script by accident. This
was an accidental regression from #8969.
The intention of #8969 was to exclude connections to build scripts
connected via dev-dependencies, but it only applied a heuristic because
the unit graph doesn't retain information about dev-dependencies. The
fix here is to instead actually retain information about
dev-dependencies which is only used for constructing the unit graph and
connecting build script executions to one another.
rubenrua [Tue, 12 Jan 2021 07:46:25 +0000 (08:46 +0100)]
Sort available binaries when multiple
From:
```
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: basic-tutorial-13, basic-tutorial-6, basic-tutorial-1, basic-tutorial-4, basic-tutorial-9, basic-tutorial-2, basic-tutorial-3, basic-tutorial-5, basic-tutorial-12, playback-tutorial-4, basic-tutorial-8, basic-tutorial-7
```
To:
```
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: basic-tutorial-1, basic-tutorial-12, basic-tutorial-13, basic-tutorial-2, basic-tutorial-3, basic-tutorial-4, basic-tutorial-5, basic-tutorial-6, basic-tutorial-7, basic-tutorial-8, basic-tutorial-9, playback-tutorial-4
```
bors [Mon, 11 Jan 2021 15:12:09 +0000 (15:12 +0000)]
Auto merge of #9059 - ehuss:fix-unit-for-host, r=alexcrichton
Fix unit_for computation on proc-macros in shared workspace.
There was a bug where the UnitFor was not being computed properly for proc-macros in a workspace with shared dependencies, integration tests, and a mixture of various flags (`--workspace --all-targets --all-features`). The issue is that [this line](https://github.com/rust-lang/cargo/blob/faf05ac316cd71100a691799cd8da02fce6dd85d/src/cargo/core/compiler/unit_dependencies.rs#L474), which is used when attaching the implicit dependency from an integration test to its library, was using the wrong unit_for value (it was not checking if the implicit lib is a proc-macro). The consequence is that the graph could be built inconsistently, causing features to be randomly selected incorrectly if the integration test happened to be the first unit processed.
The solution here is to use a common function for transitioning the unit_for value. The with_for_host/with_host_features split was mostly a consequence of how things evolved over time, and keeping them separate wasn't really necessary.
bors [Sun, 10 Jan 2021 20:25:54 +0000 (20:25 +0000)]
Auto merge of #9000 - JohnTitor:owner-add-docs, r=ehuss
Document `could not find the github team` error on `cargo owner --add`
When running `cargo owner --add`, the `could not find the github team` error often occurs due to lack of the permissions.
Example cases: https://github.com/rust-lang/cargo/issues/5297#issuecomment-653709183, https://github.com/rust-lang/crates.io/issues/2928
I think it's worth documenting that error and the possible solution.
bors [Fri, 8 Jan 2021 16:44:12 +0000 (16:44 +0000)]
Auto merge of #9053 - sharnoff:master, r=alexcrichton
[doc] add note about empty environment variables for missing manifest keys
This is a small addition to the cargo book.
In [the section](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates) about the environment variables cargo sets to provide information about a crate, there's no mention about the value of those environment variables is if the key isn't present in the manifest.
As can be seen [here](https://github.com/rust-lang/cargo/blob/94e21ada550f91f5d32f2f51635792a79aeb8d63/src/cargo/core/compiler/compilation.rs#L287)¹, the values default to the empty string (instead of, say, not being present), so this change just adds a sentence in the book to clarify that.
If the terminology could be improved or there's a better place for this to be included, I'm happy to change it :)
---
¹ To be clear, I did also play around with this and found that the environment variables were empty. The code reference was more to double-check that the behavior I saw was a consistent pattern.
bors [Tue, 5 Jan 2021 21:39:20 +0000 (21:39 +0000)]
Auto merge of #8997 - ehuss:stabilize-features, r=alexcrichton
Stabilize -Zfeatures and -Zpackage-features.
This follows through with [RFC 2957](https://github.com/rust-lang/rfcs/pull/2957) to stabilize the new feature resolver, and `-Zpackage-features` command-line changes.
This also rewrites the "Features" chapter to try to expand it a little.
I decided to leave the `-Zfeatures` flag in for now for testing, but it can be removed at a later date.
There is a code change related to the `package-name/feature-name` syntax for the `--features` flag. I wanted to stabilize that for `resolver = "1"`, but I previously neglected to separate that behavior out, so it required change to `Workspace::members_with_features` to make that work (see the `resolver1_member_features` test).
bors [Mon, 4 Jan 2021 17:44:14 +0000 (17:44 +0000)]
Auto merge of #8986 - ehuss:fix-git-http-proxy, r=alexcrichton
Fix git http.proxy config setting.
The `http.proxy` setting in `~/.gitconfig` was never being used. This is because the `get_str` method of `git2::Config` requires a "snapshot" config. Otherwise, it aways returns an error of "get_string called on a live config object".
I'm not 100% positive it makes sense to fix this, since I'm uncertain this might introduce problems for people, but it seems to be the intent here.
This PR updates that parameter name and also clarifies in the help text that `--aggressive` and `--precise` make sense when used with `-p`, which specifies `SPEC`.
bors [Mon, 4 Jan 2021 16:01:13 +0000 (16:01 +0000)]
Auto merge of #9037 - Swatinem:test-cwd, r=alexcrichton
Assert that tests are run in the crate directory
To avoid regressions to the test runtime directory, this asserts that
all test types (unit, integration, doctest) are executed in the crate
(manifest) directory, no matter where that crate is in relation to the
workspace root.
Arpad Borsos [Sat, 2 Jan 2021 13:34:21 +0000 (14:34 +0100)]
Assert that tests are run in the crate directory
To avoid regressions to the test runtime directory, this asserts that
all test types (unit, integration, doctest) are executed in the crate
(manifest) directory, no matter where that crate is in relation to the
workspace root.
Clarify the help text of `--aggressive` and `--precise` of `cargo update`
This commit makes following 2 changes:
- Replace a parameter "<name>" with "SPEC". The former is an older name
of the latter before 0d2a2434f6f49cd671bd06e8cfc9f88bbbc67ff8.
- Document that both options make sense when used with `-p`, which
specifies SPEC.
bors [Mon, 21 Dec 2020 19:37:30 +0000 (19:37 +0000)]
Auto merge of #8976 - ebroto:rustc_workspace_wrapper, r=ehuss
Stabilize RUSTC_WORKSPACE_WRAPPER
Stabilizing this environment variable would allow Clippy to fix a long-standing usability problem, [clippy#4612](https://github.com/rust-lang/rust-clippy/issues/4612).
It's also the last step towards stabilizing the `--fix` command-line argument in Clippy, that allows applying suggestions automatically when the lint supports it.
Eric Huss [Mon, 21 Dec 2020 19:02:46 +0000 (11:02 -0800)]
Rearrange and try to clarify resolver 2 docs.
* Avoid terms like "new", "previously", and "now".
* Add link for `resolver` field in manifest.md.
* Move the resolver version specification to the resolver chapter.
* Break up the version 2 section in features.md into subsections.
* Try to clarify some of the wording, and make it clearer when talking
about resolver versions.
* Rewrite the section on version 2 command-line flags to hopefully be
clearer.