feat(tree): show artifact dependency details by npmccallum · Pull Request #17075 · rust-lang/cargo

npmccallum · 2026-06-04T12:20:41Z

What does this PR try to resolve?

cargo tree -Z bindeps currently renders artifact dependencies as ordinary package edges. The output does not identify the requested artifact kinds, selected binaries, or artifact target, and it cannot distinguish a library relationship from an artifact relationship to the same package.

This PR represents each artifact request as an intermediate node between the dependent and the package that provides the artifact:

foo v0.1.0
└── bar artifact "bin:bar-cli" (target: wasm32-unknown-unknown)
    └── bar v0.5.0

The request remains in its original normal, build, or development dependency category. The package below it retains the compilation context and dependency subtree selected for the artifact target.

Refs #14804.

Design

Artifact details belong to a dependency request rather than globally to a package. An intermediate node preserves that request in both graph directions without adding hidden text to a formatted package line.

With feature edges enabled, the request precedes the features it activates:

foo v0.1.0
└── bar artifact "bin"
    └── bar feature "default"
        └── bar v0.5.0

In an inverted tree, the request remains visible between the package and its dependent:

bar v0.5.0
└── bar artifact "bin"
    └── foo v0.1.0

--format continues to format package nodes. Artifact request nodes, like feature nodes, use a fixed description so artifact information is not lost or appended outside the requested package format.

Artifact request nodes are graph nodes and therefore count as a level for --depth. For example, the provider package in the first example appears at depth 2 rather than depth 1.

For lib = true, Cargo has two relationships with the package: an ordinary Rust library dependency and an artifact request. The tree displays both:

foo v0.1.0
├── bar v0.5.0
└── bar artifact "bin"
    └── bar v0.5.0 (*)

Scope

This PR does not add a dashed or otherwise distinct line style. The artifact node identifies the non-library request and provides its kinds and target; line styling can be considered separately without changing the graph model.

Dependency aliases are not added to the label. This matches existing cargo tree package-edge behavior. Requests that differ by selected artifacts, target, package compilation context, or activated features remain distinct.

Commit structure

Record existing output, including formatting, inversion, pruning, depth limiting, shared-request deduplication, --no-dedupe, dependency filtering, targets, features, and lib = true.
Centralize dependency-edge construction without changing output.
Add artifact request nodes and update the recorded expectations.

Each commit builds and passes the focused test suite independently.

How should we test and review this PR?

The expectation changes in the final commit show the display contract directly. The graph changes should preserve these invariants:

The incoming edge retains its normal/build/dev category and publicness.
Artifact features and transitive dependencies use the artifact package's compilation context.
lib = true retains a separate ordinary package relationship.
Formatting, inversion, pruning, depth limiting, deduplication, and feature-edge traversal handle artifact nodes consistently.

Local verification:

cargo fmt --check
git diff --check upstream/master...HEAD
cargo check -q
cargo test --test testsuite artifact_dep::
cargo test --test testsuite cargo_tree::

rustbot · 2026-06-04T12:20:46Z

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ehuss, @epage, @weihanglo
@ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
Random selection from ehuss, epage, weihanglo

epage · 2026-06-04T13:13:53Z

    }
 }

-#[derive(Debug, Copy, Hash, Eq, Clone, PartialEq)]


tip: splitting changes like this into their own commit make it easier / faster for maintainers to review, see https://epage.github.io/dev/pr-style/#c-atomic

View changes since the review

epage · 2026-06-04T13:16:46Z

+        .with_status(0)
+        .run();
+
+    p.cargo("tree -Z bindeps -e features")


We ask for new test cases to be added in their own commit first, with tests passing in that commit, see https://epage.github.io/dev/pr-style/#c-test

View changes since the review

epage · 2026-06-04T13:22:30Z

    ws: &Workspace<'_>,
    graph: &'a Graph<'_>,
    node_index: NodeId,
+    incoming_edge: Option<&Edge>,


If we are relying on the incoming edge. Are there times where we have different edges but the same node? For example, what happens if a package has a regular dep and an artifact dep on a package?

#16192 also deals with edges and may have other relevant concerns.

View changes since the review

epage · 2026-06-04T13:23:19Z

            r#"...
 foo v0.1.0 ([ROOT]/foo)
-└── bar v0.1.0 ([ROOT]/foo/bar)
+└── bar v0.1.0 ([ROOT]/foo/bar) (artifact: bin, target=[ALT_TARGET])


This PR is marked as closing the issue but part of the issue is how to visually represent the graph.

View changes since the review

npmccallum · 2026-06-04T17:23:59Z

I traced the design history through #10593, #14804, #14658, RFC 3028,
and RFC 3176. I did not find an accepted RFC-level output format for
cargo tree.

The concrete proposal in #10593 / #14804 was to annotate artifact
dependencies with the artifact kind, for example (bin), (staticlib),
or (cdylib), optionally including the target in that annotation if we
choose to show it. The prior draft PR #14658 followed that textual suffix
direction.

This PR takes that minimal textual approach, but spells the annotation
out as (artifact: ..., target=...) so the meaning is self-describing.
It keeps artifact dependencies in their existing normal/build/dev
sections and attaches the annotation to the incoming edge, not globally
to the package node. That is why a normal edge and an artifact edge to
the same package render differently.

I did not implement dashed-line rendering in this PR. Line style could
communicate that an edge is a non-linking artifact edge, but it cannot
disambiguate multiple artifact requests to the same package, such as
different artifact kinds, binary selectors, or targets. The target case
is not hypothetical; #17067 allows separate artifact dependency aliases
for the same package with different requested targets. The textual
annotation carries that edge-local detail, and the graph representation
keeps the metadata on the edge so dashed-line rendering remains possible
as a future UI refinement.

If dashed-line rendering would be valuable, I am happy to implement that
as a follow-up once there is agreement on how it should interact with the
textual artifact details.

I also changed this from Closes #14804 to Refs #14804 because the
larger visual design remains open, especially whether cargo tree
should eventually use a distinct line style and how far we want to go
for lib = true rendering.

npmccallum · 2026-06-24T16:18:51Z

Updated this PR around the design discussion and the PR-structure feedback.

Changes in this revision:

Rebuilt the series as two commits: first a tests-only baseline that passes with the existing unannotated output, then the behavior change that updates those expected outputs.
Switched the display to the compact suffix shape discussed in cargo tree panics with "activated_features for invalid package: features did not find PackageId" when a binary dependency is specified with an explicit target key #10593 / Display artifact dependency information in cargo tree #14804: (bin), (bin:name), (bin, target), and (bin:name, staticlib, cdylib).
Kept artifact metadata on the incoming edge, not the package node. This covers the case where the same package is reached through both a normal dependency and an artifact dependency.
Rendered lib = true as two relationships: a normal dependency edge plus an artifact dependency edge.
Changed the PR body to Refs #14804 and called out that dashed/non-linking line style is deferred. The textual suffix remains useful even if line styling is added later because it carries the artifact kind, selected binary, and target.

I left the review threads open for reviewer confirmation.

Verified locally:

cargo fmt
git diff --check
cargo check -q
cargo test --test testsuite artifact_dep::
cargo test --test testsuite cargo_tree::

epage · 2026-07-03T18:32:05Z

We have other attempts at annotating edges which gets weird in some cases. I wonder if we should instead treat these like features: an artifact is a node that depends on the package / lib.

epage · 2026-07-03T18:37:30Z

Not dug into all the details of this implementation (particularly when there are bigger questions) but

consider how this interacts with --format
the more you split out refactors / logistical changes (like possibly removing Copy), it removes noise from the most relevant changes, making it easier to review, particularly with limited reviewer time

rustbot · 2026-07-11T23:05:10Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

npmccallum · 2026-07-11T23:05:22Z

Updated this around the artifact-node design proposal.

Artifact requests are now synthetic nodes, following the existing feature-node model:

foo v0.1.0
└── bar artifact "bin" (target: wasm32-unknown-unknown)
    └── bar v0.5.0

With -e features, the relationship is artifact -> feature -> package. This also makes inversion preserve the request (package -> artifact -> dependent) and keeps artifact details outside custom --format output, which continues to apply only to package nodes.

The parent-to-artifact edge retains its normal/build/dev dependency kind. lib = true is represented as a normal package relationship plus the artifact request relationship. I also restored Edge to Copy; artifact metadata no longer lives on edges.

The first commit is a passing current-behavior test baseline, including format, inversion, pruning, selected binaries, targets, multiple artifact kinds, features, and lib = true. The second commit changes the graph and expected output.

Verified locally:

cargo fmt --check
git diff --check upstream/master...HEAD
cargo check -q
cargo test --test testsuite artifact_dep::
cargo test --test testsuite cargo_tree::

Add passing snapshots for how cargo tree currently renders artifact dependencies. The fixtures cover selected binaries, multiple artifact kinds, explicit targets, feature trees, custom formatting, inversion, pruning, dependency categories, and lib = true. Shared artifact fixtures record reversed artifact-kind declarations, depth limiting, deduplication, and negative dependency-kind filtering. These snapshots establish the behavior changed by the later feature commit.

The logic that routes a dependency edge through feature nodes was inline in `add_pkg`. Extract it into `add_dependency_edge`, alongside the existing `add_pkg` and `add_feature` free functions. The helper accepts the source node and edge so graph construction can reuse feature routing without maintaining a second package index. Also name the inherited compilation context `base_features_for` before applying an artifact target override. Tree output is unchanged and no tests are modified.

Represent each artifact request as an intermediate node between the dependent and the package that provides the artifact. The node records artifact kinds and target while the incoming edge preserves the dependency category. Artifact kinds use canonical ordering so requests that differ only in manifest order share one node. Feature trees route artifact requests through feature nodes before reaching the package. Inverted trees print requests before dependency section headings so their original category remains unambiguous. Custom package formats do not hide artifact details, and dependencies with lib = true keep a separate ordinary package edge. Artifact request nodes deliberately count as a level for --depth.

epage · 2026-07-13T20:29:27Z

                .artifact()
                .and_then(|artifact| artifact.target())
                .and_then(|target| target.to_resolved_compile_target(requested_kind))
-            {


Also name the inherited compilation context base_features_for before
applying an artifact target override.

"Also" and "and" are smells for a commit not being atomic. It looks like this change is independent of the function extraction. The fact that it takes closer inspection to determine whether the behavior changed and drops explanatory comments which take closer inspection to determine if that is fine, makes this require more reviewer attention.

View changes since the review

epage · 2026-07-13T20:33:56Z

                Node::Package { package_id, .. } => {
                    if filter_non_workspace_member && !ws.is_member_id(*package_id) {
                        return false;
                    }
                    !pkgs_to_prune.iter().any(|spec| spec.matches(*package_id))
                }
+                Node::Artifact { package_id, .. } => {
+                    if filter_non_workspace_member && !ws.is_member_id(*package_id) {
+                        return false;
+                    }
+                    !pkgs_to_prune.iter().any(|spec| spec.matches(*package_id))
+                }


is there a reason these two aren't merged?

View changes since the review

epage · 2026-07-13T20:35:14Z

 └── right v0.0.0 ([ROOT]/foo/right)
    [build-dependencies]
-    └── bar v0.5.0 ([ROOT]/foo/bar)
+    └── bar artifact "cdylib, staticlib" (*)


Shouldn't that be "cdylib", "staticlib" if we are quoting them?

View changes since the review

epage · 2026-07-13T20:37:04Z

Thanks for your continue work on this!

rustbot assigned ehuss Jun 4, 2026

rustbot added A-documenting-cargo-itself Area: Cargo's documentation Command-tree S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 4, 2026

epage reviewed Jun 4, 2026

View reviewed changes

npmccallum force-pushed the issue-14804-bindeps-tree branch from 2eb63a0 to 83d0988 Compare June 4, 2026 17:23

npmccallum force-pushed the issue-14804-bindeps-tree branch from 83d0988 to 78717bd Compare June 24, 2026 16:18

This comment has been minimized.

Sign in to view

npmccallum force-pushed the issue-14804-bindeps-tree branch from 78717bd to 4280c6a Compare July 3, 2026 14:20

This comment has been minimized.

Sign in to view

npmccallum force-pushed the issue-14804-bindeps-tree branch from 4280c6a to a45f3cc Compare July 11, 2026 23:05

npmccallum force-pushed the issue-14804-bindeps-tree branch 2 times, most recently from 42e78c1 to cbf26b5 Compare July 11, 2026 23:38

npmccallum added 3 commits July 11, 2026 20:16

npmccallum force-pushed the issue-14804-bindeps-tree branch from cbf26b5 to e36bbbf Compare July 12, 2026 00:48

epage reviewed Jul 13, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

npmccallum commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

Design

Scope

Commit structure

How should we test and review this PR?

Uh oh!

rustbot commented Jun 4, 2026

Uh oh!

epage Jun 4, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Jun 4, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Jun 4, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Jun 4, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

npmccallum commented Jun 4, 2026

Uh oh!

This comment has been minimized.

npmccallum commented Jun 24, 2026

Uh oh!

This comment has been minimized.

epage commented Jul 3, 2026

Uh oh!

epage commented Jul 3, 2026

Uh oh!

This comment has been minimized.

rustbot commented Jul 11, 2026

Uh oh!

npmccallum commented Jul 11, 2026

Uh oh!

epage Jul 13, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Jul 13, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Jul 13, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage commented Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

npmccallum commented Jun 4, 2026 •

edited

Loading

epage Jun 4, 2026 •

edited by rustbot

Loading

epage Jun 4, 2026 •

edited by rustbot

Loading

epage Jun 4, 2026 •

edited by rustbot

Loading

epage Jun 4, 2026 •

edited by rustbot

Loading

epage Jul 13, 2026 •

edited by rustbot

Loading

epage Jul 13, 2026 •

edited by rustbot

Loading

epage Jul 13, 2026 •

edited by rustbot

Loading