rust_binary does not produce link in bazel-bin

[dfreese]

My commit a1d8936 caused rust_binary to no longer link into bazel-bin. The binary still is built, and can be run by bazel run, but the binary no longer appears in bazel-bin, just bazel-out. This doesn't appear to be related to depending on a proc-macro, as the following example has this behavior.

# //BUILD
load("@io_bazel_rules_rust//rust:rust.bzl", "rust_binary")

rust_binary(
    name = "check",
    srcs = ["main.rs"],
)

// //main.rs
fn main() {
    print!("hello world\n");
}

Still trying to track down the exact cause of it here, but wanted to flag it in case anyone has noticed this behavior, or similar, and if it's more clear to others as to why this would happen.

Also, I'm not sure what the revert policy is for this project, but I'm perfectly fine reverting it until a fix is found. Let me know.

[kragniz]

Running a build with -s shows that it's changing the rustc --out-dir flag.

With a1d8936:

  /bin/bash -c 'CARGO_MANIFEST_DIR=$(pwd)/server external/rust_linux_x86_64/bin/rustc "$@" --remap-path-prefix="$(pwd)"=__bazel_redacted_pwd' '' server/src/main.rs '--crate-name=server' '--crate-type=bin' '--codegen=metadata=' '--out-dir=bazel-out/k8-fastbuild-ST-5e74b77704d3a70b08875590eb0f067cbb9a6e09f41f090f307cf0d79d4b2461/bin/server' '--codegen=extra-filename=' '--codegen=opt-level=0' '--codegen=debuginfo=0' '--emit=dep-info,link' '--color=always' '--target=x86_64-unknown-linux-gnu' -L external/rust_linux_x86_64/lib/rustlib/x86_64-unknown-linux-gnu/lib '--codegen=linker=/usr/bin/gcc' --codegen 'link-args=-fuse-ld=gold -Wl,-no-as-needed -Wl,-z,relro,-z,now -B/usr/bin -pass-exit-codes -lstdc++ -lm')

With a1d8936 reverted:

  /bin/bash -c 'CARGO_MANIFEST_DIR=$(pwd)/server external/rust_linux_x86_64/bin/rustc "$@" --remap-path-prefix="$(pwd)"=__bazel_redacted_pwd' '' server/src/main.rs '--crate-name=server' '--crate-type=bin' '--codegen=metadata=' '--out-dir=bazel-out/k8-fastbuild/bin/server' '--codegen=extra-filename=' '--codegen=opt-level=0' '--codegen=debuginfo=0' '--emit=dep-info,link' '--color=always' '--target=x86_64-unknown-linux-gnu' -L external/rust_linux_x86_64/lib/rustlib/x86_64-unknown-linux-gnu/lib '--codegen=linker=/usr/bin/gcc' --codegen 'link-args=-fuse-ld=gold -Wl,-no-as-needed -Wl,-z,relro,-z,now -B/usr/bin -pass-exit-codes -lstdc++ -lm')

and bazel-bin/server/server exists

[damienmg]

This is a weird impact of using configuration. @gregestren might know a bit more about that.

I have some reserve about a1d8936 as it adds a configuration that seems to be a host configuration which would explain why it is not in the good output.

[dfreese]

It appears to be something with how Bazel handles any translation added to the cfg parameter. If I replace proc_macro_host_transition with noop_transition the effect is the same for the example; bazel-bin is no longer populated.

def _noop_transition(settings, attr):
    return settings

noop_transition = transition(
    implementation = _noop_transition,
    inputs = [],
    outputs = [],
)

Perhaps there should be a different approach than transitions?

[gregestren]

Without digging too deeply into this, also note this flag:

https://github.com/bazelbuild/bazel/blob/c3bcb9838e17d08da0b7f30cbb0e4e284506748b/src/main/java/com/google/devtools/build/lib/buildtool/BuildRequestOptions.java#L312

which resolves this problem as long as all targets use the same transition.

If not all targets use the same transition we run into fundamentally harder issues described in https://docs.google.com/document/d/1fZI7wHoaS-vJvZy9SBxaHPitIzXE_nL9v4sS4mErrG4/edit