bors 963bfe4dd9 Auto merge of #8799 - ehuss:new-namespaced, r=alexcrichton
New namespaced features implementation.

This is a new implementation for namespaced features (#5565). See the `unstable.md` docs for a description of the new behavior. This is intended to fix several issues with the existing design, and to make it backwards compatible so that it does not require an opt-in flag.

This also includes tangentially-related changes to the new feature resolver. The changes are:

* `crate_name/feat_name` syntax will now always enable the feature `crate_name`, even if it is an inactive optional dependency (such as a dependency for another platform). The intent here is to have a certain amount of consistency whereby "features" are always activated, but individual crates will still not be activated.
* `--all-features` will now enable features for inactive optional dependencies. This is more consistent with `--features foo` enabling the `foo` feature, even when the `foo` dep is not activated.

I'm still very conflicted on how that should work, but I think it is better from a simplicity/consistency perspective. I still think it may be confusing if someone has a `cfg(some_dep)` in their code, and `some_dep` isn't built, it will error. The intent is that `cfg(accessible(some_dep))` will be the preferred method in the future, or using platform `cfg` expression like `cfg(windows)` to match whatever is in Cargo.toml.

Closes #8044
Closes #8046
Closes #8047
Closes #8316

## Questions
- For various reasons, I changed the way dependency conflict errors are collected. One slightly negative consequence is that it will raise an error for the first problem it detects (like a "missing feature"). Previously it would collect a list of all missing features and display all of them in the error message. Let me know if I should retain the old behavior. I think it will make the code more complicated and brittle, but it shouldn't be too hard (essentially `Requirements` will need to collect a list of errors, and then `resolve_features` would need to check if the list is non-empty, and then aggregate the errors).

- Should `cargo metadata` show the implicit features in the "features" table? Currently it does not, and I think that is probably best (it mirrors what is in `Cargo.toml`), but I could potentially see an argument to show how cargo sees the implicit features.
2020-10-27 19:58:34 +00:00
2020-10-17 11:47:18 -07:00
2020-10-25 12:51:27 -07:00
2019-11-11 10:35:40 +02:00
2020-10-09 10:18:53 -07:00
2020-09-18 14:01:51 -07:00
2019-01-30 15:34:37 -05:00
2019-01-30 15:34:37 -05:00
2020-07-16 15:21:51 -07:00
2020-09-18 14:01:51 -07:00
2020-03-31 11:15:46 -04:00

Cargo

Cargo downloads your Rust projects dependencies and compiles your project.

Learn more at https://doc.rust-lang.org/cargo/

Code Status

Build Status

Code documentation: https://docs.rs/cargo/

Installing Cargo

Cargo is distributed by default with Rust, so if you've got rustc installed locally you probably also have cargo installed locally.

Compiling from Source

Cargo requires the following tools and packages to build:

  • git
  • curl (on Unix)
  • pkg-config (on Unix, used to figure out the libssl headers/libraries)
  • OpenSSL headers (only for Unix, this is the libssl-dev package on ubuntu)
  • cargo and rustc

First, you'll want to check out this repository

git clone https://github.com/rust-lang/cargo
cd cargo

With cargo already installed, you can simply run:

cargo build --release

Adding new subcommands to Cargo

Cargo is designed to be extensible with new subcommands without having to modify Cargo itself. See the Wiki page for more details and a list of known community-developed subcommands.

Releases

Cargo releases coincide with Rust releases. High level release notes are available as part of Rust's release notes. Detailed release notes are available in this repo at CHANGELOG.md.

Reporting issues

Found a bug? We'd love to know about it!

Please report all issues on the GitHub issue tracker.

Contributing

See the Cargo Contributor Guide for a complete introduction to contributing to Cargo.

License

Cargo is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE and LICENSE-MIT for details.

Third party software

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/).

In binary form, this product includes software that is licensed under the terms of the GNU General Public License, version 2, with a linking exception, which can be obtained from the upstream repository.

See LICENSE-THIRD-PARTY for details.

Description
The Rust package manager
Readme 97 MiB
Languages
Rust 95.4%
Roff 4.2%
JavaScript 0.2%
Shell 0.1%