### What does this PR try to resolve?
The "host" string is ambiguous
* We have `-Zhost-config` that config `[host]` table applies to
artifacts running on host, such as build scripts and proc macros.
* `host` sounds like the default behavior, whereas `--target host` is in
the cross-compilation mode: `target/<triple>/debug`.
* We might want to reserve `host` for future use
This should address both concerns in
<https://github.com/rust-lang/cargo/issues/13051#issuecomment-3313262589>:
* "host-tuple" is aligned with `rustc --print host-tuple`, and doesn't
sound like a default behavior.
* Given "host" is not used, we reserved the future possibility to reset
to the default behavior
The test exercises a regression of extra `-Zbuild-std-features`
overriding the entire default-features set.
However, after rust-lang/rust 146317 panic_immediate_abort
became a codegen flag not a Cargo feature anymore.
We pick another `optimize_for_size` feature flag to ensure the
regression case is still covered.
To verify `optimize_for_size` actually triggers the regression,
git revert f004691aa41449fa06b764683385558edee51428
and changes to `-Zbuild-std-features=optimize_for_size`.
Alternatively, we can just drop this test.
The "host" string is ambiguous
* We have `-Zhost-config` that config `[host]` table applies to
artifacts running on host, such as build scripts and proc macros.
* `host` sounds like the default behavior, whereas `--target host`
is in the cross-compilation mode: `target/<triple>/debug`.
* We might want to reserve `host` for future use
For comparison, the rustc error is:
> error: extra characters after frontmatter close are not allowed
> --> $DIR/extra-after-end.rs:2:1
> |
> LL | ---cargo
> | ^^^^^^^^
### What does this PR try to resolve?
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.
Closes#13522
### How to test and review this PR?
This applies the review feedback from #13522 that the author didn't have
a chance to get back to.
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.
