This implements the repo_mapping capabilities and provides a new
runfiles API. The new API can be accessed explicitly as
`runfiles::Runfiles::rlocation_from` or with the `runfiles::rlocation!`
macro, which adds compile-time support for correctly embedding the
external repo. This is a purely new API, existing usage continues to
work, although we mark it deprecated because it's not fully correct. We
can remove it at some point in the future.
This PR also transitions in-repo examples/tests to using it, in case
anyone copies them.
---------
Co-authored-by: scentini <rosica@google.com>
- Create `bzlmod/hello_world` package based upon
`examples/bzlmod/hello_world`.
- Add `rules_bazel_integration_test` so that `//bzlmod:hello_world_test`
can be executed as a test from the parent workspace.
- Add `filegroup` targets named `all_files` to collect files for all of
the packages that are necessary to use `rules_rust`. These are an input
to the `rules_bazel_integration_test` test.
- Replace `.bcr/presubmit.yml` to test `//bzlmod:hello_world_test`.
- Update CI to test `//bzlmod:hello_world_test`.
Related to
https://github.com/bazelbuild/bazel-central-registry/pull/1199#discussion_r1429129814.
Initial support for `no_std` mode.
This allows us to
1. Don't pass the whole standard library to compile actions that specify `no_std`
2. Conditionally select `crate_features` and `deps` based on whether `no_std` mode is used.
Currently the only supported modes are `off` and `alloc`, with a possibility to expand in the future.
The `no_std` support comes with the following caveats:
1. Targets in `exec` mode are still built with `std`; the logic here being that if a device has enough space to run bazel and rustc, std's presence would not be a problem. This also saves some additional transitions on `proc_macro`s (they need `std`), as they are built in `exec` mode.
2. Tests are still built with `std`, as `libtest` depends on `libstd`
There is quite an ugly hack to make us be able to `select` on the `no_std` flavor taking `exec` into account; I'm looking forward to the day where Bazel will expose better ways to inspect the cfg.
There is also one part I didn't manage to make work - having a `rust_test` that tests the `rust_shared_library` in `cc_common.link` mode; I got a link error for missing `__rg_alloc` & co. symbols, which should be present as we pass `--@rules_rust//rust/settings:experimental_use_global_allocator=True`. Unfortunately I could only spot this error on CI, and could not reproduce locally. I removed the test because the `rust_shared_library` is already tested via a `cc_test`. I will however give another shot at inspecting how my local setup differs from CI.
The `rust_binary` source code in `main.rs` was borrowed from https://github.com/jfarrell468/no_std_examples, big thanks to @jfarrell468 for letting me use it.
Co-authored-by: Krasimir Georgiev <krasimir@google.com>
Co-authored-by: UebelAndre <github@uebelandre.com>
* Added bootstrap script for crate_universe and github action for auto-releasing new binaries
* Addressed PR feedback
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
* Updated local dev documentation
* Add announce_rc to crate_universe.bazelrc
* Addressed buildifier defect
* Addressed additional user feedback
* Apply suggestions from code review
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
* Fixed missing extension for windows.
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
This rule dynamically looks up crate dependencies as a repository rule.
See https://github.com/bazelbuild/rules_rust/issues/2 for context.
Note that this rule is currently experimental, and offers absolutely no stability guarantees. Expect significant churn in near future.
This pull request contains various cleanup/quality-of-life improvements for the repository by clearly grouping and defining dependencies for the docs and examples workspaces. Ultimately, the files that are created in here can be moved entirely into their neighboring WORKSPACE files once bazelbuild/bazel#1943 has been closed.
Peter Kolloch