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
Added a test that checks that the aliases that currently
are builtin with cargo are indeed being printed with the rest
of the commands when `cargo --list` is called.
Closes#8486
As stated in #8486 it would help to the discovery of the
builtin aliases the facto of printing them with the
`cargo --list` command.
- Extracted the builtin aliases currently implemented to a
sepparated `const`.
- Make all of the functions that interact with these aliases
point to that function.
- Refactored the `list_commands` fn in order to include with the
builtin and external commands, the builtin aliases that come with
cargo by defaut.
This commit implements a simple warning to indicate when `DefaultBranch`
is unified with `Branch("master")`, meaning `Cargo.toml` inconsistently
lists `branch = "master"` and not. The intention here is to ensure that
all projects uniformly use one or the other to ensure we can smoothly
transition to the new lock file format.
This commit lays the groundwork for an eventual V3 of the lock file
format. The changes in this format are:
* A `version` indicator will be at the top of the file so we don't have
to guess what format the lock is in, we know for sure. Additionally
Cargo now reading a super-from-the-future lock file format will give a
better error.
* Git dependencies with `Branch("master")` will be encoded with
`?branch=master` instead of with nothing.
The motivation for this change is to eventually switch Cargo's
interpretation of default git branches.
This commit implements a warning in Cargo for when a dependency
directive is using `DefaultBranch` but the default branch of the remote
repository is not actually `master`. We will eventually break this
dependency directive and the warning indicates the fix, which is to
write down `branch = "master"`.
This commit is intended to be an effective but not literal revert
of #8364. Internally Cargo will still distinguish between
`DefaultBranch` and `Branch("master")` when reading `Cargo.toml` files,
but for almost all purposes the two are equivalent. This will namely fix
the issue we have with lock file encodings where both are encoded with
no `branch` (and without a branch it's parsed from a lock file as
`DefaultBranch`).
This will preserve the change that `cargo vendor` will not print out
`branch = "master"` annotations but that desugars to match the lock file
on the other end, so it should continue to work.
Tests have been added in this commit for the regressions found on #8468.
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.
