japaric / cargo-project Goto Github PK

As of rust-lang/cargo#7295, Cargo allows using .cargo/config.toml instead of just .cargo/config. The current recommendation is to use the former. However, cargo-project does not currently support .cargo/config.toml.

The TOML entry package.version may be:

version = { workspace = true }

In this case cargo-project fails w/

error: Parse: invalid type: map, expected a string for key `package.version`

When running cargo-call-stack with two Cargo config files, eg. this one:

# ~/.cargo/config
[build]
target-dir = "/home/my-user/.cache/cargo-target"

and this one

# ${PWD}/.cargo/config
[patch.crates-io]
riot-sys = { git = "https://github.com/RIOT-OS/rust-riot-sys" }
riot-wrappers = { git = "https://github.com/RIOT-OS/rust-riot-wrappers" }

then cargo call-stack does not find the binary to be tested because it is only processing the first found .cargo/config file, while Cargo itself processes both and puts the binary in a different place:

$ cargo +nightly call-stack --target thumbv7em-none-eabihf --example testex
[...]
    Finished release [optimized] target(s) in 4.37s
error: couldn't open ELF file `${PWD}/target/thumbv7em-none-eabihf/release/examples/testex`: No such file or directory (os error 2)

I've traced this down to cargo-project's parse<config::Config> method as called by Project::query, but am not sure how to fix it well within the idioms of this crate.

As described in rust-embedded/cargo-binutils#41 cargo-project does not properly support projects consisting of workspaces with cargo projects in them.

Easy test:

$ cat Cargo.toml
[workspace]
members = ["foo"]

cargo-project will explode on this, even though it's a valid cargo configuration.
This blocks cargo-binutils usage in any complex OS project.