Error related to rust-cargo

[carlosgaldino]

Suspicious state from syntax checker rust-cargo: Checker rust-cargo returned non-zero exit code 101, but no errors from output: extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing e.g. `--lib` or `--bin NAME` to specify a single target

I believe this is related to #16 and #18. I'm using the latest version from Dec 25 and getting this message when I save any file on my project. The project layout is:

src/
├── config.rs
├── error.rs
├── lib.rs
├── main.rs

Any ideas about this? Is there something I'm doing wrong?

Thank you.

[carlosgaldino]

When I run M-x flycheck-compile on config.rs and select rust-cargo I get:

cargo rustc -- -Z no-trans --test -L/Users/carlosgaldino/code/goethite/target/debug -L/Users/carlosgaldino/code/goethite/target/debug/deps
extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing e.g. `--lib` or `--bin NAME` to specify a single target

When I run the same command on main.rs I get:

cargo rustc -- -Z no-trans -L/Users/carlosgaldino/code/goethite/target/debug -L/Users/carlosgaldino/code/goethite/target/debug/deps
extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing e.g. `--lib` or `--bin NAME` to specify a single target

Just like reported on #16.

[swsnr]

@carlosgaldino Would you mind to show your Flycheck and Flycheck Rust setup?

[carlosgaldino]

@lunaryorn I'm using Spacemacs so the config is the following: https://github.com/syl20bnr/spacemacs/blob/v0.105.4/layers/%2Blang/rust/packages.el#L24-L32

[carlosgaldino]

@lunaryorn Sorry. I forgot to add flycheck config. That was flycheck-rust config. flycheck config is the following: https://github.com/syl20bnr/spacemacs/blob/v0.105.4/layers/syntax-checking/packages.el

[swsnr]

Can you provide the versions of Flycheck and Flycheck Rust installed in your Emacs? And name your Rust version?

[carlosgaldino]

flycheck-rust: 20151225.713
flycheck: 20160106.544
rust: 1.5.0

[swsnr]

@mkpankov I think I'll need your help here. Since #18 Flycheck Rust always picks the "binary" crate type if there's a src/main.rs. However with that crate type the rust-cargo syntax checkers doesn't pass any target to cargo rustc, hence this error.

I'm not sure how we could solve that. Passing --bin doesn't really work without additional code that tries to find out the name of the executable target.

[mkpankov]

@lunaryorn thank you for invitation to the org! 😉

I'll try to work on the issue on weekend, but unfortunately can't promise anything.

[swsnr]

@mkpankov You're welcome. I meant to write you a mail, but I forgot ☺️ Please take all the time you need :)

[mkpankov]

Ok, I've been able to reproduce the issue. This is the test project I've setup. Flycheck breaks in main.rs.

It's indeed the case that cargo rustc -- -Z no-trans won't work if there are multiple targets, like in this case. So we should use cargo rustc --bin <BINARY_NAME> -- -Z no-trans or cargo rustc --lib -- -Z no-trans, depending on buffer we want to check: if it's main.rs, we should use --bin form, otherwise, the --lib one. It's a simplification, but it should do, for now.

So, I propose adding a new variable, i.e. flycheck-rust-binary-name, to be set to name of the binary. Usually, the first binary is named the same as the crate itself - in my test crate I had to pass --bin test.

Another question, then, is where do we get its value from. I found cargo read-manifest command - apparently it's an official way of reading metadata in JSON and works from any place in crate tree. What it gives us is

{"name":"test","version":"0.1.0","dependencies":[],"targets":[{"kind":["lib"],"name":"test","src_path":"/home/mkpankov/flycheck-rust/tests/main-and-lib/test/src/lib.rs","metadata":{"metadata":"06b476a90b7dc18d","extra_filename":"-06b476a90b7dc18d"}},{"kind":["bin"],"name":"test","src_path":"/home/mkpankov/flycheck-rust/tests/main-and-lib/test/src/main.rs","metadata":null}],"manifest_path":"/home/mkpankov/flycheck-rust/tests/main-and-lib/test/Cargo.toml"}

Then, we should go over the "targets" array, and when "src_path" matches, we have the binary name in "name" in same array element.

I feel I oversimplify things and proposed solution lacks generality, but well, we have to work off something. I propose digging this way first to find out how good this scheme is.

@lunaryorn do you think you could take a shot at implementing this? I have nearly no time to work on flycheck, unfortunately, and I think this will take me quite some time to get familiar with the toolkit.

[swsnr]

@mkpankov I don't think so, at least any time soon.

Adding an option to Flycheck is simple, but digging through the Cargo layout to guess the executable name is more than I have time for currently. Besides, I don't really use Rust in any complicated setup, and am not personally affected by this problem.

My personal focus is on the many open tasks in Flycheck, particularly on writing documentation for contributors and maintainers, which is crucial to ensure that Flycheck is able to continue evolving as fast as it used to do in the past. Working on individual language support has to stand back, the more when I'm not affected personally.

I'm sorry.

That said, your approach sounds interesting, and I think it'll get us a huge step closer to good Rust support in complex projects. I hope that someone from the community picks this up and gives it a shot ☺️

[tomjakubowski]

I feel I oversimplify things and proposed solution lacks generality, but well, we have to work off something. I propose digging this way first to find out how good this scheme is.

I think it should work up to the point where a bin file has submodules implemented in other files. For example:

src/
  lib.rs
  bin/
    common.rs
    foo.rs

// src/bin/foo.rs

extern crate my_crate;

mod common;

fn main() { }

// src/bin/common.rs

pub fn some_common_thing() { }

If you edit src/bin/common.rs, flycheck won't know which target to build. It gets even more questionable if a module is shared by multiple targets (arguably a bad practice…). But I agree this is a good start, at least until such time as Cargo can provide tools with dependency information at the granularity of files/modules.

[tgroshon]

Any luck on this? I also have this problem.

[djanderson]

I am still able to reproduce this error with latest rust/cargo/emacs

The exact error:

Suspicious state from syntax checker rust-caro: Check rust-cargo returned non-zero exit code 101, but no errors from output: error: no library targets found

Check definition probably flawed

$ emacs-snapshot --version
GNU Emacs 25.1.50.2
$ rustc --version
rustc 1.11.0 (9b21dcd6a 2016-08-15)
$ cargo --version
cargo 0.12.0-nightly (6b98d1f 2016-07-04)

flycheck           20160902.523
flycheck-rust      20160816.236

Steps to reproduce:
(following cargo guide here: http://doc.crates.io/guide.html)

1. $ cargo new hello_world --bin
2. open hello_world/src/main.rs

[fmdkdd]

@djanderson Hmm I cannot reproduce under Emacs 24.5.1 or 25.1.1.

I have no error when opening hello_world/src/main.rs, and introducing a syntax error and saving the file does trigger flycheck, as expected.

$ rustc --version
rustc 1.11.0
$ cargo --version
cargo 0.12.0 (6b98d1f 2016-07-04)

Same flycheck and flycheck-rust as you.

[buster]

It's not working for me either.
I'm using spacemacs and just created a a new project.

To be honest, i don't understand why it says "no such subcommand".
When i run "flycheck-compile" and "rust-cargo" it shows the following:

cargo rustc --lib -- -Z no-trans -Z unstable-options --error-format\=json --test No such subcommand Did you meanrun?

But first of all, my directory structure shows no "library". I have no [lib] entry in the Cargo.toml and only one file: src/main.rs.

And second of all, why does it say "no such subcommand"? Because i can run this command in the terminal and that gives the error "error: no library targets found".

[buster]

I have found that /usr/bin/cargo was an old version and that's why flycheck-rust did get "no such subcommand".
Now, flycheck doesn't find my cargo installation in $HOME/.cargo/bin. Is that normal?

[fmdkdd]

@buster Are you using rustup? Flycheck will look for the cargo executable in your PATH environment variable. If $HOME/.cargo/bin isn't on your path, then you can either add it or set the variable flycheck-rust-cargo-executable to point to cargo's location.

In a rust file in your cargo project, you can use flycheck-verify-checker and select rust-cargo to check if flycheck finds the executable.

[djanderson]

@fmdkdd, well, I'm embarrassed to say that I was able to fix the issue by actually RTFMing your README :) I was already using flycheck for several other languages and so just copy/pasted one and added the hook to rust-mode, but when I added (add-hook 'rust-mode-hook #'flycheck-rust-setup) to init.el, as you say to do, the error went away. Sorry for the noise!

[buster]

@fmdkdd: Yes, i am using rustup. Somehow emacs didn't pick up my PATH variable. I'l' set flycheck-rust-cargo-executable.. It works now, thanks!

[buster]

@fmdkdd Does flycheck-rust have such a variable? Looking in the source i can't find a reference to it... I don't know flycheck or elisp, so i may be missing something..

[swsnr]

@buster Yes, it does. Flycheck implicitly defines such a variable for all syntax checkers. Take a look at C-h v flycheck-rust-cargo-executable.

[fmdkdd]

@djanderson Glad to know it's working for you now :)

@buster @lunaryorn Implicitly defined variables always trip me up too, since jumping to definition from the help buffer does not work. Even though the docstring does tell its purpose, it also states that the value is "nil", but then at the end of the docstring actually tells you the default is "cargo". Still, it's good that we can override the executable for every checker, as in this case it proves useful.

Looking at the manual at http://www.flycheck.org, it seems this functionality is only referenced in the first screenshot of the 'Quickstart' section, in the flycheck menu. The menu is very good for discoverability, but I wonder how many users toggle them off... (I know I do).

[swsnr]

@fmdkdd Would you rather define this variable explicitly for each of the 80 syntax checkers we support?

I'm aware that this part of Flycheck isn't documented in the manual, see flycheck/flycheck#927: Configuration of checkers is still missing. I'll add it at some point but given that it's got a docstring, is referred to in the docstring of each syntax checker and an option that's probably not of so much use (you'll more likely change $PATH and exec-path, on Unix at least) I just had different priorities so far. If you think that it's urgent to document these options in the manual please leave a comment on flycheck/flycheck#927.

I'm not actually sure whether the variable is really the place to go in this case. Assuming that @buster is on OS X a proper $PATH in the shell configuration and exec-path-from-shell are probably the way to go instead.

[fmdkdd]

@lunaryorn It's a tradeoff. I'd rather have Emacs tell me it's a custom variable defined by a macro, at least.

Good to know that documentation is coming. Let me know if I can help in any capability.

[swsnr]

@fmdkdd Any contribution to the documentation would be very welcome :) I've been planning to write more for a long time, but then I thought it'd be more important to provide good documentation for new contributors which is why I spent most of my documentation efforts on the contributor and maintainer guide and automated a lot of our processes (like releases, etc.).

I'm not sure in how far we can bent Emacs to improve the docstrings and the "source discoverability" of these variables. When I chose to auto-generate the definitions it was because I didn't want to write those definitions for 80 checkers—I didn't care much about documentation. Maybe we can find a better way to handle these definitions. If you'd like please open a new issue in the main tracker so that we can discuss possible improvements.

[apiraino]

Hello,

not sure it's related, I get a slightly different error when compiling an .rs file outside the src directory. Here's my project tree:

$ tree
.
├── Cargo.lock
├── Cargo.toml
├── examples
│   └── test.rs
├── prova
│   └── test.rs
├── src
│   └── test.rs

test.rs is being copied in those three dirs, it's exactly the same file. If I open src/main.rs and prova/test.rs Flycheck runs fine; on example/test.rs I got the error:

Suspicious state from syntax checker rust-cargo: Flycheck checker rust-cargo returned non-zero exit code 101, but its output contained no errors: eeror: no library targets found

Try installing a more recent version of rust-cargo, and please open a... etc. etc.

I can reproduce running the cmd manually:

$ cargo rustc --lib --message-format\=json -- -Z no-trans --test -L/home/user/myprj/target/debug -L/home/user/myprj/target/debug/deps                        
error: no library targets found                                                                 

Currently running on:

flycheck: 20170309.145
flycheck-rust: 20161019.1103
rustc: 1.15.1 (021bd294c 2017-02-08)
cargo 0.16.0-nightly (6e0c18c 2017-01-27)

I'm starting now with Rust, but it is my understanding that the example dir is a special one: could it be related to the issue?

Thanks for any hint!

[fmdkdd]

@apiraino Yes, example is currently not supported by Flycheck, and that should be fixed by flycheck/flycheck#1206 that hasn't been merged yet.