cargo tree -i does not interpret -e no-proc-macro in a useful way

[jrose-signal]

Problem

In libsignal's attest crate, we have dependencies on serde:

% cargo tree -i serde -e normal -p attest       
serde v1.0.136
├── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)
├── chrono v0.4.19
│   ├── asn1 v0.9.1
│   │   └── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)
│   └── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)
├── hex v0.4.3
│   └── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)
└── serde_json v1.0.79
    └── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)

serde v1.0.136
└── toml v0.5.8
    └── proc-macro-crate v1.1.3
        └── num_enum_derive v0.5.7 (proc-macro)
            └── num_enum v0.5.7
                └── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)

However, adding -e no-proc-macro merely truncates the tree for the second serde, rather than omitting it.

% cargo +stable tree -i serde -e normal,no-proc-macro -p attest
serde v1.0.136
├── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)
├── chrono v0.4.19
│   ├── asn1 v0.9.1
│   │   └── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)
│   └── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)
├── hex v0.4.3
│   └── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)
└── serde_json v1.0.79
    └── attest v0.1.0 (/Users/jordan/dev/libsignal-client/rust/attest)

serde v1.0.136
└── toml v0.5.8
    └── proc-macro-crate v1.1.3

The same applies to cargo tree -d, leading to some silly workarounds in our script that checks for duplicate crates (for code size reasons).

Steps

No response

Possible Solution(s)

Preferred solution: in -i and -d mode, no-proc-macro should hide paths that go through proc-macros, rather than starting at the target crate and stopping on the way back to the root. This helps answer my real question of "which crates have object files that end up in my built library".

Alternate solution: reject (or ignore-with-warning) no-proc-macro in -i and -d until it does something useful. (I can't think of any use for the current behavior.)

Notes

No response

Version

cargo 1.69.0 (6e9a83356 2023-04-12)
release: 1.69.0
commit-hash: 6e9a83356b70586d4b77613a6b33f9ea067b9cdf
commit-date: 2023-04-12
host: x86_64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.87.0 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.3.1 [64-bit]

Also happens with

cargo 1.67.0-nightly (7e484fc1a 2022-10-27)
release: 1.67.0-nightly
commit-hash: 7e484fc1a766f56dbc95380f45719698e0c82749
commit-date: 2022-10-27
host: x86_64-apple-darwin
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.87.0 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.3.1 [64-bit]

and

cargo 1.71.0-nightly (de80432f0 2023-04-21)
release: 1.71.0-nightly
commit-hash: de80432f04da61d98dcbbc1572598071718ccfd2
commit-date: 2023-04-21
host: x86_64-apple-darwin
libgit2: 1.6.3 (sys:0.17.0 vendored)
libcurl: 7.87.0 (sys:0.4.61+curl-8.0.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1t  7 Feb 2023
os: Mac OS 13.3.1 [64-bit]

[weihanglo]

Thank you for writing this out! This is definitely a todo left in #9488. I am fine with either solution you listed. If you find the former one (walk from root to omit proc-macro) a bit complicated, we can always start from the latter (ignore-with-warning).