When attempting to substitute a local version of a dependency, since the
`patch` section uses syntax similar to a dependency (and the
documentation even says "The syntax is similar to the `[dependencies]`
section", it's natural to assume that other things from `[dependencies]`
also work, such as `features` or `default-features`. Attempting to use
them produces this warning:
> patch for `crate-name-here` uses the features mechanism.
> default-features and features will not take effect because the patch dependency does not support this mechanism
The phrasing "the patch dependency does not support this mechanism"
makes it seem at first glance like `patch` just doesn't support this at
all. But the actual problem is that the user needs to move the
`features`/`default-features` keys to an entry in `dependencies`
instead.
Modify the message, to make this more obvious.
Modify the corresponding warning for `replace` as well.
Update tests accordingly.
### What does this PR try to resolve?
This changes the future-incompat message to be reported in a single
`Report`. The primary motivation is to cleanup the output compared to
taking the existing note's and aligning all content with the first line
which is what would happen otherwise in #15917.
In preparation for this, the message was cleaned up and made more like
what a rustc message might look like.
### How to test and review this PR?
### 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"
```
