When build fails, print dependency graph path leading to failure

[stepancheg]

Problem

I'm running cargo build --bin foo (with cross-compilation, custom compiler, large workspace, feature flags, etc etc).

Build fails:

...
   Compiling openssl-sys v0.9.110
error: failed to run custom build command for `openssl-sys v0.9.110`
...
warning: build failed, waiting for other jobs to finish...

Why was openssl even compiled? It is not supposed to be in the dependency tree. I run cargo tree -p foo-pkg, and openssl-sys it is nowhere there. I'm stuck. (I'm not asking for help with openssl here, this is an illustration.)

Proposed Solution

When build fails, print a graph path leading to the dependency that failed to build. Like this:

   Compiling openssl-sys v0.9.110
error: failed to run custom build command for `openssl-sys v0.9.110`
...
openssl-sys was compiled because it is dependency of openssl
... which is dependency of native-tls
... which is a build dependency of aaa
... which is a dependency of foo-pkg

warning: build failed, waiting for other jobs to finish...

Notes

buck2 does something similar for every error: it prints dependency graph path leading to an error, for example:

Error running analysis for `root//:main (prelude//platforms:default#f6691640831d48dd)`

Caused by:
    0: Error looking up configured node root//:main (prelude//platforms:default#f6691640831d48dd)
    1: Error looking up configured node toolchains//:java (prelude//platforms:default#f6691640831d48dd) (prelude//platforms:default#f6691640831d48dd)
    2: looking up unconfigured target node `toolchains//:java`
    3: Unknown target `java` from package `toolchains//`.

[epage]

Dependencies generally fail because

• Specified MSRV is higher than current toolchain: we check this before compilation
• Unspecified MSRV is higher than current toolchain: this appears as compilation errors
• Build scripts and proc-macros that depend on external state

My overall concern is this being noisy if we do it for every compiler error.

Another important aspect to this issue is that using cargo tree directly didn't work (for likely valid reasons) but that the user needs to understand this nuance to make it work. That seems like the more fundamental problem to address so we can help people in more circumstances.

Would you mind opening a separate issue about the workflow problem with cargo tree with reproduction steps and output?

[stepancheg]

My overall concern is this being noisy if we do it for every compiler error.

One possible option is to do what Bazel does for tests: write information into a file, and post a link to that file.

Dependency path (and compilation flags, env vars etc) leading to this failure is written in /tmp/build-failure.txt

[epage]

We are working on structured logging for cargo so you can review timings reports or rebuild reasons after the fact. That might also be an option.