profile
viewpoint

alexcrichton/toml-rs 602

A TOML encoding/decoding library for Rust

dtolnay/cargo-expand 524

Subcommand to show result of macro expansion

ehuss/cargo-prefetch 19

Cargo subcommand to download popular crates.

dqsully/atom-column-select 9

Atom package to enhance column selection.

ehuss/cargo-index 7

Cargo subcommand to manage a registry index.

ehuss/ePlayer 3

Music player for iOS.

ehuss/atom-wrap-plus 2

Enhanced word wrapping for the Atom editor.

ehuss/anno-2205-layouts 1

Tool for Anno 2205 layouts.

ehuss/dotfiles 1

My dotfiles.

issue commentrust-lang/cargo

Cargo search using maximum result limit hardcodes the crates.io URL

Hm, I can't seem to reproduce. It explicitly checks if it is a private registry (this line).

Can you say more about your configuration? I assume you have something like:

[registries]
your-registry = { index = "someurl" }

where someurl is not crates.io? Do you have any [source] tables?

AndrewSpeed

comment created time in a day

PR opened rust-lang/rls

Update cargo.

Another small API change.

+5 -5

0 comment

3 changed files

pr created time in a day

push eventehuss/rls

Eric Huss

commit sha 8f135b5480c34529dc45ebda57aac32442cfedad

Update cargo.

view details

push time in a day

issue commentrust-lang/cargo

Cargo rebuilds when it shouldn't

@bestouff I was wondering if you're still able to reproduce this problem on your laptop? If you are, can you maybe try with the latest nightly (2020-02-21 or newer). I've added some extended logging for fingerprints, so if you run with CARGO_LOG=cargo::core::compiler::fingerprint=trace and post the output, it might help track down what is going on.

bestouff

comment created time in a day

issue commentrust-lang/cargo

`cargo fix` uses wrong `crlf` git setting for deciding which newlines to use

cargo fix doesn't use git at all, so I don't think that is related.

If you can create an exact set of steps to reproduce the issue, that would help. Otherwise, I don't think there's anything we can do here.

Boscop

comment created time in a day

issue commentrust-lang/cargo

Make `repository` mandatory in Cargo.toml to find repositories easily

It should display a warning if the repository/homepage/docs fields are not set in cargo package and cargo publish.

gfx

comment created time in a day

issue closedrust-lang/cargo

Build and download in parallel

Hello,

If it's alright, I'd like to propose a feature. (selfishly... :) ).

I'm not always on fast connection and I would love if building and downloading could be done in parallel.

Currently, I believe the following happens- cargo downloads a crate and then recursively traverses the dependency graph. What could be great is if a crate registry stored direct dependency information for each version of a crate. (I'm sure there are more complications but just to get the discussion started...), and there was an API to get this information. cargo would recursively use this information to build a graph and get all the "leaves". It then downloads those leaves first and compiles them. Before downloading inner nodes. Or the complete graph itself could be on the crate registry...?

Ultimately I feel like not all of us have great internet at all times and this could be something that would benefit a lot of us. This also brings down the perceived compilation time and hopefully changes the impression, which IMHO counts too, in general usage.

closed time in a day

SRGOM

issue commentrust-lang/cargo

Build and download in parallel

Thanks for the suggestion! I can sympathize, as my connection is kinda slow, too. Unfortunately I think this would be a Herculean effort to rework Cargo to support this. There are certain post-processing steps that are done after building the compilation graph, and those require knowing the entirety of the graph, and all packages must be downloaded to get the required information. I'm not sure how much information is missing from the index, but it could result in bloating it somewhat, and we don't have any precedent for retroactively updating it.

I'm going to close this, since it is unlikely to happen. Although it would be nice, I don't think it is feasible today.

SRGOM

comment created time in a day

Pull request review commentrust-lang/cargo

Add new feature resolver.

+//! Feature resolver.+//!+//! This is a new feature resolver that runs independently of the main+//! dependency resolver. It is intended to make it easier to experiment with+//! new behaviors. When `-Zfeatures` is not used, it will fall back to using

Posted #7918 if you could review at your leisure.

And it is focused on what should be built for this system not all possible systems that the dependency resolver considers.

This part I didn't quite follow. The dependency resolver runs twice, once with all features enabled (which I think is what you mean by "all possible systems"?), and again with just the features on the command-line. The new feature resolver has the same capabilities, but it only runs once. By "same", I mean if you do --all-features --workspace, then that should result in the same "all possible" scenario matching Cargo.lock's output.

ehuss

comment created time in a day

PR opened rust-lang/cargo

Reviewers
Add extra details in the new feature resolver doc comment.

Some extra details about how the new feature resolver fits in the picture.

+28 -6

0 comment

1 changed file

pr created time in a day

pull request commentrust-lang/rust

Update cargo

@bors r+ rollup

ehuss

comment created time in a day

PR opened rust-lang/rust

Update cargo

11 commits in e02974078a692d7484f510eaec0e88d1b6cc0203..e57bd02999c9f40d52116e0beca7d1dccb0643de 2020-02-18 15:24:43 +0000 to 2020-02-21 20:20:10 +0000

  • fix most remaining clippy findings (mostly redundant imports) (rust-lang/cargo#7912)
  • Add -Zfeatures tracking issues. (rust-lang/cargo#7917)
  • Use rust-lang/rust linkchecker on CI. (rust-lang/cargo#7913)
  • Clean up code mostly based on clippy suggestions (rust-lang/cargo#7911)
  • Add an option to include crate versions to the generated docs (rust-lang/cargo#7903)
  • Better support for license-file. (rust-lang/cargo#7905)
  • Add new feature resolver. (rust-lang/cargo#7820)
  • Switch azure to macOS 10.15. (rust-lang/cargo#7906)
  • Modified the help information of cargo-rustc (rust-lang/cargo#7892)
  • Update for nightly rustfmt. (rust-lang/cargo#7904)
  • Support --config path_to_config.toml cli syntax. (rust-lang/cargo#7901)
+1 -1

0 comment

1 changed file

pr created time in a day

push eventehuss/rust

Michael Bradshaw

commit sha 348278a7fd5fd459f555dd763e71e12c23c1661a

Stabilize Once::is_completed

view details

Dylan MacKenzie

commit sha c981d67b509f1ba16c97683ad6dc430429899e49

[!] Use `rustc_inherit_overflow_checks` in `next_power_of_two` I believe the previous code was calling `ops::Add::add` instead of the `+` operator to get this behavior.

view details

Dylan MacKenzie

commit sha 2afa99379d9623e50efd290e609447bdc5059af8

Use bespoke macro instead of `?` inside const fns

view details

Dylan MacKenzie

commit sha 269bf89865536964546242589bb186a8a7e3c566

Make integer power methods const

view details

Dylan MacKenzie

commit sha 7fe5eaf7d8cb23ceb71d8e509be13d20ef836114

Test integer exponentiation in a const context

view details

Esteban Küber

commit sha 683ebc2dec0a5b88eb3eaf146e6855ea299d17b8

On mismatched argument count point at arguments

view details

Dylan MacKenzie

commit sha fc5c2956b11e29f931cec010e3f38461ec4ac309

Impl `GenKill` for old dataflow framework's `GenKillSet` This impl is temporary and will be removed along with the old dataflow framework. It allows us to reuse the transfer function of new dataflow analyses when defining old ones

view details

Dylan MacKenzie

commit sha 7d9dadcccca9efc63f30fa1c9adee00effb860d4

Implement `Maybe{Mut,}BorrowedLocals` analyses

view details

Dylan MacKenzie

commit sha 34783b73bd891a66fb2af613fef7492376fc7c8a

Remove outdated `IndirectlyMutableLocals` `MaybeMutBorrowedLocals` serves the same purpose and has a better name.

view details

Dylan MacKenzie

commit sha 9972502bafab062b06ef04c02c653f1b868937bd

Reenable peek test for indirect mutation analysis This uses the new `MaybeMutBorrowedLocals` pass but we keep the `rustc_peek_indirectly_mutable` since the two are interchangable except when inspecting a local after it has been marked `StorageDead`.

view details

Dylan MacKenzie

commit sha 1d737fb032b762e69e8d809c0e042d45e08b457d

Use `MaybeBorrowedLocals` for generator analyses It should have the same semantics as `HaveBeenBorrowedLocals`

view details

Dylan MacKenzie

commit sha d045a17c4b032a858323f6c9bea698ee2e5920b7

Use `MaybeMutBorrowedLocals` for const-checking

view details

Dylan MacKenzie

commit sha 6f167e9c5f421613ff3de37771b1352cd98dd4f7

Remove ignore and add explanation of indirect mutation peek test

view details

Eric Huss

commit sha 4810c4712f9edc4c378142ace1b868fc2fd1eeea

Add shared script for linkchecking books.

view details

Matthew Jasper

commit sha cd9f5ff2a1c50a5af94ad1dd1c976f631b9f19a6

Check `Copy` lifetimes bounds when copying from a projection

view details

Matthew Jasper

commit sha ddc25456c5945457ba86cb60994ce9872bd98edd

Check types of statics in MIR typeck

view details

Dylan MacKenzie

commit sha 15a5382ef1115ff11c1357fd21ab4aa12626efee

Rename `MaybeBorrowedLocals` constructors

view details

Dylan MacKenzie

commit sha 0984639348c2fc98389746f6815e576cfcaacda8

Ignore mut borrow from drop terminator in const-eval

view details

Dylan MacKenzie

commit sha 668d2fe807068073647f9c92d81ff0e7b9ab8486

Update line # in test output

view details

Ralf Jung

commit sha ad4b3f3e175a1b5d9e532ed35a917cd47196e75b

const-prop: use one helper method for all lints; consistently lint overflow on BinOps and not on Assert

view details

push time in a day

create barnchehuss/cargo

branch : features-doc-comment

created branch time in a day

push eventehuss/rls

Igor Matuszewski

commit sha 10bf331d4d1280d773045e57d65031969c51dec6

Merge pull request #1636 from ehuss/update-cargo Update cargo

view details

Eric Huss

commit sha 93534169d6c9d17531432e049bf34613d452fbbe

Update cargo.

view details

push time in a day

issue commentrust-lang/cargo

Tag for 0.42 missing

I would have expected the tag cargo-0.42.0 tag to be in sync with rust-1.41.0.

It is. You can see the rust-1.41.0 branch at https://github.com/rust-lang/rust/tree/1.41.0/src/tools, where the last cargo update was 626f0f4.

If you mean the rust-1.41.0 branch here on the cargo repo (https://github.com/rust-lang/cargo/commits/rust-1.41.0), there was one extra commit made (for testing purposes), but was never upstreamed because it wasn't needed.

jnbr

comment created time in a day

pull request commentrust-lang/cargo

fix most remaining clippy findings (mostly redundant imports)

Thanks!

@bors r+

matthiaskrgr

comment created time in a day

issue commentrust-lang/cargo

Tag for 0.42 missing

The tag looks a bit old though.

I made a "lightweight" tag, as that is what the other tags looked like. I believe the date for those is the commit date. Since beta takes 6 weeks, and we didn't do any beta backports, and there aren't commits every day, Dec 3 was the last day a commit was made for that release.

jnbr

comment created time in a day

PR opened rust-lang/cargo

Add -Zfeatures tracking issues.
+4 -0

0 comment

1 changed file

pr created time in a day

create barnchehuss/cargo

branch : features-tracking-issues

created branch time in a day

issue openedrust-lang/cargo

Tracking issue for -Z features=dev_dep

Implementation: #7820 Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#features

Summary -Z features=dev_dep causes the feature resolver to prevent features enabled on dev dependencies from being enabled for normal dependencies. For example:

[dependencies]
serde = {version = "1.0", default-features = false}

[dev-dependencies]
serde = {version = "1.0", features = ["std"]}

In this example, the library will normally link against serde without the std feature. However, when built as a test or example, it will include the std feature.

This mode is ignored if you are building any test, bench, or example. That is, dev dependency features will still be unified if you run commands like cargo test or cargo build --all-targets.

Unresolved issues

  • [ ] Update cargo metadata
  • [ ] Does this cause existing projects to fail?
    • Projects can add missing features as a backwards-compatible workaround. However, if it causes problems for too many projects, we may need to find some way to opt-in.
  • [ ] Does this significantly increase build times?
    • This can cause cargo test to rebuild some dependencies after a cargo build, where previously those dependencies were built once. Projects can add features to re-unify if they want, but it may not be clear or obvious what to add and when. We may need something that identifies these duplicate dependencies, and give suggestions on how to unify them. Or, we may need to make this opt-in somehow so the user needs to make this an explicit decision.
  • [ ] Is it OK that this is a global mode?
    • For example, when running cargo test, binaries will use dependencies with the dev-dependency features. Changing this would be very difficult, requiring major changes to how Cargo builds its unit graph. It may also cause longer build times when it is not necessary, since common dependencies with different features would need to be built twice during cargo test.

created time in a day

issue openedrust-lang/cargo

Tracking issue for -Z features=build_dep

Implementation: #7820 Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#features

Summary -Z features=build_dep causes the feature resolver to prevent features enabled on build dependencies from being enabled for normal dependencies. For example:

[dependencies]
log = "0.4"

[build-dependencies]
log = {version = "0.4", features=['std']}

When building the build script, the log crate will be built with the std feature. When building the library of your package, it will not enable the feature.

Unresolved issues

  • [ ] Update cargo metadata
  • [ ] Does this cause existing projects to fail?
    • Projects can add missing features as a backwards-compatible workaround. However, if it causes problems for too many projects, we may need to find some way to opt-in.
  • [ ] Does this significantly increase build times?
    • This can cause common dependencies to be built multiple times, when they were previously shared (when --target is not used). Projects can add features to re-unify if they want, but it may not be clear or obvious what to add and when. We may need something that identifies these duplicate dependencies, and give suggestions on how to unify them. Or, we may need to make this opt-in somehow so the user needs to make this an explicit decision.
  • [ ] Does the feature resolver need to support decoupling of shared proc-macro dependencies?
    • Currently this isn't possible because Cargo does not have the necessary information to know which dependencies are proc-macros during resolution time. Either we would need to add the proc-macro status to the index, or try to do feature resolution while dependencies are downloaded. The latter is very difficult due to the way downloading works. The former isn't too hard. Nobody has asked for this ability, so it is unclear how important it is. Presumably that is because proc-macros are relatively new, and tend to only use proc-macro-specific dependencies like syn/quote.

created time in a day

issue openedrust-lang/cargo

Tracking issue for -Z features=itarget

Implementation: #7820 Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#features

Summary -Z features=itarget causes the feature resolver to ignore features for target-specific dependencies for targets that don't match the current compile target. For example:

[dependency.common]
version = "1.0"
features = ["f1"]

[target.'cfg(windows)'.dependencies.common]
version = "1.0"
features = ["f2"]

When building this example for a non-Windows platform, the f2 feature will not be enabled.

Unresolved issues

  • [ ] Update cargo metadata
  • [ ] Does this cause existing projects to fail?
    • Projects can add missing features as a backwards-compatible workaround. However, if it causes problems for too many projects, we may need to find some way to opt-in.

created time in a day

issue closedrust-lang/cargo

Tag for 0.42 missing

Cargo-1.41 / 0.42 has been release a few weeks ago but there is no tag for cargo-0.42 on github. If there is no reason why it is missing, it would be helpful if someone can create it.

closed time in a day

jnbr

issue commentrust-lang/cargo

Tag for 0.42 missing

I tagged 0.42.0 at 626f0f40efd32e6b3dbade50cd53fdfaa08446ba

@Mark-Simulacrum or @pietroalbini, can tagging be automated during the release process? Or, can it be added to a release checklist?

jnbr

comment created time in a day

created tagrust-lang/cargo

tag0.42.0

The Rust package manager

created time in a day

push eventehuss/cargo

Eric Huss

commit sha d1a0040e8000cf941367b9443a8cba91aecb99e8

Use rust-lang/rust linkchecker on CI.

view details

push time in a day

push eventehuss/nomicon

Eric Huss

commit sha eaafcd7387fa4c5904a021dc6d50487a6112e0cb

Use rust-lang/rust linkchecker on CI.

view details

push time in a day

push eventehuss/reference

Eric Huss

commit sha 5b8fed8fd8b24a67e14041aa6744c660bf34bee9

Use common script for link checking.

view details

push time in a day

push eventehuss/edition-guide

Eric Huss

commit sha 51d5eeb8c0ea95bf1550edee84dd4a6589a42333

Use rust-lang/rust linkchecker on CI.

view details

push time in a day

push eventehuss/test

Eric Huss

commit sha 3d188666cb4936cd9eb94464363f215242e2afab

Test

view details

push time in a day

push eventehuss/test

Eric Huss

commit sha 30730ba8aa701b3cf1a8d85d7a04c23f1cdf4de3

Test

view details

push time in a day

Pull request review commentrust-lang/edition-guide

Use rust-lang/rust linkchecker on CI.

 jobs:       run: rustup self update     - name: Install Rust       run: |+        set -e

ah, I had tested azure and travis, and I was assuming gha was the same as azure. thanks! (trying to update everyone, and everyone uses different CI)

ehuss

comment created time in a day

Pull request review commentrust-lang/edition-guide

Use rust-lang/rust linkchecker on CI.

 jobs:       run: rustup self update     - name: Install Rust       run: |+        set -e

ah, I had tested azure and travis, and I was assuming gha was the same as azure. thanks! (trying to update everyone, and everyone uses different CI)

ehuss

comment created time in a day

PR opened rust-lang/book

Use rust-lang/rust linkchecker on CI.

This can help ensure submodule updates go smoothly.

+6 -0

0 comment

1 changed file

pr created time in a day

PR opened rust-lang/nomicon

Use rust-lang/rust linkchecker on CI.

This can help ensure submodule updates go smoothly.

+12 -3

0 comment

1 changed file

pr created time in a day

PR opened rust-lang/rust-by-example

Use rust-lang/rust linkchecker on CI.

This can help ensure submodule updates go smoothly.

This also switches to downloading pre-compiled mdbook instead of building it locally. This should reduce the amount of time needed to check CI.

+11 -10

0 comment

1 changed file

pr created time in a day

PR opened rust-lang/cargo

Use rust-lang/rust linkchecker on CI.

This can help ensure submodule updates go smoothly.

+11 -0

0 comment

1 changed file

pr created time in a day

PR opened rust-lang/reference

Use common script for link checking.

Moved linkchecker to a shared script that all books can use.

+9 -30

0 comment

2 changed files

pr created time in a day

PR opened rust-lang/edition-guide

Use rust-lang/rust linkchecker on CI.

This can help ensure submodule updates go smoothly.

+12 -3

0 comment

1 changed file

pr created time in a day

PR opened rust-lang/reference

Update for change in const lint name.

Lint seems to have changed in https://github.com/rust-lang/rust/pull/69185.

+1 -1

0 comment

1 changed file

pr created time in a day

create barnchehuss/reference

branch : fix-new-lint-name

created branch time in a day

create barnchehuss/cargo

branch : linkcheck-script

created branch time in a day

create barnchehuss/rust-by-example

branch : linkcheck-script

created branch time in a day

push eventehuss/reference

Eric Huss

commit sha a907f45d539b07d1a2147b2638aa4099e61fc7fe

Use common script for link checking.

view details

push time in a day

create barnchehuss/nomicon

branch : linkcheck-script

created branch time in a day

push eventehuss/edition-guide

Eric Huss

commit sha 988b45779eb4013d4d92cefef0538fb54f0ccfac

Use rust-lang/rust linkchecker on CI.

view details

push time in a day

create barnchehuss/rust-book

branch : linkcheck-script

created branch time in a day

push eventehuss/test

Eric Huss

commit sha 26073225efe652d693718fcffb3e7c44efd63404

Test

view details

push time in a day

push eventehuss/test

Eric Huss

commit sha 3197e612cb6503806275ee746fcee17d5347798c

Test

view details

push time in a day

push eventehuss/test

Eric Huss

commit sha 54d4661b8994e4a3169c3aac27b966061a37bcbf

Test

view details

push time in a day

pull request commentrust-lang/cargo

Clean up code mostly based on clippy suggestions

@bors retry E: Failed to fetch https://packages.microsoft.com/ubuntu/16.04/prod/dists/xenial/main/binary-amd64/Packages.bz2 Hash Sum mismatch

aleksator

comment created time in 2 days

pull request commentrust-lang/cargo

Add an option to include crate versions to the generated docs

@bors retry Failed to fetch https://packages.microsoft.com/ubuntu/16.04/prod/dists/xenial/main/binary-amd64/Packages.bz2 Hash Sum mismatch

aleksator

comment created time in 2 days

push eventehuss/edition-guide

Eric Huss

commit sha 74e2d7fbda69d212c0733fae87f8c00f62c7b8dc

Check links on CI.

view details

push time in 2 days

create barnchehuss/edition-guide

branch : linkcheck-script

created branch time in 2 days

create barnchehuss/reference

branch : linkcheck-script

created branch time in 2 days

pull request commentrust-lang/cargo

Add an option to include crate versions to the generated docs

Thanks! A separate commit is probably fine, I normally only squash if there are a bunch of commits, or commits are changing previous ones in the same PR.

@rust-lang/cargo FYI, this is a really minor new nightly-only feature, so I'm not going to bother with FCP. If there are changes (or if we think we should never do this), feel free to leave comments on the tracking issue.

@bors r+

aleksator

comment created time in 2 days

pull request commentrust-lang/cargo

Clean up code mostly based on clippy suggestions

Thanks! @bors r+

aleksator

comment created time in 2 days

pull request commentrust-lang/cargo

Better support for license-file.

@bors r=alexcrichton

ehuss

comment created time in 2 days

PullRequestEvent

PR closed rust-lang/cargo

Better support for license-file. S-waiting-on-bors

This adds some changes to how cargo package and cargo publish handle the license-file field. This also incorporates some refactoring which hopefully makes the code a little clearer and straightforward, but which also resulted in some minor behavior changes.

  • Warn if license-file points to a non-existent file.
  • Automatically include license-file, even if it is not listed in the package.include list (similar to how Cargo.toml/lock are automatically included).
  • If license-file points outside of the package root, copy the file to the package root (and rewrite the field in Cargo.toml).
  • Files are now sorted when archived.
  • Archiving: Cargo.toml.orig is explicitly printed where before it did not report that.
  • cargo package --list now shows Cargo.toml.orig where before it was not reported.

Closes #3537 Closes #7830

+495 -208

8 comments

7 changed files

ehuss

pr closed time in 2 days

pull request commentrust-lang/cargo

Better support for license-file.

@bors retry Failed to fetch https://packages.microsoft.com/ubuntu/16.04/prod/dists/xenial/main/binary-amd64/Packages Writing more data than expected (670139 > 669553)

ehuss

comment created time in 2 days

pull request commentrust-lang/cargo

Better support for license-file.

@bors retry Failed to fetch https://packages.microsoft.com/ubuntu/16.04/prod/dists/xenial/main/binary-amd64/Packages Writing more data than expected (670139 > 669553)

ehuss

comment created time in 2 days

push eventehuss/cargo

KaneGreen

commit sha 367fe7bfcb4c9ea4b8511bf198c9ccb539ebcf2e

Modified the help information of cargo-rustc

view details

Eric Huss

commit sha 1d5d7a269fbff61a70b36c85e004351b6d761403

Support `--config path_to_config.toml` cli syntax.

view details

bors

commit sha e0678fbbf8bde3b7762cfe9a8ab8a6a8a88bf139

Auto merge of #7901 - ehuss:config-cli-path, r=alexcrichton Support `--config path_to_config.toml` cli syntax. Updates the `--config` flag so that if the argument appears to be a file, it will load the file. cc #7722, #7723

view details

Eric Huss

commit sha 4b6c26dd16786b416190bd0a36e7646d33b9846a

Update for nightly rustfmt.

view details

bors

commit sha c8019b10e58de31df0611288015012868456e452

Auto merge of #7904 - ehuss:rustfmt-1.4.12-fix, r=alexcrichton Update for nightly rustfmt. Most recently nightly seems to have slightly different behavior.

view details

bors

commit sha 389943439022e1e192f8b6e04de6cd475bb5dbc3

Auto merge of #7892 - KaneGreen:rustc-about-text, r=ehuss Modified the help information of cargo-rustc ### Motivation The original help information for `cargo build` is > Compile a local package and all of its dependencies And the original help information for `cargo rustc` is > Compile a package and all of its dependencies These messages are **too similar** to make it difficult to distinguish the differences between the two commands. According to the [cargo book](https://doc.rust-lang.org/cargo/commands/cargo-rustc.html), `cargo rustc` is characterized by > pass extra options to the compiler I think this should be written into the help text of the command. In addition, the `<args> ...` parameters of `cargo rustc` lack help text and need to be added. ### Modification See the commit files. ### Problems Maybe some words in my modification are not accurate enough. If you have better wording, welcome to point out. Thanks.

view details

Eric Huss

commit sha 0a2f691381f958b93fff90abf0521da90a9c68b3

Switch azure to macOS 10.15.

view details

Eric Huss

commit sha 457c4bc4c8727d71dbc075b8b3f88183987c7d81

Work-around macOS 10.15 Gatekeeper issue.

view details

bors

commit sha 369991b9a09c9f49deebe81fa05d6e104c59ea11

Auto merge of #7906 - ehuss:macos-10.15, r=alexcrichton Switch azure to macOS 10.15. Switches CI to the macOS 10.15 image. Since 32-bit support is no longer available, this changes how cross-compile testing works. I decided to use `x86_64-apple-ios` as a cross target, since it can easily build/link on macOS. `cargo run` won't work without a simulator, so some of the tests are restructured to check if `cargo run` is allowed. If you do have a simulator, it should Just Work. CI doesn't seem to be configured with a simulator installed, and I didn't bother to look if that would be possible (the simulators tend to be several gigabytes in size). An alternative approach would be to use wasm as a cross target, which is also fairly easy to support. But wasm is a sufficiently different target that it can cause some issues in some tests, and is a bit harder to run as an executable. This also adds some more help text on how to configure cross-compile tests. Rustup is now installed on macOS by default, so no need to install it. Unfortunately self-updates are not allowed, but hopefully that won't be an issue. Closes #7821

view details

Eric Huss

commit sha 949eccac3e0d7df8ef705054fa45926ce8005291

Move rustc target collection out of bcx. This allows querying it earlier, and independently of the rest of stuff in BuildContext.

view details

Eric Huss

commit sha db80baad21ba0088bce4567a039044735d9c58eb

Add a RequestedFeatures struct to hold cli features. The RequestedFeatures struct holds the features requested on the command line.

view details

Eric Huss

commit sha 7caa1612cf39896d957afb11f07f3a10bb352b78

Add new feature resolver.

view details

Eric Huss

commit sha d728f386e73e02a98d49892a2913b9821b23589f

Ensure dev-dep features are unified if any are used. There is a complex issue where `cargo test -Zfeatures=dev_dep` was building things incorrectly if there was a binary executable. The issue is that lib.rs needed to be built twice (once linked against normal dependencies, once against dev dependencies), but the current Unit structure can't distinguish between the two, and thus it was picking the wrong one. Instead of allowing `cargo test` to build binaries without dev-dependency features, just link main.rs against the dev-dependency-unified versions. We may need to revisit this in the future, but for now it is not clear what people want or how this should work. Fixing this would require substantial changes to how unit dependencies are computed (to properly handle deduplication), so for now we'll use a simpler solution. It would also mean `cargo test` would take longer on some projects (because it would need to build the library 3 times instead of twice).

view details

Eric Huss

commit sha a2135fe1cf7789d6a99edfbb366aa574dffbd860

Do not store `requested_features` in FeatureResolver. This isn't really needed "globally", just at the beginning.

view details

Eric Huss

commit sha 3f06823095682a1058376aaecdc9e55be901cd8f

Add some comments to help clarify some features stuff from review.

view details

Eric Huss

commit sha 2c8b9fb5ee7083b2c330e881e9cd1ca2ef6d68bd

Add test for build script being run multiple times.

view details

Eric Huss

commit sha 76f0d68de9855aeb65e37f565dc8ec323574ca12

Consolidate -Zpackage-features member iteration logic.

view details

Eric Huss

commit sha 899067fbec52cf8507250c23920c84fce3590e08

Add a cyclical dev-dep test.

view details

Eric Huss

commit sha da678a75d5806081799cbb7350ef5ffbb8b26920

Add `-Zfeatures=all` option.

view details

Eric Huss

commit sha 134aeff1bfd3e07c7da869717ede6e3eb4711c5c

Add comment explaining dep_kind in compute_deps_custom_build.

view details

push time in 2 days

Pull request review commentrust-lang/cargo

Clean up code mostly based on clippy suggestions

 fn build_work<'a, 'cfg>(cx: &mut Context<'a, 'cfg>, unit: &Unit<'a>) -> CargoRes      // Be sure to pass along all enabled features for this package, this is the     // last piece of statically known information that we have.-    for feat in &unit.features {+    for &feat in &unit.features {

Can you explain these changes to add &? It looks more confusing to me.

aleksator

comment created time in 2 days

Pull request review commentrust-lang/cargo

Clean up code mostly based on clippy suggestions

 impl Platform {                             )),                         _ => (),                     },-                    Cfg::KeyPair(name, _) => match name.as_str() {-                        "feature" =>-                            warnings.push(String::from(-                                "Found `feature = ...` in `target.'cfg(...)'.dependencies`. \-                                 This key is not supported for selecting dependencies \-                                 and will not work as expected. \-                                 Use the [features] section instead: \-                                 https://doc.rust-lang.org/cargo/reference/features.html"-                            )),-                        _ => (),+                    Cfg::KeyPair(name, _) => if let "feature" = name.as_str() {

Could this be if name.as_str() == "feature"

aleksator

comment created time in 2 days

push eventehuss/cargo

Eric Huss

commit sha 4d0fda7cd9efb14055915e755b09ee3cf64586ff

Fix bug where an optional dependency is disabled in one fork, and enabled in another.

view details

push time in 2 days

push eventehuss/cargo

KaneGreen

commit sha 367fe7bfcb4c9ea4b8511bf198c9ccb539ebcf2e

Modified the help information of cargo-rustc

view details

bors

commit sha 389943439022e1e192f8b6e04de6cd475bb5dbc3

Auto merge of #7892 - KaneGreen:rustc-about-text, r=ehuss Modified the help information of cargo-rustc ### Motivation The original help information for `cargo build` is > Compile a local package and all of its dependencies And the original help information for `cargo rustc` is > Compile a package and all of its dependencies These messages are **too similar** to make it difficult to distinguish the differences between the two commands. According to the [cargo book](https://doc.rust-lang.org/cargo/commands/cargo-rustc.html), `cargo rustc` is characterized by > pass extra options to the compiler I think this should be written into the help text of the command. In addition, the `<args> ...` parameters of `cargo rustc` lack help text and need to be added. ### Modification See the commit files. ### Problems Maybe some words in my modification are not accurate enough. If you have better wording, welcome to point out. Thanks.

view details

Eric Huss

commit sha 0a2f691381f958b93fff90abf0521da90a9c68b3

Switch azure to macOS 10.15.

view details

Eric Huss

commit sha 457c4bc4c8727d71dbc075b8b3f88183987c7d81

Work-around macOS 10.15 Gatekeeper issue.

view details

bors

commit sha 369991b9a09c9f49deebe81fa05d6e104c59ea11

Auto merge of #7906 - ehuss:macos-10.15, r=alexcrichton Switch azure to macOS 10.15. Switches CI to the macOS 10.15 image. Since 32-bit support is no longer available, this changes how cross-compile testing works. I decided to use `x86_64-apple-ios` as a cross target, since it can easily build/link on macOS. `cargo run` won't work without a simulator, so some of the tests are restructured to check if `cargo run` is allowed. If you do have a simulator, it should Just Work. CI doesn't seem to be configured with a simulator installed, and I didn't bother to look if that would be possible (the simulators tend to be several gigabytes in size). An alternative approach would be to use wasm as a cross target, which is also fairly easy to support. But wasm is a sufficiently different target that it can cause some issues in some tests, and is a bit harder to run as an executable. This also adds some more help text on how to configure cross-compile tests. Rustup is now installed on macOS by default, so no need to install it. Unfortunately self-updates are not allowed, but hopefully that won't be an issue. Closes #7821

view details

Eric Huss

commit sha 949eccac3e0d7df8ef705054fa45926ce8005291

Move rustc target collection out of bcx. This allows querying it earlier, and independently of the rest of stuff in BuildContext.

view details

Eric Huss

commit sha db80baad21ba0088bce4567a039044735d9c58eb

Add a RequestedFeatures struct to hold cli features. The RequestedFeatures struct holds the features requested on the command line.

view details

Eric Huss

commit sha 7caa1612cf39896d957afb11f07f3a10bb352b78

Add new feature resolver.

view details

Eric Huss

commit sha d728f386e73e02a98d49892a2913b9821b23589f

Ensure dev-dep features are unified if any are used. There is a complex issue where `cargo test -Zfeatures=dev_dep` was building things incorrectly if there was a binary executable. The issue is that lib.rs needed to be built twice (once linked against normal dependencies, once against dev dependencies), but the current Unit structure can't distinguish between the two, and thus it was picking the wrong one. Instead of allowing `cargo test` to build binaries without dev-dependency features, just link main.rs against the dev-dependency-unified versions. We may need to revisit this in the future, but for now it is not clear what people want or how this should work. Fixing this would require substantial changes to how unit dependencies are computed (to properly handle deduplication), so for now we'll use a simpler solution. It would also mean `cargo test` would take longer on some projects (because it would need to build the library 3 times instead of twice).

view details

Eric Huss

commit sha a2135fe1cf7789d6a99edfbb366aa574dffbd860

Do not store `requested_features` in FeatureResolver. This isn't really needed "globally", just at the beginning.

view details

Eric Huss

commit sha 3f06823095682a1058376aaecdc9e55be901cd8f

Add some comments to help clarify some features stuff from review.

view details

Eric Huss

commit sha 2c8b9fb5ee7083b2c330e881e9cd1ca2ef6d68bd

Add test for build script being run multiple times.

view details

Eric Huss

commit sha 76f0d68de9855aeb65e37f565dc8ec323574ca12

Consolidate -Zpackage-features member iteration logic.

view details

Eric Huss

commit sha 899067fbec52cf8507250c23920c84fce3590e08

Add a cyclical dev-dep test.

view details

Eric Huss

commit sha da678a75d5806081799cbb7350ef5ffbb8b26920

Add `-Zfeatures=all` option.

view details

Eric Huss

commit sha 134aeff1bfd3e07c7da869717ede6e3eb4711c5c

Add comment explaining dep_kind in compute_deps_custom_build.

view details

Eric Huss

commit sha 615464518639de308153a2e60b4a6d4801f87034

Rewrite new feature resolver to simplify DepKind handling. Now that dev-dependencies are a global setting, only build-dependencies matter. This is maybe a little simpler to understand?

view details

Eric Huss

commit sha 6f337386e7d3cc08f75974970d30a56de950eaba

Fix `cargo clean -p` crashing with -Zfeatures.

view details

Eric Huss

commit sha 8973b959220c59d0f2bdfb13a6f8de228ab6b75d

Fix bug where required-features didn't work with -Zfeatures=build_dep correctly.

view details

Eric Huss

commit sha e0d64f94610f2c309a843b27eee786004784621e

Change have_dev_units from a bool to enum HasDevUnits for clarity.

view details

push time in 2 days

pull request commentrust-lang/cargo

Add new feature resolver.

Added some comments, and fixed a critical bug in how shared optional dependencies were handled.

@Eh2406 you mentioned in the meeting wanting a high level overview, but I wasn't sure if you meant beyond what is already written. Is there additional information you'd like to see in this PR? I think if you start by reading unstable.md to get a sense of what it does and how to use it, you can then go to resolve/features.rs which contains an overview of how it fits. I've tried to include plenty of comments, but let me know if there's anything you'd like me to add.

ehuss

comment created time in 2 days

Pull request review commentrust-lang/cargo

Add new feature resolver.

 pub struct UnitFor {     /// A target for `build.rs` or any of its dependencies, or a proc-macro or     /// any of its dependencies. This enables `build-override` profiles for     /// these targets.-    build: bool,+    host: bool,+    /// A target for a build dependency (or any of its dependencies). This is+    /// used for computing features of build dependencies independently of+    /// other dependency kinds.+    ///+    /// The subtle difference between this and `host` is that the build script+    /// for a non-host package sets this to `false` because it wants the+    /// features of the non-host package (whereas `host` is true because the+    /// build script is being built for the host). `build_dep` becomes `true`+    /// for build-dependencies, or any of their dependencies.+    build_dep: bool,

Hm, so it is working correctly, but you do point out that host isn't accurate for the RunCustomBuild unit. host only matters for the profile, and the RunCustomBuild unit goes through a separate code path for computing the profile. That is here where it manually fetches the profile (ignoring unit_for). All other units go through this path where it inspects unit_for to determine the profile. However, it is necessary for host to be true for RunCustomBuild so that all dependencies below it are marked as "host:true". Added some comments explaining this.

shared_dep build.rs is only compiled once regardless of feature settings, right? And then it's executed twice maybe depending on feature settings/targets?

It depends. With -Zfeatures=build_dep, and the features listed are different between the normal and build dep, then it will get built twice. The reason for this is that many scripts out there use #[cfg] and cfg! to detect features, instead of inspecting "CARGO_FEATURE_*". Only building it once would break a large number of build scripts. I don't think it would be feasible to avoid that.

ehuss

comment created time in 2 days

push eventehuss/cargo

Eric Huss

commit sha 4adff01332070232dd33d83aa945a606762822df

Add comment trying to explain recursion and optional dependencies.

view details

Eric Huss

commit sha 8c3c606bfefcd15c850e84541e9fe3b092526964

Add comment on relationship of RunCustomBuild and UnitFor::host.

view details

Eric Huss

commit sha ff68a7c3c2f116a2bb64172c3928098558506073

Fix bug where an optional dependency is disabled in one fork, and enabled in another.

view details

push time in 2 days

issue commentrust-lang/rust

unused-extern-crate false positive with sysroot crates

Hm, this is an unexpected consequence due to https://github.com/rust-lang/cargo/pull/7700. As of beta (1.42), extern crate proc_macro; isn't necessary.

I can see how that might be problematic for people who use deny(warnings) or deny(unused). I'm not sure what the policy is for that. For now you can either remove the extern crate proc_macro, or if you need compatibility with older versions, add an explicit allow.

nagisa

comment created time in 3 days

pull request commentrust-lang/cargo

Switch azure to macOS 10.15.

@alexcrichton I think this is ready to go. Do you want to take a quick peek at the last commit? I ran tests for a couple hours locally without problems, and have done a number of builds on azure without problems.

ehuss

comment created time in 3 days

push eventehuss/cargo

Eric Huss

commit sha 0a2f691381f958b93fff90abf0521da90a9c68b3

Switch azure to macOS 10.15.

view details

Eric Huss

commit sha 457c4bc4c8727d71dbc075b8b3f88183987c7d81

Work-around macOS 10.15 Gatekeeper issue.

view details

push time in 3 days

push eventehuss/cargo

Eric Huss

commit sha d2e166cd7e7d1599c93ed70ed0d2b8e4afe5197b

Work-around macOS 10.15 Gatekeeper issue.

view details

push time in 3 days

push eventehuss/cargo

Eric Huss

commit sha 3489428921671b274b08ebbabd00128d56ebaa00

Set an environment variable for tests to find executables.

view details

Eric Huss

commit sha 499f917c03f4a4956b83bb497f247e75311528ee

Switch to case-sensitive environment variable.

view details

Eric Huss

commit sha 4cf531f5a6939fb92c095dd76e252bf778815b01

Add more docs on CARGO_BIN_EXE_.

view details

Eric Huss

commit sha 0d44a8267bf503645ceb5f5853abdd4cce407dc8

Rework internal errors.

view details

bors

commit sha 74f2b400d2be43da798f99f94957d359bc223988

Auto merge of #7896 - ehuss:internal-errors, r=alexcrichton Rework internal errors. This changes the behavior of "internal" errors, which were previously hidden and only displayed with `--verbose`. The changes here: - `internal` now means "a cargo bug", and is always displayed and requests that the user file a bug report. - Added `VerboseError` to signify an error that should only be displayed with `--verbose`. This is only used in one place, to display the `rustc` compiler command if the compiler exited with a normal error code (i.e. not a crash). - Audited the uses of internal errors, and promoted some to normal errors, as they seemed to contain useful information, but weren't necessarily bugs in cargo. - Added some details to some errors. - Sometimes the "run with --verbose" message wasn't being printed when I think it should. This happened when rustc failed while other rustc processes were running. Another case was with `cargo install` installing multiple packages, and one of them fails.

view details

bors

commit sha e02974078a692d7484f510eaec0e88d1b6cc0203

Auto merge of #7697 - ehuss:bin-test-env, r=alexcrichton Set an environment variable for tests to find executables. This adds the environment variable `CARGO_BIN_EXE_<name>` so that integration tests can find binaries to execute, instead of doing things like inspecting `env::current_exe()`. The use of uppercase is primarily motivated by Windows whose Rust implementation behaves in a strange way. It always ascii-upper-cases keys to implement case-insensitive matching (which loses the original case). Seems less likely to result in confusion? Closes #5758.

view details

Eric Huss

commit sha 1d5d7a269fbff61a70b36c85e004351b6d761403

Support `--config path_to_config.toml` cli syntax.

view details

bors

commit sha e0678fbbf8bde3b7762cfe9a8ab8a6a8a88bf139

Auto merge of #7901 - ehuss:config-cli-path, r=alexcrichton Support `--config path_to_config.toml` cli syntax. Updates the `--config` flag so that if the argument appears to be a file, it will load the file. cc #7722, #7723

view details

Eric Huss

commit sha 4b6c26dd16786b416190bd0a36e7646d33b9846a

Update for nightly rustfmt.

view details

bors

commit sha c8019b10e58de31df0611288015012868456e452

Auto merge of #7904 - ehuss:rustfmt-1.4.12-fix, r=alexcrichton Update for nightly rustfmt. Most recently nightly seems to have slightly different behavior.

view details

KaneGreen

commit sha 3b4fff99aaf8822a5db41c8c0404a1a8d967486e

Modified the help information of cargo-rustc

view details

Eric Huss

commit sha eed550a0c7da6cbfe6893e64e133e4e8618a58e2

Move rustc target collection out of bcx. This allows querying it earlier, and independently of the rest of stuff in BuildContext.

view details

Eric Huss

commit sha 6bfc06fdc259ba5971ad1c716c46c9154639d88d

Add a RequestedFeatures struct to hold cli features. The RequestedFeatures struct holds the features requested on the command line.

view details

Eric Huss

commit sha ca2ee1ae126229caec9e5483498c6d8f04d02d4d

Add new feature resolver.

view details

Eric Huss

commit sha c370136e877ca540408e3bdf03613c8e391d82db

Ensure dev-dep features are unified if any are used. There is a complex issue where `cargo test -Zfeatures=dev_dep` was building things incorrectly if there was a binary executable. The issue is that lib.rs needed to be built twice (once linked against normal dependencies, once against dev dependencies), but the current Unit structure can't distinguish between the two, and thus it was picking the wrong one. Instead of allowing `cargo test` to build binaries without dev-dependency features, just link main.rs against the dev-dependency-unified versions. We may need to revisit this in the future, but for now it is not clear what people want or how this should work. Fixing this would require substantial changes to how unit dependencies are computed (to properly handle deduplication), so for now we'll use a simpler solution. It would also mean `cargo test` would take longer on some projects (because it would need to build the library 3 times instead of twice).

view details

Eric Huss

commit sha 0b1dae49e88576438eb6eecf93bc2d4ebcb04694

Do not store `requested_features` in FeatureResolver. This isn't really needed "globally", just at the beginning.

view details

Eric Huss

commit sha 33414a13c20e574f80109cecde56a3f202a03509

Add some comments to help clarify some features stuff from review.

view details

Eric Huss

commit sha ff4208c0e3aa96c12e1577c5d4ed66e0a0f9b604

Add test for build script being run multiple times.

view details

Eric Huss

commit sha 88c607016d3354c4c87579f7e9249b778cdf92ad

Consolidate -Zpackage-features member iteration logic.

view details

Eric Huss

commit sha 5227b94038feb5a5189a8c5945c4bf88b53a10f5

Add a cyclical dev-dep test.

view details

push time in 3 days

Pull request review commentrust-lang/cargo

Add new feature resolver.

 impl UnitFor {         }     } -    /// Returns `true` if this unit is for a custom build script or one of its-    /// dependencies.-    pub fn is_build(self) -> bool {-        self.build+    /// Returns a new copy updating it for a build dependency.+    ///+    /// This is part of the machinery responsible for handling feature+    /// decoupling for build dependencies in the new feature resolver.+    pub fn with_build_dep(mut self, build_dep: bool) -> UnitFor {

Yea, I struggled a bit with the naming convention and wasn't happy with it. But I'm unable to think of anything particularly better. If you think of something, let me know!

I don't know if there is a common naming convention for this idiom (creating a copy and modifying a field in one step)? Maybe that's a sign it may be better to be explicit about creating a copy, and then call set_build_dep?

ehuss

comment created time in 3 days

Pull request review commentrust-lang/cargo

Add new feature resolver.

 fn deps_of_roots<'a, 'cfg>(roots: &[Unit<'a>], mut state: &mut State<'a, 'cfg>)             } else if unit.target.is_custom_build() {                 // This normally doesn't happen, except `clean` aggressively                 // generates all units.-                UnitFor::new_build()+                UnitFor::new_build(false)

is_custom_build is true for both CompileMode::RunCustomBuild and CompileMode::Build of a build.rs script. Normally code uses is_run_custom_build if it needs just one or the other.

Yea, any situation there is UnitFor::new_build(false) is the "subtle" difference. That is, whenever adding a build.rs script for a normal dependency.

ehuss

comment created time in 3 days

Pull request review commentrust-lang/cargo

Add new feature resolver.

 pub struct UnitFor {     /// A target for `build.rs` or any of its dependencies, or a proc-macro or     /// any of its dependencies. This enables `build-override` profiles for     /// these targets.-    build: bool,+    host: bool,+    /// A target for a build dependency (or any of its dependencies). This is+    /// used for computing features of build dependencies independently of+    /// other dependency kinds.+    ///+    /// The subtle difference between this and `host` is that the build script+    /// for a non-host package sets this to `false` because it wants the+    /// features of the non-host package (whereas `host` is true because the+    /// build script is being built for the host). `build_dep` becomes `true`+    /// for build-dependencies, or any of their dependencies.+    build_dep: bool,

I added an example.

I'm reluctant to add an enum to represent the 3 states. All the code is oriented around simple booleans, and I think it would make it harder to follow if they were unified into one field. I usually agree that it is good to prevent impossible scenarios, but in this case I think it might be harder to understand.

ehuss

comment created time in 3 days

Pull request review commentrust-lang/cargo

Add new feature resolver.

+//! Feature resolver.+//!+//! This is a new feature resolver that runs independently of the main+//! dependency resolver. It is intended to make it easier to experiment with+//! new behaviors. When `-Zfeatures` is not used, it will fall back to using+//! the original `Resolve` feature computation. With `-Zfeatures` enabled,+//! this will walk the dependency graph and compute the features using a+//! different algorithm. One of its key characteristics is that it can avoid+//! unifying features for shared dependencies in some situations.+//!+//! The preferred way to engage this new resolver is via+//! `resolve_ws_with_opts`.+//!+//! There are many assumptions made about the resolver itself. It assumes+//! validation has already been done on the feature maps, and doesn't do any+//! validation itself. It assumes dev-dependencies within a dependency have+//! been removed.++use crate::core::compiler::{CompileKind, RustcTargetData};+use crate::core::dependency::{DepKind, Dependency};+use crate::core::resolver::types::FeaturesSet;+use crate::core::resolver::Resolve;+use crate::core::{FeatureValue, InternedString, PackageId, PackageIdSpec, Workspace};+use crate::util::{CargoResult, Config};+use std::collections::{BTreeSet, HashMap, HashSet};+use std::rc::Rc;++/// Map of activated features.+///+/// The key is `(PackageId, bool)` where the bool is `true` if these+/// are features for a build dependency.+type ActivateMap = HashMap<(PackageId, bool), BTreeSet<InternedString>>;++/// Set of all activated features for all packages in the resolve graph.+pub struct ResolvedFeatures {+    activated_features: ActivateMap,+    /// This is only here for legacy support when `-Zfeatures` is not enabled.+    legacy: Option<HashMap<PackageId, Vec<InternedString>>>,+    opts: FeatureOpts,+}++/// Options for how the feature resolver works.+#[derive(Default)]+struct FeatureOpts {+    /// -Zpackage-features, changes behavior of feature flags in a workspace.+    package_features: bool,+    /// -Zfeatures is enabled, use new resolver.+    new_resolver: bool,+    /// Build deps will not share share features with other dep kinds.+    decouple_build_deps: bool,+    /// Dev dep features will not be activated unless needed.+    decouple_dev_deps: bool,+    /// Targets that are not in use will not activate features.+    ignore_inactive_targets: bool,+    /// If enabled, compare against old resolver (for testing).+    compare: bool,+}++impl FeatureOpts {+    fn new(config: &Config, has_dev_units: bool) -> CargoResult<FeatureOpts> {+        let mut opts = FeatureOpts::default();+        let unstable_flags = config.cli_unstable();+        opts.package_features = unstable_flags.package_features;+        let mut enable = |feat_opts: &Vec<String>| {+            opts.new_resolver = true;+            for opt in feat_opts {+                match opt.as_ref() {+                    "build_dep" => opts.decouple_build_deps = true,+                    "dev_dep" => opts.decouple_dev_deps = true,+                    "itarget" => opts.ignore_inactive_targets = true,+                    "all" => {+                        opts.decouple_build_deps = true;+                        opts.decouple_dev_deps = true;+                        opts.ignore_inactive_targets = true;+                    }+                    "compare" => opts.compare = true,+                    "ws" => unimplemented!(),+                    "host" => unimplemented!(),+                    s => anyhow::bail!("-Zfeatures flag `{}` is not supported", s),+                }+            }+            Ok(())+        };+        if let Some(feat_opts) = unstable_flags.features.as_ref() {+            enable(feat_opts)?;+        }+        // This env var is intended for testing only.+        if let Ok(env_opts) = std::env::var("__CARGO_FORCE_NEW_FEATURES") {+            if env_opts == "1" {+                opts.new_resolver = true;+            } else {+                let env_opts = env_opts.split(',').map(|s| s.to_string()).collect();+                enable(&env_opts)?;+            }+        }+        if has_dev_units {+            // Decoupling of dev deps is not allowed if any test/bench/example+            // is being built. It may be possible to relax this in the future,+            // but it will require significant changes to how unit+            // dependencies are computed, and can result in longer build times+            // with `cargo test` because the lib may need to be built 3 times+            // instead of twice.+            opts.decouple_dev_deps = false;+        }+        Ok(opts)+    }+}++/// Features flags requested for a package.+#[derive(Debug, Clone, Eq, PartialEq, Hash)]+pub struct RequestedFeatures {+    pub features: FeaturesSet,+    pub all_features: bool,+    pub uses_default_features: bool,+}++impl RequestedFeatures {+    /// Creates a new RequestedFeatures from the given command-line flags.+    pub fn from_command_line(+        features: &[String],+        all_features: bool,+        uses_default_features: bool,+    ) -> RequestedFeatures {+        RequestedFeatures {+            features: Rc::new(RequestedFeatures::split_features(features)),+            all_features,+            uses_default_features,+        }+    }++    /// Creates a new RequestedFeatures with the given `all_features` setting.+    pub fn new_all(all_features: bool) -> RequestedFeatures {+        RequestedFeatures {+            features: Rc::new(BTreeSet::new()),+            all_features,+            uses_default_features: true,+        }+    }++    fn split_features(features: &[String]) -> BTreeSet<InternedString> {+        features+            .iter()+            .flat_map(|s| s.split_whitespace())+            .flat_map(|s| s.split(','))+            .filter(|s| !s.is_empty())+            .map(InternedString::new)+            .collect::<BTreeSet<InternedString>>()+    }+}++impl ResolvedFeatures {+    /// Returns the list of features that are enabled for the given package.+    pub fn activated_features(&self, pkg_id: PackageId, is_build: bool) -> Vec<InternedString> {+        self.activated_features_int(pkg_id, is_build, true)+    }++    /// Variant of `activated_features` that returns an empty Vec if this is+    /// not a valid pkg_id/is_build combination. Used by `cargo clean` which+    /// doesn't know the exact set.+    pub fn activated_features_unverified(+        &self,+        pkg_id: PackageId,+        is_build: bool,+    ) -> Vec<InternedString> {+        self.activated_features_int(pkg_id, is_build, false)+    }++    fn activated_features_int(+        &self,+        pkg_id: PackageId,+        is_build: bool,+        verify: bool,+    ) -> Vec<InternedString> {+        if let Some(legacy) = &self.legacy {+            legacy.get(&pkg_id).map_or_else(Vec::new, |v| v.clone())+        } else {+            let is_build = self.opts.decouple_build_deps && is_build;+            if let Some(fs) = self.activated_features.get(&(pkg_id, is_build)) {+                fs.iter().cloned().collect()+            } else if verify {+                panic!("features did not find {:?} {:?}", pkg_id, is_build)+            } else {+                Vec::new()+            }+        }+    }+}++pub struct FeatureResolver<'a, 'cfg> {+    ws: &'a Workspace<'cfg>,+    target_data: &'a RustcTargetData,+    /// The platform to build for, requested by the user.+    requested_target: CompileKind,+    resolve: &'a Resolve,+    /// Options that change how the feature resolver operates.+    opts: FeatureOpts,+    /// Map of features activated for each package.+    activated_features: ActivateMap,+    /// Keeps track of which packages have had its dependencies processed.+    /// Used to avoid cycles, and to speed up processing.+    processed_deps: HashSet<(PackageId, bool)>,+}++impl<'a, 'cfg> FeatureResolver<'a, 'cfg> {+    /// Runs the resolution algorithm and returns a new `ResolvedFeatures`+    /// with the result.+    pub fn resolve(+        ws: &Workspace<'cfg>,+        target_data: &RustcTargetData,+        resolve: &Resolve,+        requested_features: &RequestedFeatures,+        specs: &[PackageIdSpec],+        requested_target: CompileKind,+        has_dev_units: bool,+    ) -> CargoResult<ResolvedFeatures> {+        use crate::util::profile;+        let _p = profile::start("resolve features");++        let opts = FeatureOpts::new(ws.config(), has_dev_units)?;+        if !opts.new_resolver {+            // Legacy mode.+            return Ok(ResolvedFeatures {+                activated_features: HashMap::new(),+                legacy: Some(resolve.features_clone()),+                opts,+            });+        }+        let mut r = FeatureResolver {+            ws,+            target_data,+            requested_target,+            resolve,+            opts,+            activated_features: HashMap::new(),+            processed_deps: HashSet::new(),+        };+        r.do_resolve(specs, requested_features)?;+        log::debug!("features={:#?}", r.activated_features);+        if r.opts.compare {+            r.compare();+        }+        Ok(ResolvedFeatures {+            activated_features: r.activated_features,+            legacy: None,+            opts: r.opts,+        })+    }++    /// Performs the process of resolving all features for the resolve graph.+    fn do_resolve(+        &mut self,+        specs: &[PackageIdSpec],+        requested_features: &RequestedFeatures,+    ) -> CargoResult<()> {+        let member_features = self.ws.members_with_features(specs, requested_features)?;+        for (member, requested_features) in &member_features {+            let fvs = self.fvs_from_requested(member.package_id(), requested_features);+            self.activate_pkg(member.package_id(), &fvs, false)?;+        }+        Ok(())+    }++    fn activate_pkg(+        &mut self,+        pkg_id: PackageId,+        fvs: &[FeatureValue],+        for_build: bool,+    ) -> CargoResult<()> {+        // Add an empty entry to ensure everything is covered. This is intended for+        // finding bugs where the resolver missed something it should have visited.+        // Remove this in the future if `activated_features` uses an empty default.+        self.activated_features+            .entry((pkg_id, for_build))+            .or_insert_with(BTreeSet::new);+        for fv in fvs {+            self.activate_fv(pkg_id, fv, for_build)?;+        }+        if !self.processed_deps.insert((pkg_id, for_build)) {

I think it is fine. After resolving deep-dependency once, other packages that add features to that deep-dependency will do so via FeatureValue::CrateFeature in activate_fv. This in turn checks if it is activating an optional dependency, and will recurse into that if necessary.

This is kinda fundamental to the way this is organized. If you notice, a few lines below it always skips optional dependencies. Whenever a dependency is encountered that enables an optional feature, it will enable it and recurse right away.

I believe this is structured somewhat differently from how the dependency resolver works. Presumably because it is figuring out the features as it goes along, and doesn't have the full graph built, yet.

ehuss

comment created time in 3 days

pull request commentrust-lang/cargo

Modified the help information of cargo-rustc

Thanks! @bors r+

KaneGreen

comment created time in 3 days

push eventehuss/cargo

Eric Huss

commit sha efed107648156d6c6f76bc89c58062bddbe30c62

Copy license-file into package if outside of root.

view details

push time in 3 days

pull request commentrust-lang/cargo

Add an option to include crate versions to the generated docs

Looks great!

Can you add a section to the bottom of unstable.md briefly describing the feature? I created a tracking issue you can link to: https://github.com/rust-lang/cargo/issues/7907

aleksator

comment created time in 3 days

issue openedrust-lang/cargo

Tracking issue for -Z crate-versions

Implementation: #7903 Original issue: #1681

Summary

-Z crate-versions will add the crate version to cargo doc via the unstable rustdoc flag.

image

Unresolved issues

  • [ ] Need to stabilize --crate-version in rustdoc.

created time in 3 days

push eventehuss/cargo

Eric Huss

commit sha fbadd309dac6565bebbd278f1bdd385edf7058d7

Test

view details

push time in 3 days

pull request commentrust-lang/cargo

[WIP] Switch azure to macOS 10.15.

Opening this to do some testing with rust-lang's builders, which I believe are different hardware from the free microsoft hosted agents?

ehuss

comment created time in 3 days

PR opened rust-lang/cargo

[WIP] Switch azure to macOS 10.15.

Switches CI to the macOS 10.15 image. Since 32-bit support is no longer available, this changes on cross-compile testing works. I decided to use x86_64-apple-ios as a cross target, since it can easily build/link on macOS. cargo run won't work without a simulator, so some of the tests are restructured to check if cargo run is allowed. If you do have a simulator, it should Just Work. CI doesn't seem to be configured with a simulator installed, and I didn't bother to look if that would be possible (the simulators tend to be several gigabytes in size).

An alternative approach would be to use wasm as a cross target, which is also fairly easy to support. But wasm is a sufficiently different target that it can cause some issues in some tests, and is a bit harder to run as an executable.

This also adds some more help text on how to configure cross-compile tests.

Rustup is now installed on macOS by default, so no need to install it. Unfortunately self-updates are not allowed, but hopefully that won't be an issue.

+307 -202

0 comment

8 changed files

pr created time in 3 days

push eventehuss/cargo

Eric Huss

commit sha 1d5d7a269fbff61a70b36c85e004351b6d761403

Support `--config path_to_config.toml` cli syntax.

view details

bors

commit sha e0678fbbf8bde3b7762cfe9a8ab8a6a8a88bf139

Auto merge of #7901 - ehuss:config-cli-path, r=alexcrichton Support `--config path_to_config.toml` cli syntax. Updates the `--config` flag so that if the argument appears to be a file, it will load the file. cc #7722, #7723

view details

Eric Huss

commit sha 7528bde3c730cbf11aa3dcb5897e960d6f83226b

Switch azure to macOS 10.15.

view details

push time in 3 days

issue commentrust-lang/cargo

Update CI for upcoming macOS changes

Do you think this is a viable way forward maybe?

I ran some tests with Cargo's full testsuite using the rename trick, but I still got failures. ☹️

ehuss

comment created time in 3 days

PR opened rust-lang/cargo

Better support for license-file.

This adds some changes to how cargo package and cargo publish handle the license-file field. This also incorporates some refactoring which hopefully makes the code a little clearer and straightforward, but which also resulted in some minor behavior changes.

  • Warn if license-file points to a non-existent file.
  • Automatically include license-file, even if it is not listed in the package.include list (similar to how Cargo.toml/lock are automatically included).
  • If license-file points outside of the package root, copy the file to the package root (and rewrite the field in Cargo.toml).
  • Files are now sorted when archived.
  • Archiving: Cargo.toml.orig is explicitly printed where before it did not report that.
  • cargo package --list now shows Cargo.toml.orig where before it was not reported.

Closes #3537 Closes #7830

+495 -207

0 comment

7 changed files

pr created time in 3 days

push eventehuss/cargo

Eric Huss

commit sha 942f4c70887aac8eaffc71add901bfe6c92bbe3c

Copy license-file into package if outside of root.

view details

push time in 3 days

PR opened rust-lang/cargo

Update for nightly rustfmt.

Most recently nightly seems to have slightly different behavior.

+6 -4

0 comment

1 changed file

pr created time in 3 days

create barnchehuss/cargo

branch : rustfmt-1.4.12-fix

created branch time in 3 days

create barnchehuss/cargo

branch : license-file-updates

created branch time in 3 days

pull request commentrust-lang/rust

ci: switch macOS builders to 10.15

That's a month away? We're working on a fix now, I don't expect it to take that long.

If this merges now, there is a chance that the majority of PRs will fail. Have you done multiple tests on the rust-lang builders to see what the error rate is?

pietroalbini

comment created time in 3 days

pull request commentrust-lang/rust

ci: switch macOS builders to 10.15

I would be concerned that without Cargo fixed, this will cause frequent failures. I'm not sure if the rust-lang macos machines are different enough to make much of a difference, but on the free microsoft hosted ones I saw a lot of errors.

pietroalbini

comment created time in 3 days

issue commentrust-lang/cargo

Update CI for upcoming macOS changes

How quickly does it reproduce for you?

Usually takes anywhere from a few seconds to 5 minutes. I run my tests for 10-20 minutes just to make sure.

I suspect it is very sensitive to timing. The system I'm running tests on is kinda old (~6 years). You can maybe tweak the parallelism to match the number of cpus (I hard-coded it to 8). You can also maybe disable some CPUs to slow your machine down (Instruments > Settings > CPU).

Interestingly, I tried your rename trick and it doesn't seem to repro with that. How strange!

I tested with HFS, and I'm unable to repro on that, so it does seem to be related to APFS! I also verified that the 10.15 image on azure switched to apfs (which doesn't seem to be documented anywhere 😠).

@Mark-Simulacrum regarding the CoW stuff, I'm not too familiar with APFS. However, my understanding is that CoW only works if the program uses special options. That is, the copyfile(3) function with the COPYFILE_CLONE flag. Is that correct, or is there something else regarding CoW? I considered trying that, but I think it is only available in very recent versions of macos, and I don't know if it is worth monkeying around with that.

ehuss

comment created time in 4 days

issue commentrust-lang/cargo

cargo returns outdated warnings

This is a known issue that will be fixed by #7533.

You can use cargo clippy-preview on nightly to avoid this for now.

matthiaskrgr

comment created time in 4 days

push eventehuss/cargo

Eric Huss

commit sha 3489428921671b274b08ebbabd00128d56ebaa00

Set an environment variable for tests to find executables.

view details

Eric Huss

commit sha 499f917c03f4a4956b83bb497f247e75311528ee

Switch to case-sensitive environment variable.

view details

Eric Huss

commit sha 4cf531f5a6939fb92c095dd76e252bf778815b01

Add more docs on CARGO_BIN_EXE_.

view details

Josh Triplett

commit sha e84a4ed6d02293034380761461b09241488070fe

Keep environment variables in a BTreeMap to preserve sort order This prevents verbose output from varying between runs due to HashMap (non-)ordering.

view details

bors

commit sha c31bd9d8aceab993939c9c579c78d30db2371523

Auto merge of #7877 - joshtriplett:env-order, r=ehuss Keep environment variables in a BTreeMap to preserve sort order This prevents verbose output from varying between runs due to HashMap (non-)ordering.

view details

Esteban Küber

commit sha e0787ec2b3feba19e1537265ef398d6f300a3431

Modify test to make `rustc` PR mergeable Modify a test to be less succeptible to failure for wording changes.

view details

bors

commit sha a491aa7179bbcab817d937af33e1b91bf214c316

Auto merge of #7883 - estebank:change-test, r=ehuss Modify test to make `rustc` PR mergeable Modify a test to be less succeptible to failure for wording changes.

view details

Josh Stone

commit sha 9c8b4dcd3e9c3e21d7ed23345e8848291b162ae0

Link the licenses into crates/cargo-platform The licenses should be included in the package published on crates.io

view details

bors

commit sha 17855e583f2079bee0c6fe885d9f0af6c1aa10d2

Auto merge of #7886 - cuviper:cargo-platform-licenses, r=ehuss Link the licenses into crates/cargo-platform The licenses should be included in the package published on crates.io

view details

Eric Huss

commit sha 677b24adad67f591d50bcb0d9ccfad79b9460409

Add some extra fingerprint debug information.

view details

bors

commit sha 1492e5723e6c9f13c39fc242996a18564e912600

Auto merge of #7888 - ehuss:fingerprint-debug, r=Eh2406 Add some extra fingerprint debug information. There have been some situations where the existing log info was not sufficient to understand the cause of a rebuild. I hope that this additional information can help with debugging problems.

view details

Eric Huss

commit sha 75fa342d5971bf8fa24b203691443ea7a7f877d4

Fix inaccurate doc comment on `env_args`.

view details

Eric Huss

commit sha 25275b07bb3a2b19f0955445c09c13b2b9973b87

Add new/old rustflags to fingerprint log.

view details

bors

commit sha 1fa0f1b98f0f90dd0e261be43758d1a08c9db0f4

Auto merge of #7889 - ehuss:fix-env_args-doc, r=Eh2406 Fix inaccurate doc comment on `env_args`.

view details

bors

commit sha 5f079721035b236e3bff8c026de3f807694b9f6f

Auto merge of #7890 - ehuss:fingerprint-log-rustflags, r=Eh2406 Add new/old rustflags to fingerprint log. Follow up to #7888. Due to a conversation with someone I had with Discord who was having trouble determining why something was rebuilding.

view details

Eric Huss

commit sha fd258634c904d4a36cfbc8a176440db7faac3eff

Improvements to StringList config handling.

view details

bors

commit sha 914e31d7b27248617c7e9fbc862476256a86d3e8

Auto merge of #7891 - ehuss:stringlist-fixes, r=Eh2406 Improvements to StringList config handling. `StringList` was using an untagged enum to deserialize a string or list. Unfortunately, serde does not handle untagged enums very well. The error messages are not very good, and it doesn't interact with untyped deserializers (like our environment variables). This switches it to a newtype struct, and then has hard-coded support for it in the deserializer. This fixes some deserialization errors (like treating `true` as a boolean) and provides better error messages. `StringList` is currently used for `build.rustflags`, `target.*.rustflags`, and `target.*.runner`. Fixes #7780 Fixes #7781

view details

Eric Huss

commit sha 0d44a8267bf503645ceb5f5853abdd4cce407dc8

Rework internal errors.

view details

bors

commit sha 74f2b400d2be43da798f99f94957d359bc223988

Auto merge of #7896 - ehuss:internal-errors, r=alexcrichton Rework internal errors. This changes the behavior of "internal" errors, which were previously hidden and only displayed with `--verbose`. The changes here: - `internal` now means "a cargo bug", and is always displayed and requests that the user file a bug report. - Added `VerboseError` to signify an error that should only be displayed with `--verbose`. This is only used in one place, to display the `rustc` compiler command if the compiler exited with a normal error code (i.e. not a crash). - Audited the uses of internal errors, and promoted some to normal errors, as they seemed to contain useful information, but weren't necessarily bugs in cargo. - Added some details to some errors. - Sometimes the "run with --verbose" message wasn't being printed when I think it should. This happened when rustc failed while other rustc processes were running. Another case was with `cargo install` installing multiple packages, and one of them fails.

view details

bors

commit sha e02974078a692d7484f510eaec0e88d1b6cc0203

Auto merge of #7697 - ehuss:bin-test-env, r=alexcrichton Set an environment variable for tests to find executables. This adds the environment variable `CARGO_BIN_EXE_<name>` so that integration tests can find binaries to execute, instead of doing things like inspecting `env::current_exe()`. The use of uppercase is primarily motivated by Windows whose Rust implementation behaves in a strange way. It always ascii-upper-cases keys to implement case-insensitive matching (which loses the original case). Seems less likely to result in confusion? Closes #5758.

view details

push time in 4 days

PR opened rust-lang/rls

Update cargo

Cargo has switched to BTreeMap for env vars for reproducibility.

Note: I had to update rustfmt-nightly to get the lock file to update properly. I'm not sure what happened with #1631, but there were a lot of conflicts with the rustc-ap-* crates pulling in two different versions. It looks like rust-lang/rust is already updated to the correct version.

+231 -111

0 comment

5 changed files

pr created time in 4 days

more