Update termcolor and fwdansi versions
A summary of the changes since 1.0.5:
- **wincolor-1.0.3**
- readme: update readme with various things
- ci: switch to GitHub Actions and bump MSRV to 1.34.0
- doc: add notes about tty detection
- doc: clarify how ANSI colors work
- **env: respect NO_COLOR environment variable**
- edition: switch to Rust 2018
- deps: drop wincolor dependency
- msrv: document minimum supported Rust version policy
- style: use rustfmt
- **api: add option to toggle terminal resetting**
- readme: test examples in README
- **bug: fix clear() and is_none()**
- **output: italicized support**
- **wincolor-1.0.2**
- wincolor: specify dual-license
Cargo book nitpick in Manifest section
The Manifest section states on the example that the
default edition is 2018, but the lines of text above
state that the default is `2015` which is not correct.
Closes#8541
The Manifest section states on the example that the
default edition is 2018, but the lines of text avobe
state that the default is `2015` which is not correct.
Closes#8541
Update features set in CI.
This removes the `curl/force-system-lib-on-osx` feature, which I don't think has been needed for a while (I believe it was fixed with https://github.com/alexcrichton/curl-rust/pull/283).
This also uses the same features for `test -p cargo-test-support` so that cargo doesn't get recompiled (saving about a minute).
Stabilize -Z crate-versions
This stabilizes the `-Z crate-versions` flag which forwards the crate version to rustdoc so it can display the version in the sidebar.
The flag in rustdoc was stabilized in 1.44.
Closes#7907
Mask out system core.autocrlf settings before resetting git repos
This fixes an issue the gecko developers noticed when vendoring
on windows. \[0\] If a user has `core.autocrlf=true` set
(a reasonable default on windows), vendoring from a git source
would cause all the newlines to be rewritten to include carriage
returns, creating churn and platform-specific results.
To fix this, we simply set the global cargo checkout's "local"
core.autocrlf value before performing a `reset`. This masks out
the system configuration without interfering with the user's
own system/project settings.
\[0\]: https://bugzilla.mozilla.org/show_bug.cgi?id=1647582
Flag git zlib errors as spurious errors
This may be a bad band-aid for now, but the goal is to help
address #8517 where this has been showing up in the wild quite a lot.
Fix the help display for the target-triple option
The `--target` option (in `cargo build` for example) had its value name and help text flipped, so it looked like;
```
--target <Build for the target triple>... TRIPLE
```
This PR swaps the `value_name` and `help` arguments for the `multi_opt` call in `command_prelude.rs`/`fn arg_target_triple()` so the value name and help text are displayed correctly.
Check workspace member existence as dir.
Cargo command fails if workspace members are set to something like `crates/*` and if there's any non project file in `crates` directory. This PR makes member discovery logic to exclude non-directory paths.
In my case, `.DS_Store` (which is made automatically by Finder on macOS) file triggered this issue.
Apply workspace.exclude to workspace.default-members.
Not sure how controversial the feature request was, it seemed easy to do, so I did it (I'm aware it's possible this won't be accepted).
Fixes#8460
This fixes an issue the gecko developers noticed when vendoring
on windows. [0] If a user has `core.autocrlf=true` set
(a reasonable default on windows), vendoring from a git source
would cause all the newlines to be rewritten to include carriage
returns, creating churn and platform-specific results.
To fix this, we simply set the global cargo checkout's "local"
core.autocrlf value before performing a `reset`. This masks out
the system configuration without interfering with the user's
own system/project settings.
[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1647582
Build host dependencies with opt-level 0 by default
This commit updates Cargo's build of host dependencies to build them
with optimization level 0 by default instead of matching the profile of
the final binary.
Since Cargo's inception build dependencies have, by default, been built
in a profile that largely matches the profile of the final target
artifact. Build dependencies, however, rarely actually need to be
optimized and are often executing very small tasks, which means that
optimizing them often wastes a lot of build time. A great example of
this is procedural macros where `syn` and friends are pretty heavyweight
to optimize, and the amount of Rust code they're parsing is typically
quite small, so the time spent optimizing rarely comes as a benefit.
The goal of this PR is to improve build times on average in the
community by not spending time optimizing build dependencies (build
scripts, procedural macros, and their transitive dependencies). The PR
will not be a universal win for everyone, however. There's some
situations where your build time may actually increase:
* In some cases build scripts and procedural macros can take quite a
long time to run!
* Cargo may not build dependencies more than once if they're shared with
the main build. This only applies to builds without `--target` where
the same crate is used in the final binary as in a build script.
In these cases, however, the `build-override` profile has existed for
some time know and allows giving a knob to tweak this behavior. For
example to get back the previous build behavior of Cargo you would
specify, in `Cargo.toml`:
[profile.release.build-override]
opt-level = 3
or you can configure this via the environment:
export CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_OPT_LEVEL=3
There are two notable features we would like to add in the future which
would make the impact of a change like this smaller, but they're not
implemented at this time (nor do we have concrete plans to implement
them). First we would like crates to have a way of specifying they
should be optimized by default, despite default profile options. Often
crates, like lalrpop historically, have abysmal performance in debug
mode and almost always (even in debug builds) want to be built in
release mode. The second feature is that ideally crate authors would be
able to tell Cargo to minimize the number of crates built, unifying
profiles where possible to avoid double-compiling crates.
At this time though the Cargo team feels that the benefit of changing
the defaults is well worth this change. Neither today nor directly after
this change will be a perfect world, but it's hoped that this change
makes things less bad!
This commit updates Cargo's build of host dependencies to build them
with optimization level 0 by default instead of matching the profile of
the final binary.
Since Cargo's inception build dependencies have, by default, been built
in a profile that largely matches the profile of the final target
artifact. Build dependencies, however, rarely actually need to be
optimized and are often executing very small tasks, which means that
optimizing them often wastes a lot of build time. A great example of
this is procedural macros where `syn` and friends are pretty heavyweight
to optimize, and the amount of Rust code they're parsing is typically
quite small, so the time spent optimizing rarely comes as a benefit.
The goal of this PR is to improve build times on average in the
community by not spending time optimizing build dependencies (build
scripts, procedural macros, and their transitive dependencies). The PR
will not be a universal win for everyone, however. There's some
situations where your build time may actually increase:
* In some cases build scripts and procedural macros can take quite a
long time to run!
* Cargo may not build dependencies more than once if they're shared with
the main build. This only applies to builds without `--target` where
the same crate is used in the final binary as in a build script.
In these cases, however, the `build-override` profile has existed for
some time know and allows giving a knob to tweak this behavior. For
example to get back the previous build behavior of Cargo you would
specify, in `Cargo.toml`:
[profile.release.build-override]
opt-level = 3
or you can configure this via the environment:
export CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_OPT_LEVEL=3
There are two notable features we would like to add in the future which
would make the impact of a change like this smaller, but they're not
implemented at this time (nor do we have concrete plans to implement
them). First we would like crates to have a way of specifying they
should be optimized by default, despite default profile options. Often
crates, like lalrpop historically, have abysmal performance in debug
mode and almost always (even in debug builds) want to be built in
release mode. The second feature is that ideally crate authors would be
able to tell Cargo to minimize the number of crates built, unifying
profiles where possible to avoid double-compiling crates.
At this time though the Cargo team feels that the benefit of changing
the defaults is well worth this change. Neither today nor directly after
this change will be a perfect world, but it's hoped that this change
makes things less bad!
Fix freshness checks for build scripts on renamed dirs
This commit fixes an issue in Cargo where when an entire project
directory is renamed (preserving the target directory) then path
dependencies with build scripts would have their build scripts rereun
when building again. The problem with this was that when a build script
doesn't print `rerun-if-changed` Cargo's conservative fingerprint listed
an absolute path in it, which was intended to be a relative path.
The fix here is to use a relative path in the fingerprint to ensure that
it's not the reason a rebuild happens when directories are renamed.
This commit fixes an issue in Cargo where when an entire project
directory is renamed (preserving the target directory) then path
dependencies with build scripts would have their build scripts rereun
when building again. The problem with this was that when a build script
doesn't print `rerun-if-changed` Cargo's conservative fingerprint listed
an absolute path in it, which was intended to be a relative path.
The fix here is to use a relative path in the fingerprint to ensure that
it's not the reason a rebuild happens when directories are renamed.
Add a `-Zbuild-std-features` flag
This flag is intended to pair with `-Zbuild-std` as necessary to
configure the features that libstd is built with. This is highly
unlikely to ever be stabilized in any form (unlike `-Zbuild-std` which
we'd like to stabilize at some point), but can be useful for
experimenting with the standard library. For example today it can be
used to test changes to binary size by disabling backtraces.
My intention is that we won't need a `--no-default-features` equivalent
for libstd, where after rust-lang/rust#74377 is merged we can
unconditionally specify default features are disabled but the default
set of features lists `default`. That way if users want to override the
list *and* include the default feature, they can just be sure to include
`default`.
This flag is intended to pair with `-Zbuild-std` as necessary to
configure the features that libstd is built with. This is highly
unlikely to ever be stabilized in any form (unlike `-Zbuild-std` which
we'd like to stabilize at some point), but can be useful for
experimenting with the standard library. For example today it can be
used to test changes to binary size by disabling backtraces.
My intention is that we won't need a `--no-default-features` equivalent
for libstd, where after rust-lang/rust#74377 is merged we can
unconditionally specify default features are disabled but the default
set of features lists `default`. That way if users want to override the
list *and* include the default feature, they can just be sure to include
`default`.
clippy cleanups
Fixes a couple of clippy warnings.
Ignores clippy::collapsible_if warnings in the future (iirc there were not desired)
clippy::redundant_clone is enabled by default by clippy already.
Fix self-publish script.
Removes the dry run, since it won't work (verification fails since dependencies aren't actually published).
Also adds a sleep in-between publishing to give the index a moment to update.
Ensure `unstable.build-std` works like `-Zbuild-std`
This fixes an issue where the deserializer for `-Zbuild-std` was a bit
fancier than the `unstable.build-std` directive.
cc #8393
Make `cargo metadata` output deterministic
Uses BTreeMap instead of HashMap for the `cargo metadata` command, ensuring the output is sorted.
The change did not cause a measurable performance impact for running `cargo metadata` on `cargo` itself.
Fixes#8477
Uses BTreeMap instead of HashMap for the `cargo metadata` command.
The change did not cause a measurable performance impact for
running `cargo metadata` on `cargo` itself.
Fixes#8477
