New semantics for --features flag
#5353
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Historically, feature-related flags like `--all-features`, `--no-default-features` and `--features` operated on the *current* package. That is, `cargo --package foo --feature feat` would activate `feat` for the package at the current working directory, and not for the `foo` package. `-Z package-features` flag implements the more obvious semantics for this combination of flags. This changes behavior, and that is why we want to start with an unstable opt-in. The changes are: * `--feature` flag affects the selected package. It is an error to specify `--feature` with more than a single `-p`, or with `-p` outside workspace (the latter could work in theory, but would be hard to implement). * `--all-features` and `--no-default-features` affect all selected packages, and not the one at cwd. * The package in `cwd` is not implicitly enabled when doing feature selection. That is, `cargo build -Z package-features -p foo` could select *less* features for various packages than `cargo build -p foo`.
|
@bors: r+ Nice! |
|
📌 Commit 8d0b31b has been approved by |
bors
added a commit
that referenced
this pull request
Apr 13, 2018
New semantics for `--features` flag Historically, feature-related flags like `--all-features`, `--no-default-features` and `--features` operated on the *current* package. That is, `cargo --package foo --feature feat` would activate `feat` for the package at the current working directory, and not for the `foo` package. `-Z package-features` flag implements the more obvious semantics for this combination of flags. This changes behavior, and that is why we want to start with an unstable opt-in. The changes are: * `--feature` flag affects the selected package. It is an error to specify `--feature` with more than a single `-p`, or with `-p` outside workspace (the latter could work in theory, but would be hard to implement). * `--all-features` and `--no-default-features` affect all selected packages, and not the one at cwd. * The package in `cwd` is not implicitly enabled when doing feature selection. That is, `cargo build -Z package-features -p foo` could select *less* features for various packages than `cargo build -p foo`. r? @alexcrichton
|
☀️ Test successful - status-appveyor, status-travis |
matklad
added a commit
to matklad/rust
that referenced
this pull request
Apr 13, 2018
This includes rust-lang/cargo#5353, which we might want to test via opt-in in the wild
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Apr 14, 2018
Update Cargo This includes rust-lang/cargo#5353, which we want to test via opt-in in the wild. This'll break RLS, the fix is rust-lang/rls#822
This was referenced Apr 16, 2018
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this pull request
May 21, 2018
This fixes an accidental regression introduced in rust-lang#5012 where the `--all-features` CLI flag was only propagated to the "main crate" as opposed to all workspace packages. This behavior has [already been deemed][pr] as "basically not what you want", but for now it's best to avoid the regression. Closes rust-lang#5518 [pr]: rust-lang#5353
bors
added a commit
that referenced
this pull request
May 24, 2018
Copy `--all-features` request to all workspace members This fixes an accidental regression introduced in #5012 where the `--all-features` CLI flag was only propagated to the "main crate" as opposed to all workspace packages. This behavior has [already been deemed][pr] as "basically not what you want", but for now it's best to avoid the regression. Closes #5518 [pr]: #5353
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this pull request
May 24, 2018
This fixes an accidental regression introduced in rust-lang#5012 where the `--all-features` CLI flag was only propagated to the "main crate" as opposed to all workspace packages. This behavior has [already been deemed][pr] as "basically not what you want", but for now it's best to avoid the regression. Closes rust-lang#5518 [pr]: rust-lang#5353
wking
added a commit
to wking/openshift-release
that referenced
this pull request
Jan 31, 2020
…Check Cargo.lock, etc. Require Cargo.lock to be fresh when we build. Not sure if there's a way to run this to only bump when required, but we generally want to trust our dependencies to correctly SemVer and track their upstream bugfixes, so I'm not too concerned about this failing after a dependency releases a new patch version or whatever. We don't need &&-chaining or anything, because this eventually gets called with errexit. For example, [1]: --> RUN ["/bin/bash","-c","set -o errexit; umask 0002; echo \"Checking Cargo.lock\" \u0026\u0026\ncargo generate-lockfile \u0026\u0026\ngit diff --exit-code \u0026\u0026\necho \"Building release binaries\" \u0026\u0026\ncargo build --locked --release\n"] Also spit out the Rust and Cargo versions to make it easier to understand why they recommend lockfile changes when they do recommend changes. The codegen-protoc business follows [2] and, with the 'git diff', ensures the automatically-generated cincinnati/src/plugins/interface.rs is up to date too. The cd business avoids [3]: error: --features is not allowed in the root of a virtual workspace from: cargo build --features=codegen-protoc --release and [4]: error: the `-Z` flag is only accepted on the nightly channel of Cargo, but this is the `stable` channel from: cargo build -Z package-features --features=codegen-protoc --release -p cincinnati because they were building in a root outside of the cincinnati/Cargo.toml package that actually needs the feature flag [5]. [1]: https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_release/6935/rehearse-6935-pull-ci-openshift-cincinnati-master-images/4/build-log.txt [2]: https://github.com/openshift/cincinnati/tree/a03ccf39ce8633f8585272053bc595ac28fe9ed0#updating-the-plugin-interface-scheme [3]: https://prow.svc.ci.openshift.org/view/gcs/origin-ci-test/pr-logs/pull/openshift_release/6935/rehearse-6935-pull-ci-openshift-cincinnati-master-images/8#1:build-log.txt%3A30 [4]: https://prow.svc.ci.openshift.org/view/gcs/origin-ci-test/pr-logs/pull/openshift_release/6935/rehearse-6935-pull-ci-openshift-cincinnati-master-images/10#1:build-log.txt%3A30 [5]: rust-lang/cargo#5353
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Historically, feature-related flags like
--all-features,--no-default-featuresand--featuresoperated on the currentpackage. That is,
cargo --package foo --feature featwould activatefeatfor the package at the current working directory, and not for thefoopackage.-Z package-featuresflag implements the more obvioussemantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:
--featureflag affects the selected package. It is an error tospecify
--featurewith more than a single-p, or with-poutsideworkspace (the latter could work in theory, but would be hard to
implement).
--all-featuresand--no-default-featuresaffect all selectedpackages, and not the one at cwd.
The package in
cwdis not implicitly enabled when doing featureselection. That is,
cargo build -Z package-features -p foocouldselect less features for various packages than
cargo build -p foo.r? @alexcrichton