Strategy for backward-compatiblity:

When checking for the relevant Cargo directories, check in the following order of preference:

1. Use the environment variable CARGO_HOME.
2. Use the platform-specific directories if they exist.
3. Use the legacy location (~/.cargo) if it exists.
4. Fall back to the platform-specific directories if everything else fails.

The new platform-specific directories are as follows:

On Windows, use AppData\Local\Temp\Cargo for cache files (obtained via GetTempPath), AppData\Roaming\Cargo for the config files (FOLDERID_RoamingAppData) and AppData\Local\Programs\Cargo for installed binaries (FOLDERID_UserProgramFiles).

On Unixy systems, use the XDG spec: ~/.cache/cargo for cache files, ~/.config/cargo for config, ~/.local/bin for installed binaries.

http://standards.freedesktop.org/basedir-spec/basedir-spec-0.8.html http://www.freedesktop.org/software/systemd/man/file-hierarchy.html

On OS X, use ~/Library/Caches/Cargo for cache files, ~/Library/Cargo for config files and ~/Library/Cargo/bin for binary files.

Fixes #1734. Fixes #1976.

This change implements the HTTP registry API from rust-lang/rfcs#2789.

The client implementation supports the changelog extension in the RFC, but the server (that is, GitHub's static file serving of the registry) does not at the time of writing.

This implementation does not download multiple index files concurrently, since the Registry trait doesn't lend itself well to that at the moment.

This prevents target configs from accidentally being picked up when cross compiling from hosts that have the same architecture as their targets.

closes #3349

Tracking issue: #9096

Tasks

• [x] -Z unstable option called bindeps
• ✅ (config) allow parsing of newly introduced 'artifact' fields
  • [x] into TomlManifest
  • [x] into Manifest
    • [x] ~~abort~~ warn if artifacts are used on stable
• ✅ resolver : assure artifact dependencies are part of the resolution process and unified into the dependency tree
• 🔬compiler: make it understand 'artifact' dependencies and pass new environment variables to the crate being build
  • [x] lib=false should not be considered a rust library for the dependent, in unit and possibly resolve graph
  • [x] assure profile settings are applied correctly
  • [x] target overrides work
    • [x] target = "target" in build deps
    • [x] other targets on build deps
    • [x] other targets on non-build deps
    • [x] 'no-cross doc tests' seems like a constraint we should apply as well maybe
  • [x] more confidence with resolver = "2"
  • [x] assure artifact placement is correct (bin and various forms of lib)
• ✅ serialization: rewriting manifests (i.e. for publishing) does not discard artifact information
  • [x] publishing keeps artifact and lib values
• Other cargo subcommands
  • [x] cargo metadata
    • leave unchanged
  • [x] artifacts work with cargo check
  • [x] artifacts work with rustdoc, such that it doesn't document them unless lib=true
  • [x] cargo tree maybe?
  • [x] cargo clean should clean artifacts - even though it's more complex, ultimately it deletes the target directory.
  • [x] artifacts work with cargo test (and dev-dependencies)
    • [x] doctests
    • [x] try reproducible repository as well.
• 🧪 tests for more subtle RFC constraints
  • [x] build scripts cannot access artifact environment variables at compile time, only at runtime)
  • [x] assure 'examples' which also support crate-type fields like [[lib]] won't become artifacts themselves.
  • [x] assure --out-dir does not leak artifacts - tested manually, it seemed to niche to add a test.
  • [x] try target="foo" in artifact and assure it sees a decent error message
  • [x] Assure RFC 3176 doesn't work
• 🧹cleanup and finalization
  • [x] assure no TODO(ST) markers are left in code
  • [x] assure no tests are ignored
  • [x] use resolver = "1" once to assert everything also works with the previous resolver, but leave it on "2".

Implementation and review notes

• artifacts and unstable options are only checked when transforming them from TomlManifest to Manifest, discarding artifact information if the unstable flag is not set. Nowhere else in code will the CLI options be checked again.
• If no binaries are specified, all the binaries in the package will be built and made available. - this should only refer to [[bin]] targets, not examples for instance.
• artifact binaries won't be uplifted, hence won't be present outside of their output directory
• ❗️We don't know how package links will affect artifacts for build dependencies. Should probably be thought through.
• ❗️The location of artifacts is only tested roughly to avoid having to deal with different output names on the four platforms that seem to matter (gnu, macos, windows msvc, windows gnu).
• cargo tree doesn't handle artifacts specifically, and it might be interesting to make clear if an artifact is only an artifact, or both artifact and dependency.
• Most error and warning messages can probably be more cargo-matic.

Questions

• Does cargo without the feature enabled have to complain about the "artifact" field in a dependency, like it does right now? It doesn't look like machinery for that exists in do_read_manifest().
  • ✔️It warns now
• Should parsing of artifact values, like "bin" be case sensitive?
  • ✔️ It's case sensitive now, which should help with serde roundtripping.

Review Progress

• [x] address Josh's review notes one by one
  • [x] introduce IsArtifact (see this answer) (76cd48a2d62d74e043a1a482199c5bb920f50311)
  • [x] prefer uplifting artifact deps that were written into the deps directory, but prefer to do that in this PR instead
  • [x] add extra-tests as described in Josh's comment: " features get unified between a Rust library and a binary, and one that confirms features don't get unified between a Rust library and a binary for a different target?"
  • [x] Make target-based artifact splitting work by porting parts of RFC-3176
    • [x] test-support/cross-compile
    • [x] namespace separation
• [x] re-create RFC-3176 what's not in RFC-3028, namely multidep support and all related tests
• [x] Address Eh2406 's review comments
• [x] Address Eric's comments
  • [x] Unstable features need to be documented in unstable.md.
  • [x] sort out target_data
  • [x] figure out cargo metadata
  • [x] See if target-data can work without an index format update.
  • [x] truncate comments at 80-90 lines and remove unused methods, remove -Z unstable-options, use cfg!(target_env = "msvc")
  • [x] add missing doc comments to newly added methods and funtions
  • [x] simplify method parameters and inline some functions
  • [x] add test and extend test to show additional issues
• [x] assure current set of tests works consistently, also on windows

Sponsored by Profian

Cargo as well as cargo-edit have gone a long way since #4 was opened. It might now make sense to move (parts of) cargo-edit into cargo itself. Basically, we now have a format-preserving TOML library that -- at least for adding a dependency line -- work quite well (you can test this with cargo install cargo-edit --vers 0.3.0-beta.1 -f).

Speaking with @matklad, I believe I now have a somewhat solid understanding of what needs to happen to add a new built-in cargo subcommand. One important realization was that cargo-install already contains some of the parts we need.

Here are some steps to get started:

1. Create a src/bin/cargo/commands/add.rs (as duplicate of install.rs at first)
2. In src/bin/cargo/commands/mod.rs, add add to builtin/builtin_exec, and to the list of mods
3. Create a src/bin/cargo/ops/cargo_add.rs (as duplicate of cargo_install.rs at first)

One thing we should aim for though, is to now just copy-paste the whole of cargo-edit but to re-use as much of cargo's infrastructure as possible. For example, we should try to use cargo's way of querying the registry as well as its CLI args handling and output formatting. We can, for example, also use args.workspace.current_manifest to get the manifest and deal with workspace.

~~This is not finished - the big omission is no tests, and it needs some more testing too. It also requires https://github.com/rust-lang/rust/pull/37681.~~

However, this is my first non-trivial Cargo patch, so I'd like to get some early feedback.

r? @alexcrichton

and cc @rust-lang/tools since this adds a new Cargo sub-command (although we have previously discussed and approved the idea in a tools meeting).

Follow the same strategy as the compiler for now in basically every respect:

• Add new --release-channel configure option, defaulting to dev
• Remove old --enable-nightly
• Add --enable-build-openssl as an orthogonal option
• Hook up Travis/AppVeyor to stable/beta/master branches to do the right channel builds.

Most of the work was done by @dan-t in #1225 and by @winger in #1434

Fixes #2193

I failed to properly rebase previous attempts so I just salvaged this from bits and pieces.

@alexcrichton are you sure that the default format should be TOML? I think that TOML is more suitable for humans, and JSON is better (at the moment at least) for tools. Maybe we should default to ~~TOML~~ JSON?

cc rust-lang/rust#71249

This implements the Cargo side of 'Cargo report future-incompat'

Based on feedback from alexcrichton and est31, I'm implemented this a flag --future-compat-report on cargo check/build/rustc, rather than a separate cargo describe-future-incompatibilities command. This allows us to avoid writing additional information to disk (beyond the pre-existing recording of rustc command outputs).

This PR contains:

• Gating of all functionality behind -Z report-future-incompat. Without this flag, all user output is unchanged.
• Passing -Z emit-future-incompat-report to rustc when -Z report-future-incompat is enabled
• Parsing the rustc JSON future incompat report, and displaying it it a user-readable format.
• Emitting a warning at the end of a build if any crates had future-incompat reports
• A --future-incompat-report flag, which shows the full report for each affected crate.
• Tests for all of the above.

At the moment, we can use the array_into_iter to write a test. However, we might eventually get to a point where rustc is not currently emitting future-incompat reports for any lints. What would we want the cargo tests to do in this situation?

This functionality didn't require any significant internal changes to Cargo, with one exception: we now process captured command output for all units, not just ones where we want to display warnings. This may result in a slightly longer time to run cargo build/check/rustc from a full cache. since we do slightly more work for each upstream dependency. Doing this seems unavoidable with the current architecture, since we need to process captured command outputs to detect any future-incompat-report messages that were emitted.

Since building dependencies results in different libraries depending on the feature flags, I added the feature flags into the short_hash.

This solves an issue when multiple crates share a target directory or multiple targets share a common library with divergent feature flag choice.

I'm not sure if this architecturally the best way to solve this problem, but I did confirm that this fixes the issue I was seeing. I can also add a test for this case if this code is taking the right approach (or if it would help illustrate the issue).

I am using trying to use Cargo from behind a proxy, and it is unable to fetch external repositories despite having all the appropriate environment variables and configurations.

More specifically, I have the following environment variables set:

export HTTP_PROXY=proxy.example.com:8000
export HTTPS_PROXY=proxy.example.com:8000
export FTP_PROXY=proxy.example.com:8000

along with their lowercase counterparts. Git and Cargo both have in their configuration:

[http]
proxy = proxy.example.com:8000

[https]
proxy = proxy.example.com:8000

and git from the command line works fine; however, when Cargo attempts to fetch a repository, I encounter

$ cargo build
    Updating git repository `https://github.com/pistondevelopers/piston`
Unable to update https://github.com/pistondevelopers/piston

Caused by:
  failed to fetch into /home/user/.cargo/git/db/piston-10111ca7958cf505

Caused by:
  [2] Failed to connect to github.com: No route to host

yet if I run git on its own, it works fine:

$ git clone https://github.com/pistondevelopers/piston
Cloning into 'piston'...
remote: Counting objects: 1959, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 1959 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1959/1959), 2.19 MiB | 575 KiB/s, done.
Resolving deltas: 100% (1252/1252), done.

What does this PR try to resolve?

Cargo team discussed this in the triage meeting and agree that it has been long enough to write to .cargo/credentials.toml by default.

Fixes #11509.

cc rust-lang/crates.io#5730 rust-lang/crates.io#5732

How should we test and review this PR?

Integration tests included.

Additional information

We also talked about theoretically dropping the support of the old credentials for any new features. That might “force” people to migrate, though doing that has low benefits.

Problem

When a relatively medium/large project migrates to clippy, there might be a large number of lint diagnostics. It can be difficult to get a clear picture of the category with the most problems.

@dclong raised an issue here describing this feature request in the clippy github repo.

Proposed Solution

It would help if running cargo clippy automatically shows counts of lints whenever a large number of diagnostics (> 10) are generated. For example, cargo clippy should show something like

`my_project` (bin "my_project") generated 28 warnings

Summary of diagnostics:
clippy::collapsible_if: 16
clippy::collapsible_else_if: 4
clippy::approx_constant: 3
dead_code: 3
clippy::single_match: 1
clippy::new_without_default: 1

Although the default behavior is to show this summary whenever the total amount of diagnostics is greater than 10, we should also allow users to override whether the summary is shown by running cargo clippy --summary or cargo clippy --no-summary.

Notes

Note that the summary includes both warnings generated from clippy and rustc.

Problem

I would like to utilize alternate fonts with cargo doc. I specifically seek the ability to utilize monospace fonts.

Proposed Solution

Allow the user to configure cargo doc via the command line and/or configuration file.

Notes

No response

Problem

(Possible alternative title: Cargo Test does not run examples as tests when commanded)

(Relevant confusion in reddit thread here)

When read literally, line 140 of Cargo Test docs states that Cargo can reinterpret the main function of an example binary as a test, and execute it.

Since cargo does not appear to do this, a wording that does not have the misleading reading might be appropriate here.

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

No response

Problem

I'm writing a kernel and I want to split out x86 and x86_64 specific code, so I can publish it to crates.io and possible use it in another project. Best way I can think to do this is through workspaces. However, when compiling my kernel, I don't want to compile the x86 crate, when, for example, building for aarch64 or RISC-V. I'm currently doing something like the below:

// src/lib.rs

#![no_std]
#[cfg(target_arch = "x86")]
mod x86;
#[cfg(target_arch = "x86")]
pub use x86::*;

This obviously isn't optimal. Similar to #5220?

Proposed Solution

I would propose something like below:

[workspace]
members = [
    "<kernel_name>",
]

[workspace.'cfg(feature = "x86")']
members = [
    "<x86 crate>"
]

or

[workspace]
members = [
    "<kernel_name>",
    "feature.x86:<x86 crate>"
]

or something to that affect.

Notes

No response (yet, haha!)

This is an alternative solution to #10159, because #11312 is stuck in review for a long time due to open questions about some implementation details and a concern about #11461.

• 02557c3c5256ebecf2cbce252951096ab8a132cf enables a behavior that was basically already meant to be there, and it helps the rest of the changes.

• 69cacfa7513687e0a2519cecadcceea1f8634898 is the main part.

• 2c2c6d658ab5fa2436264dd0df00da6a1510b25f makes error messages even nicer. This may be a bit controversial, because it parses output assuming a particular text format of Rust panics. I think it's pretty safe to do this, but I'd be ok landing the rest of the changes without this one.