Plan a build, including reading manifests for transitive dependencies

[secona]

• Initial implementation (feat(plan-build): Initial implementation #96)

[secona]

FWIW, IntelliJ IDEA and rust-analyzer are only (atm) using build-plan to get the value of OUT_DIR. If there were some other way to get at it (e.g. rust-lang/cargo#7546), then they wouldn't have any reason to use it anymore.

rust-lang/cargo#7614 (comment)

[secona]

Related experiment: https://github.com/jwollen/cargo/tree/build-unit-graph

[epage]

Note this is tightly related to #40.

From #40 (comment)

For input/output, we more likely want unit-graph than build-plan.

[secona]

I've looked into this a bit. Building the unit graph is a two step process.

The first step is generating the root units using UnitGenerator::generate_root_units. This requires changes to cargo as UnitGenerator is still private. It also looks like we need to call resolve_with_previous again, similar to resolve-features plumbing command.

The second step is the root units get provided to build_unit_dependencies. This part probably don't need changes to cargo to get things started.

I'm assuming we're free to implement the output how we seem fit as an effort to resolve some issues at rust-lang/cargo#8002

[epage]

It also looks like we need to call resolve_with_previous again, similar to resolve-features plumbing command.

Why is that? I would assume the results of resolve-features would be passed in

I'm assuming we're free to implement the output how we seem fit as an effort to resolve some issues at rust-lang/cargo#8002

Yes

[secona]

It also looks like we need to call resolve_with_previous again, similar to resolve-features plumbing command.

Why is that? I would assume the results of resolve-features would be passed in

Because UnitGenerator requires it

https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_compile/mod.rs#L395-L396

[epage]

It needs a resolve. Is the call a hack because we can't create one?

[secona]

I haven't found a way to create one, yeah.

So, the resolve and workspace_resolve is the output from resolve_ws_with_opts. (source)

In it, resolve is the output of resolve_with_previous. (source)

It gets confusing because of the renames