"Cargo has produced more than one binary artifact" error even though only one kind: "bin" target is logged

[killercup]

• Which OS: macOS 10.12.6
• Which extension version: 0.8.6
• Which LLDB version: lldb-900.0.64 Swift-4.0
• Which VSCode version: Version 1.23.0-insider (1.23.0-insider) 6d7bb1a174f588360366af26a2ec8f27064ca110 2018-04-26T05:04:58.882Z

What is the problem and how did you get there:

Wanted to try the new release of vscode-lldb by debugging the cli binary from rust-fuzz/targets#103. I added a new "LLDB" configuration from the debug menu, was very positively surprised to see all the cargo targets automatically added (3.5k lines in this particular case), selected "Debug cli" and pressed play.

A model alert told me

Cargo has produced more than one binary artifact

while the Output panel for LLDB (opened automatically) shows:

Running `cargo build --bin=cli --message-format=json`...
    Finished dev [unoptimized + debuginfo] target(s) in 0.41 secs
Matching compilation artifacts: 
{ fileName: '/Users/pascal/Projekte/tools/fuzz-targets/target/debug/cli',
  name: 'cli',
  kind: 'bin' }
{ fileName: '/Users/pascal/Projekte/tools/fuzz-targets/target/debug/cli.dSYM',
  name: 'cli',
  kind: undefined }

What did you expect to have happened instead: Not getting an error

I assume that the dSYM artifact can be skipped safely?

[vadimcn]

I assume that the dSYM artifact can be skipped safely?

The trouble is that cargo's json format is barely documented, so I have to go by trial-and-error to figure out the possible values in its output. And I did not test on MaxOS yet.

Can you try adding "filter": { "kind": "bin" } to the "cargo" clause of your launch config?

[killercup]

"filter": { "kind": "bin" } worked, thanks!

If you can tell me how you parse cargo's messages (or point me to the right place in the code), I can follow up with the cargo team, if you want.

[vadimcn]

@killercup: yeah, it'd be nice if cargo had a story for IDE integration.

The code is here.

I'm assuming that each filename in the "compiler-artifact" message corresponds to a target kind. This is probably wrong... as your example shows.
This may not even be the right message to parse. Surely, Cargo itself knows what the names of the output binaties are going to be. It could just emit this info.

[killercup]

I'm pretty sure better IDE and build system integration is on the agenda of the cargo team. :) I'll try to look into this, but for now I'll

cc @rust-lang/cargo

Edit: Ah, hm, cross-project mentioning of teams doesn't work? Well, in that case, I choose:

cc @alexcrichton @matklad

[matklad]

Heh, I think we have had exactly the same issue in IntelliJ Rust. Here's how we handle it: https://github.com/intellij-rust/intellij-rust/blob/c90bbc7fed95eeb2e603fbb102f88839488ff303/debugger/src/main/kotlin/org/rust/debugger/runconfig/RsDebugRunner.kt#L140-L157

[vadimcn]

@matklad: lol. Ok, I guess I'm gonna have to filter on file names too.

Is there an RFC yet for cargo integration with external build systems / IDEs? (hmm, are those the same thing?)

Edit: Is it this one: rust-lang/rfcs#2136 ?

[matklad]

The RFC for build systems is rust-lang/rfcs#2136.

I don't think there were plans for better integration with IDEs specifically. At least to me, the IDE part seems to be a mostly solved problem, modulo lack of the docs. RLS links directly to Cargo, so it has everything available. IntelliJ uses cargo metadata and --message-format=JSON, and that gives all the necessary info.

The docs are here, but they are "here's the entry point, go figure out everything else yourself": https://doc.rust-lang.org/cargo/reference/external-tools.html :-( I am the person to ping on GitHub/Gitter/IRC if more details are needed :)

[vadimcn]

the IDE part seems to be a mostly solved problem

I would disagree on this one. Yes, we've coded up something that seems to work. But I would expect new edge cases to keep falling out, especially as rustc/cargo evolve. Heuristics like "files ending with dSYM are not runnable binaries" are fragile.
I think there should be a clear answer to "How can an IDE identify debuggable artifacts in cargo output?". Preferably, that should include build scripts as well (so we'll need to know all those environment variables that cargo sets).

[matklad]

But I would expect new edge cases to keep falling out, especially as rustc/cargo evolve.

No disagreement here! I've meant that the basic building blocks are in place, so we only need to fix existing bugs, smooth rough edges and keep up with Cargo's own evolution, and that we don't need an RFC which proposes radically new ways for interaction between Cargo and IDE (which we do need for build-systems stuff).

I've filed rust-lang/cargo#5426 for this specific problem.

For build scripts issue, a somewhat similar thing was tried in rust-lang/cargo#3866: in some cases the environment is important for running the actual binary itself. We eventually postponed that, because that was a fix for a niche problem for integration that hadn't been implemented at that time! Build scripts are an interesting variation of that problem, in that we need the same data (binary + args + env), but, at the same time, we don't want to actually prevent Cargo from running the binaries itself!

[vadimcn]

This should've been fixed in one of the updates.