`cargo run` without `--bin` builds `lib.rs`

[cecton]

Problem

In a package with a single bin and a lib, cargo run builds lib.rs before building main.rs while cargo run --bin <name_of_the_package> builds only main.rs.

Steps

1. I have a package with a lib.rs that I use for target WASM and a binary main.rs that I use to run a CLI. Some dependencies are only useful for the lib, some other dependencies are only useful for the bin.
2. I use this to distinguish where I want them:

[target.'cfg(target_arch = "wasm32")'.dependencies]
wasm-bindgen = "^0.2"

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
structopt = "0.3"

4. When I do cargo run --bin <name_of_the_package> it builds and run successfully the CLI.
5. When I do cargo run it tries to build lib.rs which fails because the dependencies are not available.

$ cargo run
   Compiling basic v0.1.0 (/home/cecile/repos/wasm-run/examples/basic)
error[E0433]: failed to resolve: use of undeclared crate or module `wasm_bindgen`
 --> src/lib.rs:1:5
  |
1 | use wasm_bindgen::prelude::*;
  |     ^^^^^^^^^^^^ use of undeclared crate or module `wasm_bindgen`

What I expect: running cargo run --bin <name_of_the_package> does exactly the same than cargo run if there is only one bin in the package.

I wouldn't mind too much if it was just the dependencies but this is slowing down a lot the build process as it compiles the lib in WASM for no good reason.

Possible Solution(s)

...

Notes

cargo 1.50.0 (f04e7fab7 2021-02-04)

[cecton]

(I forgot to mention but I don't put any [lib] or [[bin]] in the Cargo.toml. This is why you need to use the package's name with --bin)

[weihanglo]

#8970 also got a similar issue. Maybe they share the same behavior from filter_default_targets.

[cecton]

So I guess it would make sense to add somewhere:

enum DefaultFilterBehavior {
    All,
    Bin,
}

So when running run or install it can be set to DefaultFilterBehavior::Bin and when it is running build, test, ... it can be set to DefaultFilterBehavior::All.

[cecton]

Just trying to complete the "Possible solution(s)" section 😁

[ehuss]

It is normal that there is an implicit dependency from a binary to the library. I'm unable to reproduce your example where cargo run --bin foo works successfully.

$ cargo new foo
     Created binary (application) `foo` package
$ cd foo
$ cat <<EOF >> Cargo.toml
[target.'cfg(target_arch = "wasm32")'.dependencies]
wasm-bindgen = "^0.2"

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
structopt = "0.3"
EOF
$ echo "use wasm_bindgen::prelude::*;" >> src/lib.rs
$ cargo run --bin foo
    Updating crates.io index
   Compiling version_check v0.9.2
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling libc v0.2.88
   Compiling syn v1.0.61
   Compiling bitflags v1.2.1
   Compiling unicode-width v0.1.8
   Compiling unicode-segmentation v1.7.1
   Compiling ansi_term v0.11.0
   Compiling vec_map v0.8.2
   Compiling strsim v0.8.0
   Compiling lazy_static v1.4.0
   Compiling textwrap v0.11.0
   Compiling proc-macro-error-attr v1.0.4
   Compiling proc-macro-error v1.0.4
   Compiling heck v0.3.2
   Compiling quote v1.0.9
   Compiling atty v0.2.14
   Compiling clap v2.33.3
   Compiling structopt-derive v0.4.14
   Compiling structopt v0.3.21
   Compiling foo v0.1.0 (/Users/eric/Temp/foo)
error[E0433]: failed to resolve: use of undeclared crate or module `wasm_bindgen`
 --> src/lib.rs:1:5
  |
1 | use wasm_bindgen::prelude::*;
  |     ^^^^^^^^^^^^ use of undeclared crate or module `wasm_bindgen`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0433`.
error: could not compile `foo`

To learn more, run the command again with --verbose.

If you want the library to work with different targets, you'll need to use #[cfg] conditional compilation. If you want to have a binary that is independent of the library, you'll need to use separate packages.

[cecton]

@ehuss I just checked and it seems you need to add this to your Cargo.toml to reproduce it:

[lib]
crate-type = ["cdylib"]

[ehuss]

Ah, I see, yea the implicit dependency is only added if it is a linkable library. I'm not sure if this can be changed, since there might be projects relying on this behavior. But I can see how it can be a little unclear on how the implicit dependencies work, and there's no real control over them.

[cecton]

Yes 😓 I'm not an expert so for me it just looked surprising at first. That is why I opened an issue for this.

Now I'm not sure. Is it a bug? Is it intended? Is there anything to do about it in cargo? Or should I just find another way to deal with it?

In my opinion it was surprising because I expect the main.rs or lib.rs to be an entry point. From there I expect to use mod to insert more modules. But ok I can accept that the lib.rs is always included.

[cecton]

I have an additional feedback on this.

On a completely unrelated project: I made a crate that is only a bin. Today I wanted to expose some of the functionalities of this crate so I wanted to use it as a lib (and keep the bin). But things don't make much sense:

1. I tried to build the documentation to see what is already public. But since everything is private I was expecting to see absolutely nothing. In fact, I saw all the modules and even the main function despite they are not prefixed by pub.
2. So I made a lib.rs and moved the mod ... from main.rs to lib.rs. Now the binary doesn't compile because it can't find the module. I'm confused because for one moment I thought the lib was always built even if I target the binary. So I guess it is built but it is not used by the bin?

[ehuss]

1. But since everything is private I was expecting to see absolutely nothing.

Binary crate types default to show --document-private-items. This could probably be added to the docs.

2. Now the binary doesn't compile because it can't find the module.

The paths to access items in a library from a binary should be name_of_crate::path::to::item. If you want to create local aliases, you can write use name_of_crate::path::to::item;. This is assuming you're not using cdylib. See chapter 7 of the book for more information on the relation between packages, crates, and modules, and how paths work.