Whether a period was used was dependent on whether a `help:` block is
present.
That shouldn't make a difference and the rustc dev guide says not to use
periods unless multiple sentences are used.
This was found when updating git submodule in rust-lang/rust
```
---- cargo_command::overwrite_cargo_environment_variable stdout ----
running `/projects/rust/build/aarch64-apple-darwin/stage1-tools/aarch64-apple-darwin/release/cargo run`
thread 'cargo_command::overwrite_cargo_environment_variable' panicked at src/tools/cargo/tests/testsuite/cargo_command.rs:636:58:
test failed running `/projects/rust/build/aarch64-apple-darwin/stage1-tools/aarch64-apple-darwin/release/cargo run`
error: expected to find:
/projects/rust/build/aarch64-apple-darwin/stage1-tools/aarch64-apple-darwin/release/cargo
did not find in output:
[COMPILING] foo v1.0.0 ([ROOT]/foo)
[FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
[RUNNING] `target/debug/foo`
```
Lockfile might not be under the package root, but its entries
may be outdated and get packaged into the `.crate` tarball.
We take a conservative action that if the lockfile is dirty,
then all workspace members are considered dirty.
Workspace manifest might not be under the package root, but
workspace inheritance may still affect what is packaged into
the `.crate.` tarball. We take a conservative action that if
the workspace manifest is dirty, then all workspace members
are considered dirty.
### What does this PR try to resolve?
I was investigating some issues around public dependency lints and
wanted to see the structure of the public dependencies and had the idea
to add this with us having added `--depth workspace`.
See
https://github.com/rust-lang/rust/issues/119428#issuecomment-2686384070
for some example output (comparing `cargo tree` with `cargo tree --depth
public`)
### How should we test and review this PR?
### Additional information
This commit fixes a (five year old!) regression in `cargo metadata`
where if `--filter-platform` isn't explicitly specified it will
accidentally read `$CARGO_BUILD_TARGET` (or `build.target`
configuration) and use that as the default `--filter-platform`. The
reason for this is that the calculation for targets changed in #8167
and while the shared function makes sense for other commands such as
`cargo build` the targets have a different meaning in `cargo metadata`
so a slightly different set of functionality is desired.
This commit fixes the issue by introducing a new constructor for the
list of `CompileKind` variants where the fallback of "if nothing is
specified" is explicitly chosen.
### What does this PR try to resolve?
This is an experiment to find ways to make `cargo tree` output easier to
grok. I find too many details are hard to spot because everything looks
the same.
The goal is to make it easier to scan the output for relevant details.
So far, this approach seems the most viable. Knowing what type of edges
led to where you are provides useful context for scrolling through large
lists of dependencies.
Fixes#10558
### How should we test and review this PR?
I had considered styling normal dependency edges but there isn't a
header to clarify what they mean, so I decided to match the package name
as that is the header. So this didn't buy as much as I had hoped,
especially since dimmed lines aren't obvious with my terminal. Maybe if
we used different unicode graph characters.
Instead of coloring the "this is elided" `(*)`, I had considered using a
unicode character that looks like its pointing from that item up. I only
found one that looked close to that but the origin for the arrow was
bottom aligned, rather than center aligned and it looked off.
Alternatives considered
- Once an edge is marked with dev or build dependencies, all future
edges inherit it
- While this makes it clear what section you are in, so does the outer
most line
- Feature edges are the color of the edges that led to them
- Unsure of value either way
- This might get weird with `--invert`
- Style local nodes different than non-local
- With the format string being user customizable, I'm concerned with
styling over or within user styling
- Rainbow packages: For every package in the same namespace
(`.split_once("::").0`) or prefix (`.split_once(['-','_']).0`), assign a
color (maybe only for the top N packages to reduce duplicate colors)
- Would help a lot with `gix-*` and similar other cases
- If we cap the number of participating packages, would need care to
work with `--depth`
(of course,. these could be mixed)
### Additional information
cargo-vendor has a workaround that to mitigate rust-lang/cargo#5956,
it removes all cached sources in order to trigger a re-unpack.
It was meant for dealing with registry sources only, but accidentally
applied to directory source kind.
While directory source kind was invented for vendoring,
and vendoring from one vendored directory to the other seems unusual,
Cargo IMO should not delete any real sources.
It does not mean that registry sources are okay to delete,
In long term, we should explore a way that unpacks `.crate` files
directly, without any removal. See
https://github.com/rust-lang/cargo/pull/12509#issuecomment-1732415990
Overwrite `$CARGO` when the current exe is detected to be a cargo
binary.
From
https://github.com/rust-lang/cargo/issues/15099#issuecomment-2666737150:
> opt-in behavior (set by cargo-the-bin):
>
> 1. `from_current_exe` if its `cargo[EXE_SUFFIX]`
> 2. `from_argv` if its `cargo[EXE_SUFFIX]`
> 3. `from_env`
> 4. `from_current_exe`
> 5. `from_argv`
r? @epage
### What does this PR try to resolve?
The old behavior gets members from `default-members` if specified in a
virtual workspace, this PR gets all workspace members for `Available`
target hints.
Fixes https://github.com/rust-lang/cargo/issues/14544
### How should we test and review this PR?
The first commit added the test, the second commit addressed the issue.
### Additional information
### What does this PR try to resolve?
Just found we can simplify `human_readable_bytes` a bit.
This also remove the `bytesize` dependency,
since we already have a hand-rolled function.
(It is a good crate, though)
### How should we test and review this PR?
Should have no real functional difference.
`cargo package` starts reporting IEC (KiB) instead of SI (KB).
So do some thresholds of `cargo package`.
Could also switch entirely to `bytesize` if that is preferred.
### Additional information
When `--exclude-lockfile` is enabled,
`cargo package` will not verify the lock file if present,
nor will it generate a new one if absent.
Cargo.lock will not be included in the resulting tarball.
Together with `--no-verify`,
this flag decouples packaging from checking the registry index.
While this is useful for some non-normal workflows that requires
to assemble packages having unpublished dependencies.
It is recommended to use `-Zpackage-workspace` to package the entire
workspace, instead of opting out lockfile.
After dd698ff0483bda065d1f78968e70ee86fb116a72,
`cargo package --no-verify` at least fails in three different cases:
* An unpublished package depending on itself as a dev-dependency (cyclic self-referential dev-dependencies).
* Can be resolved by removing the `version` field from the affected dev-dependency.
* `-Zpackage-workspace` doesn't help with it.
* Existing `cargo package` has `--package <pkg>` specifying certain unpublished packages.
* Can be resolved by specifying all unpublished packages in one `cargo` call.
* `-Zpackage-workspace` also requires all dependency versions available in the target registry when calling, so doesn't help.
* `cargo package --no-verify` has been used as a kind of “plumbing commands” to create tarballs without considering dependency orders. The use cases include:
* Preparing tarballs for other package managers.
* Integrating into custom develop workflows for unpublished/internal crates.
* Constructing custom/private registries.
This commit shows the former two cases.
### What does this PR try to resolve?
This was reported at
https://github.com/rust-lang/cargo/issues/10948#issuecomment-2674289330
For the exact mapping between the publish payload and the index,
see
https://doc.rust-lang.org/cargo/reference/registry-index.html#json-schema,
particularly the note about differences.
### How should we test and review this PR?
### Additional information
I suspect there is a second bug here because my debugging only showed us
hitting this scenario for `val-json` and not `concepts` and only when
building `utils`. That difference in behavior between a transitive and
direct dependency is odd.
