Rust 1.18 regression, isbfc 0.0.1, igo 0.0.2

[brson]

A similar widespread bug was fixed previously (#41797), but I still see a regression in these two crates:

brian@ip-10-145-43-250:~/dev/isbfc⟫ cargo +beta test
   Compiling libc v0.2.20
   Compiling strsim v0.6.0
   Compiling unicode-width v0.1.4
   Compiling bitflags v0.7.0
   Compiling unicode-segmentation v1.1.0
   Compiling ansi_term v0.9.0
   Compiling vec_map v0.6.0
   Compiling term_size v0.2.3
   Compiling clap v2.20.5
   Compiling isbfc v0.0.1 (file:///mnt2/dev/isbfc)
error: couldn't read "src/bin/isbfc.rs": No such file or directory (os error 2)

error: Could not compile `isbfc`.
Build failed, waiting for other jobs to finish...
error: build failed

brian@ip-10-145-43-250:/mnt2/dev/isbfc⟫ rustc +beta -Vv
rustc 1.18.0-beta.4 (0308c9865 2017-05-27)
binary: rustc
commit-hash: 0308c986510a541a9c02bff7f4e239054fa15086
commit-date: 2017-05-27
host: x86_64-unknown-linux-gnu
release: 1.18.0-beta.4
LLVM version: 3.9

[brson]

cc @alexcrichton

[brson]

cc @ids1024

[ids1024]

Here is a minimal test case, with the caveat that I probably really shouldn't have organized that crate the way I did:

Cargo.toml

[package]
name = "bugtest"
version = "0.1.0"

[[bin]]
name = "bugtest"

[[bin]]
name = "bugtest2"

src/lib.rs

fn test() {
}

src/main.rs

fn main() {
}

src/bin/bugtest2.rs

fn main() {
}

Edit: This arguably shouldn't have worked in the first place.

[ids1024]

Anyway, the cause of the issue (and I've verified that igo is the same) is that the crate contains a library and binary with the name of the crate, as well as another binary, but also an explicit [[bin]] section for the main binary. This combination makes it not check src/main.rs but only src/bin/<cratename>.rs.

[alexcrichton]

Thanks for the investigation @ids1024! This is close enough to the release that it's likely to leak into 1.18 though :(

[alexcrichton]

cc @rust-lang/cargo, would anyone be willing to help out investigating this?

[matklad]

I've looked into it and it seems ... complicated. It's another fallout from rust-lang/cargo#3609 I guess, so cc @jmatraszek. Here's the test for Cargo:

#[test]
fn explicit_bins_without_paths() {
    let p = project("foo")
        .file("Cargo.toml", r#"
            [package]
            name = "foo"
            version = "0.1.0"
            authors = []

            [[bin]]
            name = "foo"

            [[bin]]
            name = "bar"
        "#)
        .file("src/lib.rs", "")
        .file("src/main.rs", "fn main() {}")
        .file("src/bin/bar.rs", "fn main() {}");

    assert_that(p.cargo_process("build"), execs().with_status(0));
}

The problem is that the logic for inferring a binary path is quite fiddly and fallbacks to a default instead of erroring, so I am not sure how to fix this particular case without breaking some other.

[brson]

Looks like this is fixed in cargo. We probably need to confirm this is fixed on a particular branch, and get it into the relnotes.

[Mark-Simulacrum]

Closing. I think this was fixed, we can reconsider if necessary and reopen.