Added aliases to subcommand typo suggestions. #7288

Update from rust-lang/rust#63637.

…crichton Allow using 'config.toml' instead of just 'config' files. Fixes rust-lang#7273 Note that this change only makes 'config.toml' optional to use instead of 'config'. If both exist, we will print a warning and prefer 'config', since that would be the existing behavior if both existed today. We should also consider a separate change to make config.toml the default and update docs, etc.

Basic standard library support. This is not intended to be useful to anyone. If people want to try it, that's great, but do not rely on this. This is only for experimenting and setting up for future work. This adds a flag `-Zbuild-std` to build the standard library with a project. The flag can also take optional comma-separated crate names, like `-Zbuild-std=core`. Default is `std,core,panic_unwind,compiler_builtins`. Closes rust-lang/wg-cargo-std-aware#10. Note: I can probably break some of the refactoring into smaller PRs if necessary. ## Overview The general concept here is to use two resolvers, and to combine everything in the Unit graph. There are a number of changes to support this: - A synthetic workspace for the standard library is created to set up the patches and members correctly. - Decouple `unit_dependencies` from `Context` to make it easier to manage. - Add `features` to `Unit` to keep it unique and to remove the need to query a resolver. - Add a `UnitDep` struct which encodes the edges between `Unit`s. This removes the need to query a resolver for `extern_crate_name` and `public`. - Remove `Resolver` from `BuildContext` to avoid any confusion and to keep the complexity focused in `unit_dependencies`. - Remove `Links` from `Context` since it used the resolver. Adjusted so that instead of checking links at runtime, they are all checked at once in the beginning. Note that it does not check links for the standard lib, but it should be safe? I think `compiler-rt` is the only `links`? I currently went with a strategy of linking the standard library dependencies using `--extern` (instead of `--sysroot` or `-L`). This has some benefits but some significant drawbacks. See below for some questions. ## For future PRs - Add Cargo.toml support. See rust-lang/wg-cargo-std-aware#5 - Source is not downloaded. It assumes you have run `rustup component add rust-src`. See rust-lang/wg-cargo-std-aware#11 - `cargo metadata` does not include any information about std. I don't know how this should work. - `cargo clean` is not std-aware. - `cargo fetch` does not fetch std dependencies. - `cargo vendor` does not vendor std dependencies. - `cargo pkgid` is not std-aware. - `--target` is required on the command-line. This should default to host-as-target. - `-p` is not std aware. - A synthetic `Cargo.toml` workspace is created which has to know about things like `rustc-std-workspace-core`. Perhaps rust-lang/rust should publish the source with this `Cargo.toml` already created? - `compiler_builtins` uses default features (pure Rust implementation, etc.). See rust-lang/wg-cargo-std-aware#15 - `compiler_builtins` may need to be built without debug assertions, see [this](https://github.com/rust-lang/rust/blob/8e917f48382c6afaf50568263b89d35fba5d98e4/src/bootstrap/bin/rustc.rs#L210-L214). Could maybe use profile overrides. - Panic issues: - `panic_abort` is not yet supported, though it should probably be easy. It could maybe look at the profile to determine which panic implementation to use? This requires more hard-coding in Cargo to know about rustc implementation details. - [This](https://github.com/rust-lang/rust/blob/8e917f48382c6afaf50568263b89d35fba5d98e4/src/bootstrap/bin/rustc.rs#L186-L201) should probably be handled where `panic` is set for `panic_abort` and `compiler_builtins`. I would like to get a test case for it. This can maybe be done with profile overrides? - Using two resolvers is quite messy and causes a lot of complications. It would be ideal if it could only use one, though that may not be possible for the foreseeable future. See rust-lang/wg-cargo-std-aware#12 - Features are hard-coded. See rust-lang/wg-cargo-std-aware#13 - Lots of various platform-specific support is not included (musl, wasi, windows-gnu, etc.). - Default `backtrace` is used with C compiler. See rust-lang/wg-cargo-std-aware#16 - Sanitizers are not built. See rust-lang/wg-cargo-std-aware#17 - proc_macro has some hacky code to synthesize its dependencies. See rust-lang/wg-cargo-std-aware#18. This may not be necessary if this uses `--sysroot` instead. - Profile overrides cause weird linker errors. That is: ```toml [profile.dev.overrides.std] opt-level = 2 ``` Using `[profile.dev.overrides."*"]` works. I tried fiddling with it, but couldn't figure it out. We may also want to consider altering the syntax for profile overrides. Having to repeat the same profile for `std` and `core` and `alloc` and everything else would not be ideal. - ~~`Context::unit_deps` does not handle build overrides, see rust-lang#7215.~~ FIXED ## Questions for this PR - I went with the strategy of using `--extern` to link the standard lib. This seems to work, and I haven't found any problems, but it seems risky. It also forces Cargo to know about certain implicit dependencies like `compiler_builtins` and `panic_*`. The alternative is to create a sysroot and copy all the crates to that directory and pass `--sysroot`. However, this is complicated by pipelining, which would require special support to copy `.rmeta` files when they are generated. Let me know if you think I should use a different strategy. I'm on the fence here, and I think using `--sysroot` may be safer, but adds more complexity. - As an aside, if rustc ever tries to grab a crate from sysroot that was not passed in via `--extern`, then it results in duplicate lang items. For example, saying `extern crate proc_macro;` without specifying `proc_macro` as a dependency. We could prevent rustc from ever trying by passing `--sysroot=/nonexistent` to prevent it from trying. Or add an equivalent flag to rustc. - How should this be tested? I added a janky integration test, but it has some drawbacks. It requires internet access. It is slow. Since it is slow, it reuses the same target directory for multiple tests which makes it awkward to work with. - What interesting things are there to test? - We may want to disable the test before merging if it seems too annoying to make it the default. It requires rust-src to be downloaded, and takes several minutes to run, and are somewhat platform-dependent. - How to test that it is actually linking the correct standard library? I did tests locally with a modified libcore, but I can't think of a good way to do that in the test suite. - I did not add `__CARGO_DEFAULT_LIB_METADATA` to the hash. I had a hard time coming up with a test case where it would matter. - My only thought is that it is a problem because libstd includes a dylib, which prevents the hash from being added to the filename. It does cause recompiles when switching between compilers, for example, when it normally wouldn't. - Very dumb question: Why exactly does libstd include a dylib? This can cause issues (see rust-lang/rust#56443). - This should probably change, but I want to better understand it first. - The `bin_nostd` test needs to link libc on linux, and I'm not sure I understand why. I'm concerned there is something wrong there. libstd does not do that AFAIK.

- man pages - Slightly reword deprecation notice. - Include --all in man pages. - Update some additional usages in code and docs.

Rename `--all` to `--workspace` ## Background close: rust-lang#6977 ## Description - Warn when using the 'all' option - Changed help text

don't need to copy this string This removes a `String::clone` that I noticed when profiling no-op builds of cargo, benchmarks show a barely visible improvement. Looks like it was added in rust-lang#6880, but I am not sure why.

`map_dependencies` is doing a deep clone, so lets make it cheaper This removes a `FeatureMap::clone` that I noticed when profiling no-op builds of cargo, benchmarks show a ~5% improvement. Looks like rust-lang#6880 means that there is a ref to every `Summery` so the `Rc::make_mut` dose a deep clone.

…chton guide: add section about the cargo home This PR adds a section about the $CARGO_HOME to the cargo guide. [Rendered](https://github.com/matthiaskrgr/cargo/blob/cargo_home_doc/src/doc/src/guide/cargo-home.md)

Fix some man pages where the files weren't rebuilt. A few recent PRs edited the wrong files.

Fix test for changes in plugin API. Updates for rust-lang/rust#64041

doc: capitalization change for consistency.

These two have been stabilized for all targets like `std` so if `std` is requested let's be sure to make them available to other crates as well.

Add `alloc` and `proc_macro` to libstd crates These two have been stabilized for all targets like `std` so if `std` is requested let's be sure to make them available to other crates as well.

Use the `set_require_optional_deps(false)` escape hatch to avoid resolving optional dependencies for libstd. While it doesn't really matter a huge amount either way there's no need for us to generate resolution nodes for things like `rand` just to throw them away because they're never used. Closes rust-lang/wg-cargo-std-aware#37

Don't resolve std's optional dependencies Use the `set_require_optional_deps(false)` escape hatch to avoid resolving optional dependencies for libstd. While it doesn't really matter a huge amount either way there's no need for us to generate resolution nodes for things like `rand` just to throw them away because they're never used. Closes rust-lang/wg-cargo-std-aware#37

Use `let _ = ` to ignore some values that are `#[must_use]` when checking nested data types.

I recently added `jobserver` support to the `cc` crate and ended up running afoul of a `jobserver` quirk on Windows. Due to how it's implemented, on Windows you can't actually add more than the intial number of tokens to the jobserver (it uses an IPC semaphore). On Unix, however, you can since you're just writing bytes into a pipe. In `cc`, however, I found it convenient to control parallelism by simply releasing a token before the parallel loop, then reacquiring the token after the loop. That way the loop just has to acquire a token for each job it wants to spawn and then release it when the job finishes. This is a bit simpler than trying to juggle the "implicit token" all over the place as well as coordinating its use. It's technically invalid because it allows a brief moment of `N+1` parallelism since we release a token and then do a bit of work to acquire a new token, but that's hopefully not really the end of the world. In any case this commit updates Cargo's creation of a jobserver to create it with `N` tokens instead of `N-1`. The same semantics are preserved where Cargo then immediately acquires one of the tokens, but the difference is that this "implicit token" can be released back to the jobserver pool, unlike before.

…crichton Explicitly ignore some results Use `let _ = ` to ignore some values that are `#[must_use]` when checking nested data types. This is necessary to compile cargo without warnings under rust-lang/rust#62262.

This should make the readme display on cargos crates.io page

…ichton add readme key to cargos manifest. This should make the readme display on cargos crates.io page

Home docs: fix broken links, misspellings, style fixes, clarifications. A broken link blocking upstream update. Made some other fixes while reviewing it.

Closes rust-lang/wg-cargo-std-aware#41

Add initial documentation for `-Z build-std` Closes rust-lang/wg-cargo-std-aware#41

This commit forcibly prevents Cargo from building the `std` crate as a `dylib`, even though libstd upstream lists a `dylib` crate type. We ideally want a first-class feature for doing this one day, but for now we can just hack around with the manifests to ensure that the `dylib` crate type never shows up. Note that this is only supported for libstd, and it's also all part of the unstable details of building std. Closes rust-lang/wg-cargo-std-aware#35

Create a jobserver with N tokens, not N-1 I recently added `jobserver` support to the `cc` crate and ended up running afoul of a `jobserver` quirk on Windows. Due to how it's implemented, on Windows you can't actually add more than the intial number of tokens to the jobserver (it uses an IPC semaphore). On Unix, however, you can since you're just writing bytes into a pipe. In `cc`, however, I found it convenient to control parallelism by simply releasing a token before the parallel loop, then reacquiring the token after the loop. That way the loop just has to acquire a token for each job it wants to spawn and then release it when the job finishes. This is a bit simpler than trying to juggle the "implicit token" all over the place as well as coordinating its use. It's technically invalid because it allows a brief moment of `N+1` parallelism since we release a token and then do a bit of work to acquire a new token, but that's hopefully not really the end of the world. In any case this commit updates Cargo's creation of a jobserver to create it with `N` tokens instead of `N-1`. The same semantics are preserved where Cargo then immediately acquires one of the tokens, but the difference is that this "implicit token" can be released back to the jobserver pool, unlike before.

This supports the corresponding rustc PR. To enable rustdoc to properly document macros, we mirror the '--crate-type' flag used by rustc. Currently, all crate types other than 'proc-macro' are ignored by rustdoc.

Don't build libstd as a `dylib` This commit forcibly prevents Cargo from building the `std` crate as a `dylib`, even though libstd upstream lists a `dylib` crate type. We ideally want a first-class feature for doing this one day, but for now we can just hack around with the manifests to ensure that the `dylib` crate type never shows up. Note that this is only supported for libstd, and it's also all part of the unstable details of building std. Closes rust-lang/wg-cargo-std-aware#35

The previous warning was detected at the decoding level, with the test removed in an earlier commit. Here it is brought back, in the custom profile processing level. Keeping this warning will serve to prevent confusion, when people expect to affect the 'debug' directory via the 'debug' profile to no effect, where in fact the 'dev' profile is the profile that they opted to change.

This suite of tests verifies various cases around the 'inherits' keyword, and also verifies the relationship between profile overrides and custom profiles.

@alexcrichton

…ichton Include the publish field in cargo-metadata output r? @alexcrichton

…here.

This avoids issues when the target name contains the crate type, e.g. `bin` in `custom-bin-target.json`.

The custom target name contains the crate type `bin`.

Parse `unsupported crate type` error more tightly Fixes rust-lang#7363 Instead of adding a new test, we could also rename the target file in an existing custom target test if you prefer.

…orks, r=alexcrichton [-Zbuild-std] Only build libtest when libstd is built Currently `libtest` is always compiled when a compilation unit uses a test harness. This implicitly adds builds the standard library too because `libtest` depends on it. This breaks the use of custom test frameworks in `no_std` crates as reported in rust-lang#7216 (comment). This pull request fixes the issue by only building `libtest` if `libstd` is built. This makes sense in my opinion because when the user explicitly specified `-Zbuild-std=core`, they probably don't want to build the full standard library and rather get a compilation error when they accidentally use `libtest`.

No longer needed on stable!

…inal, r=alexcrichton Pass --crate-type to rustdoc This supports the [corresponding rustc PR](rust-lang/rust#62855). To enable rustdoc to properly document macros, we pass a new flag '--proc-macro-crate' when documenting a proc-macro crate. This causes rustdoc to enable the proc-macro compiler logic that runs when rustc is building a proc-macro crate. This flag is essentially a more restricted version of '--crate-type=proc-macro'. I didn't think it was necessary to pass the full '--crate-type' flag to rustdoc, when only two options would ever be used (proc-macro vs anything else).

This shouldn't ever happen during normal development, but happens from time to time while developing Cargo itself. Closes rust-lang#6433

Don't hang when Cargo's worker threads panic This shouldn't ever happen during normal development, but happens from time to time while developing Cargo itself. Closes rust-lang#6433

This commit is aimed directly at rust-lang/wg-cargo-std-aware#33 and in general making the `-Zbuild-std` tests more robust. The main change here is that a new source tree is checked in, `tests/testsuite/mock-std`, which mirrors rust-lang/rust's own tree for libstd. This mock tree is as empty as it can be, ideally duplicating almost nothing but for not requiring duplication of Cargo metadata about patches and such. The end result here looks like: * All `-Zbuild-std` tests are now run in parallel * All tests run much more quickly since they're compiling tiny crates instead of actually compiling libstd/libcore * No tests require network access * We verify that crates have access to the "custom" libraries that we build Coverage of tests is not currently expanded, but it's hoped that we could add that shortly afterwards. Coverage has actually gone down slightly since the custom target test was commented out temporarily and the full integration test of running `-Zbuild-std` isn't run on CI any more. Closes rust-lang/wg-cargo-std-aware#33

Extract out all our test support code to its own standalone crate so it can be shared between multiple test suites if necessary.

Only run these tests on one CI builder (not all platforms) though. This is extremely resource intensive since it rebuilds libstd. Currently this does not share a build directly like before because the number of tests are supposed to be small, but if necessary we can add that in later too.

Remove another `FnBox` trait No longer needed on stable!

Improve test suite for `-Zbuild-std` This commit is aimed directly at rust-lang/wg-cargo-std-aware#33 and in general making the `-Zbuild-std` tests more robust. The main change here is that a new source tree is checked in, `tests/testsuite/mock-std`, which mirrors rust-lang/rust's own tree for libstd. This mock tree is as empty as it can be, ideally duplicating almost nothing but for not requiring duplication of Cargo metadata about patches and such. The end result here looks like: * All `-Zbuild-std` tests are now run in parallel * All tests run much more quickly since they're compiling tiny crates instead of actually compiling libstd/libcore * No tests require network access * We verify that crates have access to the "custom" libraries that we build Coverage of tests is not currently expanded, but it's hoped that we could add that shortly afterwards. Coverage has actually gone down slightly since the custom target test was commented out temporarily and the full integration test of running `-Zbuild-std` isn't run on CI any more. Closes rust-lang/wg-cargo-std-aware#33

"could not compile ..." matches other Cargo and rustc errors and warnings better.

Build script updates during execution can change the memoized hash of a `Fingerprint`, and while previously we cleared out a single build script's memoized hash we forgot to clear out everything that depended on it as well. This commit pessimistically clears out all `Fingerprint` memoized hashes just before building to ensure that during the build everything has the most up-to-date view of the world, and when build scripts change fingerprints everything that depends on them won't have run yet. Closes rust-lang#7362

…d, r=alexcrichton Uncapitalize "Could not compile" error message "could not compile ..." matches other Cargo and rustc errors and warnings better.

Clear out memoized hashes before building crates Build script updates during execution can change the memoized hash of a `Fingerprint`, and while previously we cleared out a single build script's memoized hash we forgot to clear out everything that depended on it as well. This commit pessimistically clears out all `Fingerprint` memoized hashes just before building to ensure that during the build everything has the most up-to-date view of the world, and when build scripts change fingerprints everything that depends on them won't have run yet. Closes rust-lang#7362

This commit addresses an issue with how the resolver processes `[patch]` annotations in manifests and lock files. Previously the resolver would use the raw `Url` coming out of a manifest, but the rest of resolution, when comparing `SourceId`, uses a canonical form of a `Url` rather than the actual raw `Url`. This ended up causing discrepancies like those found in rust-lang#7282. To fix the issue all `patch` intermediate storage in the resolver uses a newly-added `CanonicalUrl` type instead of a `Url`. This `CanonicalUrl` is then also used throughout the codebase, and all lookups in the resolver as switched to using `CanonicalUrl` instead of `Url`, which... Closes rust-lang#7282

Work with canonical URLs in `[patch]` This commit addresses an issue with how the resolver processes `[patch]` annotations in manifests and lock files. Previously the resolver would use the raw `Url` coming out of a manifest, but the rest of resolution, when comparing `SourceId`, uses a canonical form of a `Url` rather than the actual raw `Url`. This ended up causing discrepancies like those found in rust-lang#7282. To fix the issue all `patch` intermediate storage in the resolver uses a newly-added `CanonicalUrl` type instead of a `Url`. This `CanonicalUrl` is then also used throughout the codebase, and all lookups in the resolver as switched to using `CanonicalUrl` instead of `Url`, which... Closes rust-lang#7282

Also add some more features.

Ends up meaning that in full crate compiles that `url` doesn't wait for `serde` to finish, which in turn enables crates like `git2` to start sooner!

Experiment: Create timing report. This is just an experiment, so I'm not sure if we'll want to merge it. This adds an HTML report which gets saved to disk when the build is finished. It is primarily geared for identifying slow dependencies, and for visualizing how pipelining affects the build. Here's an example: https://ehuss.github.io/cargo-timing.html You can mouse over the blocks to highlight the reverse-dependencies that are released when a unit finishes. `syn` is a really good example. It does a few other things, like displaying a message after each unit is finished. See the docs for more information.

Don't require the `serde` feature of `url` Ends up meaning that in full crate compiles that `url` doesn't wait for `serde` to finish, which in turn enables crates like `git2` to start sooner!

Updates the requirements on [hex](https://github.com/KokaKiwi/rust-hex) to permit the latest version. - [Release notes](https://github.com/KokaKiwi/rust-hex/releases) - [Commits](https://github.com/KokaKiwi/rust-hex/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

This commit updates the graph generated by `-Ztimings` to include CPU usage information, ideally showing how Cargo/rustc used the CPU throughout the build, ideally seeing nice periods of parallelism and also periods of missed parallelism.

…alexcrichton Update hex requirement from 0.3 to 0.4 Updates the requirements on [hex](https://github.com/KokaKiwi/rust-hex) to permit the latest version. <details> <summary>Commits</summary> - See full diff in [compare view](https://github.com/KokaKiwi/rust-hex/commits) </details> <br /> Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language - `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com): - Update frequency (including time of day and day of week) - Pull request limits (per update run and/or open at any time) - Automerge options (never/patch/minor, and dev/runtime dependencies) - Out-of-range updates (receive only lockfile updates, if desired) - Security updates (receive only security updates, if desired) Finally, you can contact us by mentioning @dependabot. </details>

Added ability to crosscompile doctests This commit adds the ability to cross-compile and run doctests. Like before cargo checks if target == host, the difference is that if there is a runtool defined in config.toml, it passes the information forward to rustdoc so that it can run the doctests with that tool. If no tool is defined and the target != host, cargo instead displays a message that doctests will not be compiled because of the missing runtool. See [here](rust-lang/rust#60387) for the companion PR in the rust project that modifies rustdoc to accept the relevant options as well as allow ignoring doctests on a per target level. Partially resolves [rust-lang#6460](rust-lang#6460) See [here](rust-lang#7040) for the tracking issue.

Fix some duplicate artifact problems. The recent cargo update failed because of duplicate artifacts with rls. `tar` should mirror what the main manifest contains. Partially revert rust-lang#7374 by adding `serde` back to `url`. Unfortunately the `lsp-types` crate (used by rls) needs this feature. Unless anyone has a good idea on how to handle that, I don't think it can be removed. Unblocks cargo update, which I'd like to get done before the beta branch.

Usage of `CARGO_PROFILE_*` is generating unexpected warnings in tests in rust-lang/rust#64316 so let's just blanket remove every env var that has a `CARGO_*` prefix which generally means Cargo-specific env vars. Tests practically all assume that they have blank configs right now.

This commit removes Cargo's dependency on `winapi` 0.2 which takes an excessively long time to build, slowing down Windows builds. The `winapi` 0.2 crate was pulled in via a dependency chain that looked like: cargo \- crates-io \- http \- bytes \- iovec \- winapi 0.2 The fix implemented here was to remove the `http` crate dependency from `crates-io` which is only used for rendering status codes, but it's easy enough to inline that function locally.

Remove dependency on `winapi` 0.2 This commit removes Cargo's dependency on `winapi` 0.2 which takes an excessively long time to build, slowing down Windows builds. The `winapi` 0.2 crate was pulled in via a dependency chain that looked like: cargo \- crates-io \- http \- bytes \- iovec \- winapi 0.2 The fix implemented here was to remove the `http` crate dependency from `crates-io` which is only used for rendering status codes, but it's easy enough to inline that function locally.

Remove all `CARGO_*` env vars in tests Usage of `CARGO_PROFILE_*` is generating unexpected warnings in tests in rust-lang/rust#64316 so let's just blanket remove every env var that has a `CARGO_*` prefix which generally means Cargo-specific env vars. Tests practically all assume that they have blank configs right now.

Update `-Ztimings` with CPU usage information This commit updates the graph generated by `-Ztimings` to include CPU usage information, ideally showing how Cargo/rustc used the CPU throughout the build, ideally seeing nice periods of parallelism and also periods of missed parallelism.

change the priority in witch we build crates On my windows 4 core, this made clean builds (of 3596cb8) go from 257-223s to 210-205s. So that looks like an improvement.

Extract Platform to a separate crate. This moves the `Platform`, `Cfg`, `CfgExpr` types to a new crate named "cargo-platform". The intent here is to give users of `cargo_metadata` a way of parsing and inspecting cargo's platform values. Along the way, I rewrote the error handling to remove `failure`, and to slightly improve the output. I'm having doubts whether or not this is a good idea. As you can see from the `examples/matches.rs` example, it is nontrivial to use this (which also misses cargo's config values and environment variables). I don't know if anyone will actually use this. If this doesn't seem to have value, I would suggest closing it. I've also included a sample script, `publish.py`, for publishing cargo itself. I suspect it will need tweaking, but I figure it would be a start and open for feedback.

Integration tests were waiting for binaries to finish building due to a minor logic error.

Fix integration tests waiting for binaries to finish. Integration tests were waiting for binaries to finish building due to a minor logic error. Fixes rust-lang#7393

@alexcrichton

…-docs, r=alexcrichton Add documentation for the -Zdoctest-xcompile feature @alexcrichton This adds the documentation for the `doctest-xcompile` feature that (woops) didn't make it into the first pr

- Cap the max width to 4096. This is still quite large, but should help for some large graphs failing to display for using too much memory. - Don't allow labels to overflow past the right side of the graph. - Fix issue for very fast builds causing an error because there aren't enough CPU_USAGE entries. - Fix bug where `split_ticks` would enter an infinite loop (caused by small scale values). Added a counter to abort in case there are any other bugs.

Fix -Ztimings with doc tests. `cargo test -Ztimings` would crash if you have any doc tests. This is because the `Doctest` mode unit doesn't generate any artifacts, so a map lookup was failing. This also adds a basic test just to ensure it works.

-Ztimings: show max jobs/cpus <img width="295" alt="image" src="https://user-images.githubusercontent.com/43198/65363872-f611a280-dbc2-11e9-8abc-bb5e6e0966d0.png">

Fix some rendering issues with -Ztimings. - Cap the max width to 4096. This is still quite large, but should help for some large graphs failing to display for using too much memory. - Don't allow labels to overflow past the right side of the graph. - Fix issue for very fast builds causing an error because there aren't enough CPU_USAGE entries. - Fix bug where `split_ticks` would enter an infinite loop (caused by small scale values). Added a counter to abort in case there are any other bugs. Closes rust-lang#7392 Closes rust-lang#7388

Co-Authored-By: Eric Huss <eric@huss.org>

… on it

-Ztimings: Fix more scale problems. Some more scaling fixes, causing the graph to be misaligned. Also some adjustments to how the axes are labeled in extreme cases. Closes rust-lang#7401

Fix xcompile tests. The new xcompile tests weren't checking whether or not cross-compiling is disabled. Cross doesn't work on modern macos/xcode, so these were failing for me. Also includes some minor formatting changes.

Update some unstable docs Some minor updates.

* Minimize the sysroot crates in play * Don't use build scripts to inject args * Use `RUSTC_WRAPPER` to dynamically switch `--sysroot` depending on whether we're building sysroot crates or not. * Minimize dependency graph in sysroot, only have each crate depend on a dummy crates.io crate for testing and otherwise don't depend on anything to load the desired sysroot crate directly.

Updates the requirements on [env_logger](https://github.com/sebasmagri/env_logger) to permit the latest version. - [Release notes](https://github.com/sebasmagri/env_logger/releases) - [Changelog](https://github.com/sebasmagri/env_logger/blob/master/CHANGELOG.md) - [Commits](rust-cli/env_logger@v0.6.0...v0.7.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

…0.7.0, r=Eh2406 Update env_logger requirement from 0.6.0 to 0.7.0 Updates the requirements on [env_logger](https://github.com/sebasmagri/env_logger) to permit the latest version. <details> <summary>Release notes</summary> *Sourced from [env_logger's releases](https://github.com/sebasmagri/env_logger/releases).* > ## 0.7.0 > # Key Changes > > - Indent multiline messages by default > - Support more timestamp precision > - Update to the 2018 edition > > # Changes to minimum Rust > > The minimum version of Rust required has been set at `1.31.0`. We may change this in patch versions, but will always flag it in the release notes here. > > You can always check the `.travis.yml` file to see the current minimum supported version. > > # Contributions > > - [@&rust-lang#8203;95ulisse](https://github.com/95ulisse) [Indentation for multiline log messages](https://github-redirect.dependabot.com/sebasmagri/env_logger/pull/134) > - [@&rust-lang#8203;oherrala](https://github.com/oherrala) [Add more timestamp precisions](https://github-redirect.dependabot.com/sebasmagri/env_logger/pull/140) > - [Update to 2018 edition](https://github-redirect.dependabot.com/sebasmagri/env_logger/pull/142) </details> <details> <summary>Commits</summary> - [`424f031`](rust-cli/env_logger@424f031) Merge pull request [rust-lang#143](https://github-redirect.dependabot.com/sebasmagri/env_logger/issues/143) from KodrAus/cargo/0.7.0 - [`058655e`](rust-cli/env_logger@058655e) prepare for 0.7.0 release - [`bfac641`](rust-cli/env_logger@bfac641) Merge pull request [rust-lang#142](https://github-redirect.dependabot.com/sebasmagri/env_logger/issues/142) from KodrAus/feat/2018 - [`ef10fa5`](rust-cli/env_logger@ef10fa5) use specific log version - [`dc65e48`](rust-cli/env_logger@dc65e48) bump msrv to 1.31.0 for editions - [`8209524`](rust-cli/env_logger@8209524) update to 2018 edition - [`7105e63`](rust-cli/env_logger@7105e63) make breaking changes to timestamp API - [`75911d7`](rust-cli/env_logger@75911d7) Merge pull request [rust-lang#140](https://github-redirect.dependabot.com/sebasmagri/env_logger/issues/140) from oherrala/timestamp-formats - [`95cd4ed`](rust-cli/env_logger@95cd4ed) Trick the compiler to think we are using timestamp - [`92a5b2d`](rust-cli/env_logger@92a5b2d) Add more timestamp precisions - Additional commits viewable in [compare view](rust-cli/env_logger@v0.6.0...v0.7.0) </details> <br /> Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language - `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com): - Update frequency (including time of day and day of week) - Pull request limits (per update run and/or open at any time) - Automerge options (never/patch/minor, and dev/runtime dependencies) - Out-of-range updates (receive only lockfile updates, if desired) - Security updates (receive only security updates, if desired) Finally, you can contact us by mentioning @dependabot. </details>

Fixes an accidental regression from rust-lang#7084 where `--features a b` was erroneously mistinterpreted as `--features "a b"`. Closes rust-lang#7418

…r=ehuss Fix interpretation of `--features a b` on the CLI Fixes an accidental regression from rust-lang#7084 where `--features a b` was erroneously mistinterpreted as `--features "a b"`. Closes rust-lang#7418

Pipelining has made its way to stable so no need to check that any more.

set -Zmtime_on_use from config or ENV This lets you set the `-Zmtime_on_use` in config, it worked for me with ```toml [unstable] mtime_on_use=true ``` I did not find the ENV that would allow work. Suggestions? Does this need tests? Closes: rust-lang#6978

This should initially help with the panic in rust-lang#7427 but doesn't solve it.

Apparently StackOverflow doesn't have all the answers. The examples there I lifted this from didn't account to call `vm_deallocate` because it looks like we're handed allocated memory! Indeed running the previous state capture in a loop it infinitely allocated memory, but now it holds steady when called in a loop.

There's very little documentation on `host_processor_info` from what I can tell, so I'm just cribbing examples I've found elsewhere on the internet. It appears that I've misinterpreted one of the out parameters of `host_processor_info` as the number of elements of an array, but it actually is just something forwarded to `vm_deallocate`.

Change build-std to use --sysroot This transitions build-std to use `--sysroot` instead of `--extern`. This is necessary because existing crates have a certain expectation of how standard library crates are exposed. It was intended that explicit dependencies in `Cargo.toml` would solve this problem, but I didn't really consider this would be a backwards-incompatible change, so using `--sysroot` is probably the best way to go, even though it's not ideal. Closes rust-lang/wg-cargo-std-aware#31 Closes rust-lang/wg-cargo-std-aware#40

Don't ever capture CPU state if timings are disabled This should initially help with the panic in rust-lang#7427 but doesn't solve it.

Fix macOS collection of CPU data There's very little documentation on `host_processor_info` from what I can tell, so I'm just cribbing examples I've found elsewhere on the internet. Turns out two things were wrong: * One is that `host_processor_info` returns allocated memory we need to deallocate. Who knew! * Next is that one of the out parameters, `cpu_info_cnt`, is only somehow related to the size of the return, but all example code appears to just read data regardless of what it is. In any case this commit reads [libuv's implementation](https://github.com/libuv/libuv/blob/040543eebf4983b1459a1e0e0e26dae68b80cc28/src/unix/darwin.c#L174-L225) which if good enough for node.js is probably good enough for us. Closes rust-lang#7427

Fix zalgo formatting. Now that 1.38 has hit stable, we can finally update this rustfmt change.

Remove dynamic detection of pipelining support Pipelining has made its way to stable so no need to check that any more.

Fixes rust-lang#6684

This commit is an internal refactoring of Cargo's compilation backend to eventually support compiling multiple target simultaneously. The original motivation for this came up in discussion of rust-lang#7297 and this has long been something I've intended to update Cargo for. Nothing in the backend currently exposes the ability to actually build multiple target simultaneously, but this should have no function change with respect to all current consumers. Eventually we'll need to refactor APIs of how you enter the compilation backend to compile for multiple targets.

Rename `Kind` to `CompileKind` to reflect that it's intended for compilation. Additionally change the `Target` variant to have a newtype `CompileTarget` instead of just being a raw string. This new `CompileTarget` type has a fallible constructor and handles custom json target files internally. Two accessors are available for `CompileTarget`, one is `rustc_target()` which goes straight to rustc and everything else uses `short_name()` which is the raw target or file stem for json files. The `short_name` is used everywhere in Cargo for all purposes like configuration, env vars, target directory naming, etc.

Otherwise, it complains: run pkg_config fail: "Failed to run `\"pkg-config\" \"--libs\" \"--cflags\" \"openssl\"`: No such file or directory (os error 2)"

fix a bunch of clippy warnings

Refactor `Kind` to carry target name in `Target` This commit is an internal refactoring of Cargo's compilation backend to eventually support compiling multiple target simultaneously. The original motivation for this came up in discussion of rust-lang#7297 and this has long been something I've intended to update Cargo for. Nothing in the backend currently exposes the ability to actually build multiple target simultaneously, but this should have no function change with respect to all current consumers. Eventually we'll need to refactor APIs of how you enter the compilation backend to compile for multiple targets.

This is a moral revert of rust-lang#6503 but not a literal code revert. This switches Cargo's behavior to avoid hashing compiler flags into `-Cmetadata` since we've now had multiple requests of excluding flags from the `-Cmetadata` hash: usage of `--remap-path-prefix` and PGO options. These options should only affect how the compiler is invoked/compiled and not radical changes such as symbol names, but symbol names are changed based on `-Cmetadata`. Instead Cargo will still track these flags internally, but only for reinvoking rustc, and not for caching separately based on rustc flags. Closes rust-lang#7416

These tests all relied on support which has now ridden to stable at this point, so let's let them run on stable!

We had a few locations where the shell was written to raw instead of through the test harness or through other captured mechanisms. This updates the test suite so testing Cargo with `--quiet` provides a nice and clean report of tests executed.

Allow a number of tests to run on stable These tests all relied on support which has now ridden to stable at this point, so let's let them run on stable!

Improve test output with `--quiet` We had a few locations where the shell was written to raw instead of through the test harness or through other captured mechanisms. This updates the test suite so testing Cargo with `--quiet` provides a nice and clean report of tests executed.

Allow gitignore of Cargo.lock with explicit `include`. If a package has an `include` list, but `Cargo.lock` is in `.gitignore`, then Cargo would complain that `Cargo.lock` is "dirty". This changes it so that ignored `Cargo.lock` is allowed, even though it is still packaged. This is under the presumption that `Cargo.lock` is machine generated, so it is not critical. This was also an unexpected regression. If you don't have an `include` list, then there is no complaint about `Cargo.lock` being dirty because Cargo uses git to deduce the file list, and `Cargo.lock` would be skipped for the dirty check (but still included in the package). Closes rust-lang#7319

…h2406 Bug7346/transitive patches Fixes rust-lang#7346. A cursory comparison between current stable and nightly shows that projects with this topology resolve similarly. If there are other behaviors I should test, I'd be happy to expand that section. This is a pretty focused change, though, so I'm not sure what else there is to break. Sorry about the delay in putting this PR together. Good news is I know more than I did last week.

Bump to 0.41.0, Update changelog

The effects over the profile used by targets are made conditional in this commit, using the old scheme if the `named-profiles` feature is disabled. This also affects the `profile_targets` tests, which now have two modes - stable, and nightly with the feature enabled.

Note: this commit does not change code, just moves it

A pub dep conflict can be made by connecting two already activated pids

…e=check` And a small cleanup in `base_profile` to make the logic parallel to the one in `get_profile`.

Go back to not hashing `RUSTFLAGS` in `-Cmetadata` This is a moral revert of rust-lang#6503 but not a literal code revert. This switches Cargo's behavior to avoid hashing compiler flags into `-Cmetadata` since we've now had multiple requests of excluding flags from the `-Cmetadata` hash: usage of `--remap-path-prefix` and PGO options. These options should only affect how the compiler is invoked/compiled and not radical changes such as symbol names, but symbol names are changed based on `-Cmetadata`. Instead Cargo will still track these flags internally, but only for reinvoking rustc, and not for caching separately based on rustc flags. Closes rust-lang#7416

add an option to specify ssl version Fixes rust-lang#6684

Support for named profiles (RFC 2678) Tracking issue: rust-lang#6988 Implementation according to the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/2678-named-custom-cargo-profiles.md).

…alexcrichton unify the quote in Cargo.toml A bit nit-picked... It tries to use double-quotes in Cargo.toml instead of single quote, that would be more uniform in this file.

As described here https://rust-lang.github.io/rust-clippy/master/#needless_borrow. rust-clippy is complaining that the related borrows are unnecessary.

…alexcrichton Public dependency refactor and re-allow backjumping There were **three** attempts at vanquishing exponential time spent in Public dependency resolution. All failures. All three started with some refactoring that seams worth saving. Specifically the data structure `public_dependency` that is used to test for Public dependency conflicts is large, tricky, and modified in line. So lets make it a type with a name and move the interactions into methods. Next each attempt needed to know how far back to jump to undo any given dependency edge. I am fairly confident that any full solution will need this functionality. I also think any solution will need a way to represent richer conflicts than the existing "is this pid active". So let's keep the `still_applies` structure from the last attempt. Last each attempt needs to pick a way to represent a Public dependency conflict. The last attempt used three facts about a situation. - `a1`: `PublicDependency(p)` witch can be read as the package `p` can see the package `a1` - `b`: `PublicDependency(p)` witch can be read as the package `p` can see the package `b` - `a2`: `PubliclyExports(b)` witch can be read as the package `b` has the package `a2` in its publick interface. This representation is good enough to allow for `backjumping`. I.E. `find_candidate` can go back several frames until the `age` when the Public dependency conflict was introduced. This optimization, added for normal dependencies in rust-lang#4834, saves the most time in practice. So having it for Public dependency conflicts is important for allowing real world experimentation of the Public dependencies feature. We will have to alter/improve/replace this representation to unlock all of the important optimizations. But I don't know one that will work for all of them and this is a major step forward. Can be read one commit at a time.

Removed redundant borrow As described here https://rust-lang.github.io/rust-clippy/master/#needless_borrow. rust-clippy is complaining that the related borrows are unnecessary.

Pulls in alexcrichton/curl-rust#304 which fixes a bug from the last curl update in rust-lang#7308. This bug was not introduced by the Cargo PR itself but rather by updating the `curl` submodule in the `curl-sys` crate. Without this bugfix all downloads of a crate will make a new connection to crates.io, which drastically increases download time since setting up a connection takes so long.

These are just wasted syscalls for our purposes, no need to issue updates to the modification/creation/access times of files we unpack!

Disable preserving mtimes on archives These are just wasted syscalls for our purposes, no need to issue updates to the modification/creation/access times of files we unpack!

@alexcrichton

Removing hash from output files when using MSVC This is the fix for rust-lang#7358 suggested by @alexcrichton . Tested and working. I see a few tests failling but seem unrelated. I'll investigate them tomorrow.

add dependencies for `pkg-config` Otherwise, it complains: run pkg_config fail: "Failed to run `\"pkg-config\" \"--libs\" \"--cflags\" \"openssl\"`: No such file or directory (os error 2)"

Update `curl-sys` dependency requirement Pulls in alexcrichton/curl-rust#304 which fixes a bug from the last curl update in rust-lang#7308. This bug was not introduced by the Cargo PR itself but rather by updating the `curl` submodule in the `curl-sys` crate. Without this bugfix all downloads of a crate will make a new connection to crates.io, which drastically increases download time since setting up a connection takes so long.

This fixes rust-lang#7471 and fixes rust-lang#7255 by preventing the .wasm file from being treated as an executable binary, so `cargo test` and `cargo run` will no longer try to execute it directly. This change is only made for emscripten, which outputs a .js file as the primary executable entry point, as opposed to other WebAssembly targets for which the .wasm file is the only output.

…chton Mark Emscripten's .wasm files auxiliary This fixes rust-lang#7471 and fixes rust-lang#7255 by preventing the .wasm file from being treated as an executable binary, so `cargo test` and `cargo run` will no longer try to execute it directly. This change is only made for Emscripten, which outputs a .js file as the primary executable entry point, as opposed to other WebAssembly targets for which the .wasm file is the only output.

This fixes an accidental regression from rust-lang#7425 where `PATH` was being augmented on Windows with the wrong search path for target/host libraries. This commit fixes the issue by simply always calculating the host/target library paths for `TargetInfo`, and then we explicitly use the same `TargetInfo` for filling out information in `Compilation`. Closes rust-lang#7475

Fix wrong directories in PATH on Windows This fixes an accidental regression from rust-lang#7425 where `PATH` was being augmented on Windows with the wrong search path for target/host libraries. This commit fixes the issue by simply always calculating the host/target library paths for `TargetInfo`, and then we explicitly use the same `TargetInfo` for filling out information in `Compilation`. Closes rust-lang#7475

Update SPDX list to 3.6 Fixes rust-lang#7477

Fixes rust-lang#7278. Adds the ability to list all available aliases (by enumerating configuration subkeys) and to provide them to the suggestion distance calculator. Also adds tests for alias suggestions.

…o suggest-alias

Commits on Sep 23, 2019

set mtime_on_use from config or ENV

Eh2406 committed Sep 23, 2019

Configuration menu

View commit details

Copy full SHA for 30df731

Browse repository at this point

Copy the full SHA

30df731 View commit details

Browse the repository at this point in the history

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added aliases to subcommand typo suggestions. #7288

Added aliases to subcommand typo suggestions. #7288

Commits on Sep 3, 2019

Commits on Sep 4, 2019

Commits on Sep 5, 2019

Commits on Sep 6, 2019

Commits on Sep 7, 2019

Commits on Sep 8, 2019

Commits on Sep 9, 2019

Commits on Sep 10, 2019

Commits on Sep 11, 2019

Commits on Sep 12, 2019

Commits on Sep 13, 2019

Commits on Sep 14, 2019

Commits on Sep 15, 2019

Commits on Sep 16, 2019

Commits on Sep 17, 2019

Commits on Sep 18, 2019

Commits on Sep 19, 2019

Commits on Sep 20, 2019

Commits on Sep 21, 2019

Commits on Sep 22, 2019

Commits on Sep 23, 2019

Commits on Sep 24, 2019

Commits on Sep 25, 2019

Commits on Sep 26, 2019

Commits on Sep 27, 2019

Commits on Sep 29, 2019

Commits on Sep 30, 2019

Commits on Oct 1, 2019

Commits on Oct 2, 2019

Commits on Oct 3, 2019

Commits on Oct 4, 2019

Commits on Oct 5, 2019