### What does this PR try to resolve?
Passing a package to `--package` is for workspace members; we need to
pass it to `--invert`.
### How to test and review this PR?
This is part of #14993
While I think we should instead improve the `cargo tree` command to help
users with `--all-features`, we can at least take the other improvement
from #14991.
Unsure if this should be two groups or one group with a message.
If its one group, then we'll have a decorative line and then the `help:`
will be further indented.
I went with what is closer to how we do things today. We can always
re-evaluate at a later point.
Several parts of this are not ideal yet
- Frontmatter close should show the open and show the EOF, instead of
pointing at the open
- Trailing content on close will usually have a newline
- Multiple frontmatters should show the original frontmatter
- Some content, like supported infostrings, should go in a help
- Ideally we try to recover on no closing and instead point out a
mismatched open/close
But this is still an improvement over nothing!
### What does this PR try to resolve?
Fixes#12740
This is also prep for #15917, #15922
Changes:
- `note` changes from Cyan to Bright Green
- `cargo info` had to be changed because the header and context colors
became the same
- Switch to Bright colors which is usually redundant with Bold but that
is theme dependent
- `warning` only changes to Bright on Windows which is to work around a
shell issue on some Windows versions
- except for `PLACEHOLDER` to tell it apart from `LITERAL`
- the `:` in `note:` is no longer bolded to match rustc
### How to test and review this PR?
### Notes
While annotate-snippets does not have a style for every one of our
styles, I updated our manual styles to be similar to annotate snippets.
For annotate snippets color definitions, see
d38b08b81d/src/renderer/mod.rs (L41-L78)
In most cases, this will just be what you passed on the command line.
Even when its not, that likely represents a programmer error.
I mostly did this to help see what was the cause of a test failure.
I cannot think of a programmatic way to require escaping when going from no frontmatter to a frontmatter
or to require more escaping than is already present.
Read a real target spec JSON so we no longer need to hardcode
a target spec JSON here.
Cargo itself should not care about the spec schema.
Let's stop bothering compiler contributors.
### What does this PR try to resolve?
via issue #15505, Cargo currently errors on
```toml
[dependencies]
crc32fast = true
```
with a message about `expected a version string or a detailed
dependency` It doesn’t hint that you can depend on a workspace member.
This PR updates `cargo` so that when you write dep = true, the error
also suggests:
```toml
dep = { workspace = true }
dep.workspace = true
```
### How should we test and review this PR?
In a workspace crate’s Cargo.toml, add
```toml
[dependencies]
crc32fast = true
```
Run `cargo build` and you should see the enhanced error with the two
workspace hints.
### Additional information
Regarding support for int/float, we only need a special case for boolean
because they’re the only values that get the `workspace hint`.
Everything else just uses the normal detailed dependency error
### What does this PR try to resolve?
This PR resolves: https://github.com/rust-lang/cargo/issues/13051
Namely, it allows users to invoke cargo subcommands that accept a
`--target` directive to specify the `host` target, which is later
substituted in the command processing layer by the host's real target
triple (for instance, on most Linux distributions, `cargo build --target
host` would effectively run `cargo build --target
x86_64-unknown-linux-gnu`).
This additionally applies to usage within `config.toml`, like so:
```toml
# .cargo/config.toml
[build]
target = "host"
```
### What does this PR try to resolve?
Part of #15844
Set up `-Zbuild-analysis` flag and `build.analysis` configuration table
to lay the ground work.
when `build.analysis.enabled = true`, enables HTML timing output to
pretend we are persisting timing data for now. This will change when the
storage part is implemented.
### How to test and review this PR?
### What does this PR try to resolve?
RFC 3841 has merged, and x86_64-apple-darwin will be demoted to tier-2
in 1.90.0. In Cargo we usually run test against tier-1 platforms, so
x86_64-apple-darwin should be removed.
Also, that target platform is often the slowest one in CI, we are happy
to remove it to save us a couple of minutes.
https://rust-lang.github.io/rfcs/3841-demote-x86_64-apple-darwin.html
### How to test and review this PR?
Run `cargo test` locally with cross-compile tests enabled, and no
regression.
RFC 3841 has merged, and x86_64-apple-darwin will be demoted to tier-2
in 1.90.0. In Cargo we usually run test against tier-1 platforms, so
x86_64-apple-darwin should be removed.
Also, that target platform is often the slowest one in CI,
we are happy to remove it to save us a couple of minutes.
https://rust-lang.github.io/rfcs/3841-demote-x86_64-apple-darwin.html
### What does this PR try to resolve?
While preparing to stabilize `build-dir`, [it was
discovered](https://github.com/rust-lang/cargo/issues/14125#issuecomment-3127467689)
that `cargo package` will sometimes use the build cache for dependency
crates if `CARGO_TARGET_DIR` is explicitly set.
If target-dir is not set, the build will be preformed in an "inner
target dir" at `target/package/{name}-{version}/target` and rebuild
everything.
This PR changes the default behavior to always use the build cache,
matching the behavior of having `target-dir` set.
### How to test and review this PR?
Added a dedicated test to verify the previous behavior (cargo recompiled
non-workspace crates) in the first commit.
Then updated it to verify the new behavior.
### Related links/notes
* I did some Git archaeology and I _think_ this behavior was introduced
in #2912
* While searching through the commit/pr history was never able to find
any explicit reason why the behavior is the way it is.
* Even if it was intentional, it has been 9 years since and Cargo's
fingerprinting/rebuild detection is much more mature now so I believe
its worth revisiting if this is still the desired behavior.
* Would help mitigate https://github.com/rust-lang/cargo/issues/14941
The error message for unknown values of `cargo-features` was unhelpful:
```text
Caused by:
unknown cargo feature `build-dir`
```
I've made it more explanatory, and matching the style of the other
errors:
```text
Caused by:
feature `build-dir` is not a valid unstable feature for Cargo.toml
This feature can be enabled via -Zbuild-dir or the `[unstable]` section in config.toml.
See https://doc.rust-lang.org/cargo/reference/unstable.html for more information.
```
