Almost all tooling in the rust ecosystem depends on at least Cargo.toml files and cargo metadata. It would be good to generate the manifests.

https://github.com/mfarrugi/rules_rust/tree/marco-generate-cargo-toml/aspect is a WIP that uses an aspect to generate the information, and then a shell script to move it to the right places. I'm not confident that is the correct way to work with aspects, if anyone has thoughts I would be glad to hear them.

A little bit of the tangent is the aspect uses some of the utilities in toolchain.bzl, it would be good to separate those into another file, are there any qualms with that? And then there is bike-shedding on where the aspect/shell-script should go directory-structure-wise.

Edit:
Updated wip to https://github.com/mfarrugi/rules_rust/blob/marco-generate-cargo-toml/rust/aspect/generate_cargo_workspace.sh

It looks like https://github.com/bazelbuild/rules_rust/blob/master/rust/rust.bzl#L342 is not quite right, and we need to fish out the .so.1.0 links from the binary.

@damienmg is there a straight forward way to getthe symlink paths? If not I will spend some time spelunking in whatever the cc_* rules currently expose.

• Do the same thing as Java et al (eg. bazelbuild/bazel#6228)
• Reenable runfiles tests on CI. (Fixes part of #112 )
  

  rules_rust/.bazelci/presubmit.yml

  Lines 33 to 35 in ab32ede

  	# Runfiles currently not working properly with remote execution
  	# https://github.com/bazelbuild/rules_rust/issues/112
  	- "-@examples//hello_runfiles:hello_runfiles_test"

• Export the library as something like @io_bazel_rules_rust//runfiles instead of @io_bazel_rules_rust//examples/​hello_runfiles:runfiles"
• make rest of examples private

rust-lang/rfcs#2136

This explicitly mentions bazel. Someone from this project should review that RFC and make sure any obvious points are missed.

This WORKSPACE and custom_rust_toolchain.bzl is an example of setting up toolchains outside of the default one that is part of these rules.

Is the toolchain feature stable enough to update the documentation to recommend this flavor of custom toolchain configuration? Is it possible to configure targets to require different toolchains (eg. targets that are nightly only)?

Hello dear rules owners,

I see that bazel@HEAD breaks rules_rust: https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/386#183d2d56-2b16-4010-9373-ef1b3b66b6eb

Would you mind taking a look? Thank you very much!

This is the announcement email:
We are very close to remove in-memory //tools/default* package in favor of using @bazel_tools//tools/jdk: and @bazel_tools//tools/cpp: instead.
The changes will be ready with next release.

Motivation:
//tools/default was initially created as virtual in-memory package. It generates content dynamically based on current configuration. There is no need of having //tools/defaults any more as LateBoundAlias can generate dynamic configuration-based label resolving. Also, having //tools/default makes negative impact on performance, and introduces unnecessary code complexity.

All references to //tools/defaults:* targets should be removed or replaced to corresponding target in @bazel_tools//tools/jdk: and @bazel_tools//tools/cpp: packages.

Scope of changes and impact:
All targets in //tools/default will not exist any more. If you have any references inside your BUILD or *.bzl files to any of its, then bazel will fail to resolve.

Migration plan:

Please replace all occurrences:

//tools/defaults:jdk
-- by @bazel_tools//tools/jdk:current_java_runtime
-- or/and @bazel_tools//tools/jdk:current_host_java_runtime

//tools/defaults:java_toolchain
-- by @bazel_tools//tools/jdk:current_java_toolchain

//tools/defaults:crosstool
-- by @bazel_tools//tools/cpp:current_cc_toolchain
-- or/and @bazel_tools//tools/cpp:current_cc_host_toolchain
-- if you need reference to libc_top, then @bazel_tools//tools/cpp:current_libc_top

These targets will not be supported any more:
//tools/defaults:coverage_report_generator
//tools/defaults:coverage_support

Currently, the version of Rust used by the rules are not easily configurable. We should make it easier to use the Rust rules with different Rust versions, such as via a rust_toolchain rule (similar to cc_toolchain) or look at the approach taken by tools such as multirust.

It would also be good to make it easy to switch between having Bazel download a set of Rust binaries and using the ones installed on the local system.

Simple repro case is in this branch.

bazel run @examples//hello_world exposes the problem.

The example is a simple dependency chain: rust_binary ("hello_world") depends on rust_library ("hello_from_c_sys") which depends on cc_library ("hello_from_c"). The c library requires c++, therefore needs linking with -lstdc++. It should be sufficient to specify this in the rust_library rule, but right now all rust_binary rules that transitively depend on the lib need to specify it as well: https://github.com/bazelbuild/rules_rust/compare/master...SirVer:link_example?expand=1#diff-e85472ad14a7cde9a8510d9beae332c5R18

Howdy!

I have a cargo manifest like so:

[package]
name = "my-app"
version = "0.1.0"
authors = [<me>]

[dependencies]
libc = "0.2"
log = "0.4"
env_logger = "0.5"
bytes = "0.4"
failure = "0.1"
futures = "0.1"
tokio = "0.1"
tokio-signal = "0.2"
qp-trie = "0.7"
rmp = "0.8"
rmpv = "0.4"

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

In src I have lib.rs and main.rs. Using cargo I get 3 artifacts that are used by other parts of the existing build: libmy_app.so, libmy_app.rlib, and the program my-app.

I can get a working bazel build with something like this:

package(default_visibility = ["//visibility:public"])

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

COMMON_DEPS = [
    "//vendor/crates:libc",
    "//vendor/crates:log",
    "//vendor/crates:env_logger",
    "//vendor/crates:bytes",
    "//vendor/crates:failure",
    "//vendor/crates:futures",
    "//vendor/crates:tokio",
    "//vendor/crates:tokio_signal",
    "//vendor/crates:qp_trie",
    "//vendor/crates:rmp",
    "//vendor/crates:rmpv",
]

rust_library(
    name = "my_app_client",
    srcs = ["src/lib.rs"],
    deps = COMMON_DEPS,
    crate_type = "cdylib",
)

rust_binary(
    name = "my_app",
    srcs = ["src/main.rs"],
    deps = COMMON_DEPS,
)

But this gives me a binary my_app instead of my-app which is probably something I can live with; but my shared library is just totally wrong now libmy_app_client--<HASH>.so.

I'm generating the header for the library using cbindgen and this shared library is used in other parts of our build so the name isn't entirely a problem for that purpose, but it is also part of the package given to clients so this is ultimately not going to work.

I've tried to use -o libmy_app.so in the rustc flags but the build fails because it can't find libmy_app_client-<HASH>.so. :D Looks like bazel and I are at another impasse.

Am I missing an obvious solution or configuration here?

It would be nice to make bindgen easily available, asking users to provide an llvm label.

@acmcarther did you mentioning having this implemented somewhere already?

https://ci.bazel.build/blue/organizations/jenkins/Global%2Frules_rust/detail/rules_rust/412/tests

Platforms:

• darwin-x86_64

Let's document the Rust rules using Skydoc and serve the HTML docs to make the easier to browse.

I am working with VSCode and while it is super nice with Rust & Cargo, RLS bugs out with Bazel. I am actually contemplating shaving that yak further and modifying RLS and VSCode RLS to support generic build system but I have resisted the temptation so far so I am creating a bug here so it doesn't get lost.

Might be a workaround to use #71.

Add support for using Rust compiler plugins.

Because plugins are an unstable feature, #14 would also make this easier to use for developers.

A lot of tests are failing on RBE when I tested with #111 where I added the Buildkite config to test against RBE. You can find the set of tests that are failing in the PR (https://github.com/bazelbuild/rules_rust/pull/111/files) where I have to skip them.

We previously tested rules_rust repo at commit ef77316 internally and this set of test targets pass on RBE:

-- @examples//... -@examples//hello_runfiles:hello_runfiles_test

It's likely there is some regression between ef77316 and 1944c8a

Due to some problems in rust:
http://ci.bazel.io/job/rules_rust/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/36/console

 LD_LIBRARY_PATH=external/rust_linux_x86_64/rustc/lib DYLD_LIBRARY_PATH=external/rust_linux_x86_64/rustc/lib external/rust_linux_x86_64/rustc/bin/rustc examples/fibonacci/benches/fibonacci_bench.rs --crate-name fibonacci_bench_bin --crate-type lib -C opt-level=3 --codegen ar=/usr/bin/ar --codegen linker=/usr/bin/gcc --codegen link-args='\'''\'' -L all=external/rust_linux_x86_64/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib --out-dir bazel-out/local-fastbuild/bin/examples/fibonacci --emit=dep-info,link --test -L dependency=bazel-out/local-fastbuild/bin/examples/fibonacci/fibonacci_bench.deps --extern fibonacci=bazel-out/local-fastbuild/bin/examples/fibonacci/fibonacci_bench.deps/libfibonacci.rlib').
examples/fibonacci/benches/fibonacci_bench.rs:15:1: 15:18 error: #[feature] may not be used on the stable release channel
examples/fibonacci/benches/fibonacci_bench.rs:15 #![feature(test)]

Many Rust crates have a build.rs build script that is used for arbitrary build tasks before anything else in the crate is built. We should have equivalents for the common use cases that Rust build scripts are used for.

From the Cargo documentation, some of the tasks that can be handled by build.rs include:

• Building a bundled C library.
  • This is covered by the C interoperability that the Bazel Rust rules already support
• Finding a C library on the host system.
  • This can be done with Skylark repository rules, though the rules for finding specific libraries still need to be written.
• Generating a Rust module from a specification.
  • The best way to do this could be just building build.rs as a rust_binary then having something like a genrule target that runs the binary and have the expected output file(s) be inputs to the rust_binary or rust_library target that includes the generated file(s).
  • The key is to make this easy to use for users.
• Performing any platform-specific configuration needed for the crate.
  • I think this can also be done using Skylark repository rules.

Please update the @bazel-toolchains pin to the latest as described here: https://releases.bazel.build/bazel-toolchains.html.

The Buildkite configuration for RBE builds/tests has been modified to use the latest configs from @bazel-toolchains which are only available at the latest release of the repo. You might have already got the following error in the RBE Ubuntu1604 Buildkite builds/tests:

ERROR: no such package '@bazel_toolchains//configs/ubuntu16_04_clang/1.0/bazel_0.16.1/default': BUILD file not found on package path

Update the @bazel-toolchains pin to latest will resolve the above issue.

In the future, if you see a similar error like the above, it might be your @bazel-toolchains pin is out-of-date again.

Currently, the rust_library rule only outputs rlibs regardless of the value of crate_type. In order to correctly support all the different crate types, `rust_library should produce the crates with the correct file extensions.

Proposal

• Make the rust_library rule internal by renaming it to _rust_library
• Add a new outs attribute to the _rust_library rule to support custom outputs
• Add a rust_library macro that wraps the _rust_library rule. Based on the value of crate_type, it adds a _rust_library rule with outs set with the name of the output library with the correct file extensions according to the Rust documentation

A couple things have not kept up with changes in bazel and skylark, from what I've gathered there's:

• toolchain.bzl is somewhat misnamed since toolchain became a bazel term

  • I would like to split this into rustc.bzl, toolchain.bzl, and maybe additional files. Should we split up rust.bzl some amount as well?

• skylark has changed, in particular providers, running commands (eg. run_shell), and some other apis

  • rust_toolchain can require single labels/files using [attr.label(allow_single_file)]
  • instances of command building should use run_shell
  • struct usages should be providers
    (https://docs.bazel.build/versions/master/skylark/lib/attr.html#label)
  • Deprecations:
    • FileType

• rust.bzl might want to more carefully export an api, and/or look more like https://github.com/bazelbuild/rules_go/blob/master/go/def.bzl#L83

• mixing of % and .format strings

  • can move all to format?

• rust_bench_test shouldn't be marked as a test

• _setup_deps might not want to be producing compiler flags etc

  • This has been somewhat awkward, but the codebase is small enough that moving it closer to build_rustc_command etc has felt unecessary

All in all I think these are all cosmetic, though the newer Args api might give tiny performance improvements that are pointless in the face of rustc. I'm also not excited to fix deprecations without a clearer timeline to bazel 1.0

@acmcarther is there anything else to add to the list? And what do you think is worth fixing?

I wanted to run some of the rust examples in a docker container, built using bazel, but get:

/workspace # bazel build //...
WARNING: Failed to set up cache at /root/.cache/bazel/_bazel_root/cache/repos/v1: /root/.cache/bazel/_bazel_root/cache/repos/v1 ()
ERROR: error loading package '': Encountered error while reading extension file 'rust/repositories.bzl': no such package '@io_bazel_rules_rust//rust': /root/.cache/bazel/_bazel_root/eab0d61a99b6696edb3d2aff87b585e8/external/@io_bazel_rules_rust.marker (No such file or directory)
ERROR: error loading package '': Encountered error while reading extension file 'rust/repositories.bzl': no such package '@io_bazel_rules_rust//rust': /root/.cache/bazel/_bazel_root/eab0d61a99b6696edb3d2aff87b585e8/external/@io_bazel_rules_rust.marker (No such file or directory)
INFO: Elapsed time: 0.437s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)

I also get the following from time to time, dunno what that's about:

/workspace # bazel build //...
ERROR: bazel should not be called from a bazel output directory.

My current setup:

Am using local docker image FROM alpine:3.8 using glibc 2.27-r0, jdk1.8.0_172, bazel-0.15.0-dist

╰─➤  docker run -ti -v "${DIR}/tutor:/workspace/tutor <image id>  

/workspace:

.
├── WORKSPACE
└── tutor
    ├── BUILD
    └── src
        └── main.rs

2 directories, 3 files

/workspace/WORKSPACE:

http_archive(
    name = "io_bazel_rules_rust",
    sha256 = "615639cfd5459fec4b8a5751112be808ab25ba647c4c1953d29bb554ef865da7",
    strip_prefix = "rules_rust-0.0.6",
    urls = [
        "http://bazel-mirror.storage.googleapis.com/github.com/bazelbuild/rules_rust/archive/0.0.6.tar.gz",
        "https://github.com/bazelbuild/rules_rust/archive/0.0.6.tar.gz",
    ],
)

load("@io_bazel_rules_rust//rust:repositories.bzl", "rust_repositories")

/workspace/tutor/BUILD:

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

rust_binary(
    name = "tutor",
    srcs = [
        "src/main.rs",
    ],

/workspace/tutor/src/main.rs:

fn main() {
    println!("1 - 2 = {}", 1i32 - 2);
}

This may be more of a bazel question but since it's in the context of rust, I figured the audience here is as good as any 😄 .

Suppose we have the following targets:

1. cc_library building some static lib
2. rust_library FFI wrapper over the above
3. rust_binary that uses the rust_library

Pretty standard and simple setup for rust using c/c++ code.

In a dbg or fastbuild setup, it seems the above just works. However, when I recently tried this with an opt build using a custom cc toolchain, the code failed to link. Quick note on the custom toolchain - it's very close to the configuration/setup of bazel's builtin crosstool but uses vendored gcc (and related tools).

The link failure was around invalid relocations. This is because rustc, by default, wants to build position-independent (PIE) executables. To do that, the c/c++ static libs need to be built with -fPIC - building the cc_library as PIC fixes the issue. However, this requires modifying a target whose other downstream users may not want to be PIC'd (and PIC can have non-zero perf cost, albeit low from what I gather).

The other fix that I came across is changing the rust_binary target to specify a codegen option to rustc: --relocation-model=static. This builds a non-PIE binary, and doesn't require -fPIC on the dependent cc libs.

This feels ... wrong, however. Either I'd need to modify all rust binary targets to select static relocation, or I'd need to modify the c/c++ static libs to be PIC. I also don't know why there's a difference between dbg/fastbuild and opt builds.

Does anyone know if there's a better way to control linkage and relocation model? Ideally (I think), a rust_binary would select the linkage it wants (static or dynamic) and the relocation model (static or dynamic), and this choice would flow down to dependent libs, where bazel would build them as either static or dynamic libs and also select -fPIC or not.

Curious to hear thoughts/suggestions.

cc @mfarrugi as he's interested in this as well, I believe.

My use case is to swap out unsafe C with save rust implementations. To keep APIs in tact, I need to provide a C library that bridges to Rust. I was trying to do this:

package(default_visibility = ["//visibility:public"])

load(
    "@io_bazel_rules_rust//rust:rust.bzl",
    "rust_library",
)

rust_library(
    name = "greeter",
    srcs = ["lib.rs"],
)

cc_binary(
   name = "rust_from_c",
   srcs = ["hello_world.cc"],
   deps = [":greeter"],
)

with lib.rs:

#[no_mangle]
pub extern "C" fn greet(){
    println!("Hello from rust!");
}

and hello_world.cc:

void greet();
int main(int argc, char *argv[])
{
	greet();
	return 0;
}

This should conceptually work, but bazel refuses:

ERROR: /usr/src/app/rust_from_c/BUILD:18:14: in deps attribute of cc_library rule //rust_from_c:greeter: rust_library rule '//rust_from_c:greeter_rust' is misplaced here (expected cc_inc_library, cc_library, objc_library or cc_proto_library)

Is there a way to call rust code from C?

@damienmg @ulfjack Is there a possibility to hand out write rights for this repository? For example @acmcarther is a Googler that has an interest in improving these rules. We from Lyft Germany also need these rules to be polished before they fulfil our needs. Right now there are forks floating around which is never ideal.

I understand that this repo is not a high priority for core bazel atm. However, there are pull requests sitting unanswered and most of them could be easily resolved without the core bazel team needing to look at. Could you turn maintenance of these rules over to the community by handing out write bits?

Example of Issue

1. Generate two files: //anything/lib.rs, //anything/dependency.rs in a workspace with the required rust rules loaded.
2. Provide the following body to "lib.rs"

mod dependency;

3. Specify the following build rule in //anything/BUILD:

rust_library(
  name = "anything",
  srcs = [
     "lib.rs",
     # Note the omission of dependency.rs
  ]
)

4. Attempt to build :anything

Expected output

anything/lib.rs:1:5: 2:9 error: file not found for module `dependency`

Actual output

Target //anything:anything up-to-date:
  bazel-bin/anything/libanything.rlib

This allows our :anything build rule to violate hermeticity because rustc will automatically search and include any *.rs files corresponding to mod declarations. Since those files are not explicitly required, bazel will not know to monitor them.

Suggested Solution

I believe we need to modify our call of rustc to:

1. Explicitly take all source files, instead of just lib.rs (or equivalent crate-root)
2. Deny automatically patching files in.

I don't know enough about rustc to know if those are possible at this time without doing something tricky, though I'd be willing to investigate.

An alternate approach if rustc does not provide the necessary functionality:

1. Move the src files to some separate fresh build location
2. Run rustc as we currently run it -- against just the crate-root .rs

Howdy!

I'm not sure if this is related to #101 or not but I had expected this to work:

rust_repository_set(
    name = "rust_linux_x86_64",
    exec_triple = "x86_64-unknown-linux-gnu",
    extra_target_triples = [
        "aarch64-unknown-linux-gnu"
    ],
    version = "1.27.2",
)

The error I get:

ERROR: /home/kopernikus/.cache/bazel/_bazel_kopernikus/3b8e07831dccba8888e630aef5b461f7/external/rust_linux_x86_64_toolchains/BUILD:11:1: no such target '@bazel_tools//platforms:aarch64': target 'aarch64' not declared in package 'platforms' defined by /home/kopernikus/.cache/bazel/_bazel_kopernikus/3b8e07831dccba8888e630aef5b461f7/external/bazel_tools/platforms/BUILD and referenced by '@rust_linux_x86_64_toolchains//:toolchain_for_aarch64-unknown-linux-gnu'
ERROR: While resolving toolchains for target //components/services/kpns-bus/rust:kpns-bus: invalid registered toolchain '@rust_linux_x86_64_toolchains//:toolchain_for_aarch64-unknown-linux-gnu': Analysis failed
ERROR: Analysis of target '//components/services/kpns-bus/rust:kpns-bus' failed; build aborted: invalid registered toolchain '@rust_linux_x86_64_toolchains//:toolchain_for_aarch64-unknown-linux-gnu': Analysis failed
INFO: Elapsed time: 0.751s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (3 packages loaded)

What "extra_target_triples" seemed to be was the ability to have this pull down appropriate versions of the stdlib for alternate targets in the style of rustup target add aarch64-unknown-linux-gnu.

Creating a tool for generating BUILD/WORKSPACE files from Cargo.toml+Cargo.lock would be very useful and would greatly lower the barrier for Rust developers who are used to Cargo to use Bazel to build Rust projects.

This would be similar in concept to the glaze tool for generating BUILD files for Go projects (bazelbuild/rules_go#15).

One possible fun name for this tool: raze

The Rust version in rust/repositories.bzl seems a bit old.
Would you guys please consider updating to Rust 1.20+(it seems that the archive is stored on Google's storage).
Besides the features that were released meanwhile(before the 1.20 release), 1.20 has some important things like:

• @pcwalton(Servo team) finished up the stack probes support in LLVM(for x86/x86_64) and the Rust support for them landed in 1.20 - this prevents stack overflows from going outside the application's memory.
• -Z relro-level=[full,partial,off] - again, for security-aware software.

I ran into

...
                rust_binary(name = 'hello')                    
        File "/home/marco/.cache/bazel/_bazel_marco/405dd47089fd4396034c2fe0895614dc/external/io_bazel_rules_rust/rust/rust.bzl", line 366, in _rust_binary_impl                                                                                               
                _setup_deps(ctx.attr.deps, ctx.label.name, outpu..., ...)                                                      
        File "/home/marco/.cache/bazel/_bazel_marco/405dd47089fd4396034c2fe0895614dc/external/io_bazel_rules_rust/rust/rust.bzl", line 142, in _setup_deps                                                                                                     
                set()                                          
The `set` constructor for depsets is deprecated and will be removed. Please use the `depset` constructor instead. You can temporarily enable the deprecated `set` constructor by passing the flag --incompatible_disallow_set_constructor=false.      

and assume other rules are similarly affected.

Is this being fixed already?

set is now deprecated in favor of depset. The git repo has these changes but importing the latest release with http_archive (0.0.5) is still not updated.

Bazel is planning to move away from native rules for external repositories to Skylark rules, mainly because bundling every version control system in bazel does not scale. As part of this effort, we plan to submit https://bazel-review.googlesource.com/c/bazel/+/55932 soon, which will cause bazel by default to insist that the skylark versions the git and http rules for external repositories be used. This can be disabled by a flag for at least the next 6 months, but we still would appreciate if you could adopt your repository to use the Skylark versions of those rules soon.

A test run of downstream projects with that flag flip in bazel enabled can be found at https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/286

For more background, see

• the original announcement https://groups.google.com/d/topic/bazel-discuss/dO2MHQLwJF0/discussion
• and the documentation of the incompatible changes https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#remove-native-git-repository

Thanks.

Version 0.0.1 fails on bazel 0.2.3.

The fixes from this PR are required: #6

Please tag a new release.

Minimal repro case with a potential (but ugly) fix:

https://github.com/bazelbuild/rules_rust/compare/master...SirVer:00_include_genfiles?expand=1

The linked branch does the following changes:

1. Add a genrule call that trivially creates a file containing a string.
2. The goal is to include_str! this file in hello_world.rs. Code for this is here. For this to ever work, the genfile is made a data dependency of the rust_binary.
3. I could not pull this off without exposing bazel's ctx.bin_dir and ctx.genfiles_dir as environment variables. This is still ugly, since it includes "external", so the file needs to have the context that it is embedded as an external workspace.

Ideally, I would just want to include_str!("message.string"); or include_str!("../message.string");, but both do not currently work. Is there a better way or solution to this issue? Should my repro case become a patch?

This would look something like https://github.com/mfarrugi/rules_rust/blob/c-bind-gen/rust/cbindgen.bzl

Main issue here is that this wants cargo metadata to work under bazel, which essentially requires Cargo.toml`s to be available at build time, similar to #71 and #95.

I am not actually familiar with the tool, so I am not sure if there are additional corner cases that make this less straight forward; potentially there are issues with generating sensible Cargo.toml's that cbindgen will be happy with.

Hi all,

rightly? probably wrongly our current build configuration lets developers opt into using the sanitizers via bazelrc configurations.

One of these configurations abuses --copt to add -fsanitize=address to the cflags we compile under, as a result we get asan binaries.

I think I can make this happen with platforms / toolchains in the rust_rules, but it might be good to still think about how and if there is a way to specify flags for rustc in a more adhoc fashion.

Not urgent more a discussion point.

If I understood correctly, external crates referenced in the Cargo.toml files are still not supported, right? So there's no way at the moment to build something that depends on external crates, am I right?

In order to implement #37, we'll need to be able to handle multiple copies of a crate, as crates are entirely recompiled and linked separately when they have different feature flags.

I suggest we do what cargo does: generate a hash that can be supplied to rustc's -C metadata argument for the purpose of disambiguation.

I wrote a prototype implementation that uses the rule's path for this purpose here, that I can use to prepare a "proper" implementation here.

@davidzchen Are there any issues you foresee in using the rule's path as a unique identifier for a crate?

https://ci.bazel.build/blue/organizations/jenkins/rules_rust/detail/rules_rust/800/pipeline

suspect: 2a3f859
@davidzchen Can you take a look?

running 1 test
test test::test_can_read_data_from_runfiles ... FAILED
failures:
---- test::test_can_read_data_from_runfiles stdout ----
thread 'test::test_can_read_data_from_runfiles' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "No such file or directory" } }', src/libcore/result.rs:860:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.
failures:
test::test_can_read_data_from_runfiles
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

The rust_test does not allow users to tag a test as manual. With native bazel test rules, bazel would ignore the tests whenever someone specified the targets as ..., :all or :*.

From looking at the common attributes, tag is not a supported attribute.

Cargo passes a variety of environment variables to crates at compile time. We should pass (some of?) those variables to more easily build crates.io packages.

https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates

Add a cargo_crate repository rule for fetching Rust crates from Cargo.io.

Latest change introduced a wrapper around gcc, which is not shiped to the sandbox, see
http://ci.bazel.io/job/rules_rust/BAZEL_VERSION=HEAD,PLATFORM_NAME=ubuntu_15.10-x86_64/74/console

rustfmt is currently shipped as part of the toolchain tarballs, but not accessible for interactive nor programmatic usage without some finagling.

Some usecases I've run into:

1. rustfmt against generated code
2. enforcing rustfmt as a pre-commit / build step

For enforcement, is it possible for rules_rust to take global configuration, and do this check as an extra-build step? Would that be a reasonable thing to do?

With the fixes for bazelbuild/bazel#6015, there will be an actual dependency from toolchains back to the respective toolchain_type target. rules_rust currently does not actually define the toolchain_type, and so builds fail (see https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/480#f43a9298-b4e0-46da-980b-e6bcacdd5e5c).

Error:

ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/7a687a53d9d341692c7f46223f63d5ca/external/rust_linux_x86_64_toolchains/BUILD:2:1: no such target '@io_bazel_rules_rust//rust:toolchain': target 'toolchain' not declared in package 'rust' (did you mean 'toolchain.bzl'?) defined by /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/7a687a53d9d341692c7f46223f63d5ca/external/io_bazel_rules_rust/rust/BUILD and referenced by '@rust_linux_x86_64_toolchains//:toolchain_for_x86_64-unknown-linux-gnu'

I find myself doing this fairly often:

rust_binary(
    name = "some_thingy",
    crate_root = "some_thingy.rs",
    ...
)

Are we open to supporting this as a default value to look for?
How do others use crate_root?

This would be a straightforward change around https://github.com/bazelbuild/rules_rust/blob/master/rust/rust.bzl#L188

Breakage: http://ci.bazel.io/job/rules_rust/BAZEL_VERSION=HEAD,PLATFORM_NAME=darwin-x86_64/259/console

Reason: we now have sandbox on Mac, and the missing dependency cc_wrapper is not in the sandbox so we can't find it.

Suggested fix: add dependency //tools/defaults:crosstool to every rule that need gcc.

The for loops in examples/matrix/src/matrix.c don't compile because they require C99 mode:

$ bazel build @examples//matrix:native_matrix
INFO: Found 1 target...
ERROR: /home/jcater/.cache/bazel/_bazel_jcater/f161603a652c64478ce40dd2b7d0ce80/external/examples/matrix/BUILD:5:1: C++ compilation of rule '@examples//matrix:native_matrix' failed: Process exited with status 1 [sandboxed].
external/examples/matrix/src/matrix.c: In function 'matrix_transpose':
external/examples/matrix/src/matrix.c:73:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (size_t i = 0; i < q; ++i) {
   ^
external/examples/matrix/src/matrix.c:73:3: note: use option -std=c99 or -std=gnu99 to compile your code
external/examples/matrix/src/matrix.c: In function 'matrix_equal':
external/examples/matrix/src/matrix.c:107:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (size_t i = 0; i < len; ++i) {
   ^
Use --strategy=CppCompile=standalone to disable sandboxing for the failing actions.
Target @examples//matrix:native_matrix failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.274s, Critical Path: 0.11s

Cargo supports Features, which, according to the documentation is used for the following:

1. Specifying conditional compilation options
2. Specifying optional dependencies
3. Specifying clusters of optional dependencies, other features of the current crates, and/or enabling features in dependencies of this crate.

(1) is currently supported via the crate_features attribute, which sets flags to enable different conditional compilation features via cfg. More discussion and design work is needed in order to support (2) and (3).

Currently the stdlib and platform exts are baked into the toolchain as attrs:

... but this doesn't actually match how the Rust compiler works. Any given rust compiler can compile for any target platform provided that the right --target flag, stdlib, and linker are provided[1]. Keeping the current attrs as defaults seems fine, but we should also support retrieving the other stdlibs if an alternative --target is specified.

google/cargo-raze#54 has a little bit of discussion about the high level details of what a given target-triple should mean in terms of config_settings among other things.

[1] https://github.com/japaric/rust-cross#cross-compiling-with-rustc