Bazel 8 uses `+` as the separator for segments of canonical repo names,
whereas Bazel 7 uses `~` or `+` depending on the value of
`--incompatible_use_plus_in_repo_names`.
---------
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
This PR adds support for `wasm64-unknown-unknown` although there are no
prebuilt `wasm64-unknown-unknown` rustc toolchains. Compiling for
`wasm64` will be left up to anyone using this target triple until we get
T2 support for wasm64.
---------
Co-authored-by: Andre Brisco <andre.brisco@freeform.co>
We store in the lockfile the path of this source file relative to the
package, and if we use an absolute path we end up encoding the depth of
your local git clone into the lockfile, which is non-determinstic across
machines.
Elsewhere we use fake.rs, let's use it here as well.
Updating shas was taking much longer than it used to. I've refactored
the shell script into python so to manage increased complexity. The
script now fetches the `channel-rust-*.toml` files which contains
additional sha256 values. This script still falls back to brute force
fetching of artifacts to account for any that are missing. The runtime
was reduced from ~20 min to ~80s.
```bash
python3.11 ./util/fetch_shas/fetch_shas.py
```
```
2024-09-06 08:57:22 - INFO - Fetching known sha256 data...
2024-09-06 08:57:22 - INFO - Downloading data...
2024-09-06 08:57:29 - INFO - Done.
2024-09-06 08:57:29 - INFO - Deserializing 119 tomls...
2024-09-06 08:57:36 - INFO - Done.
2024-09-06 08:57:36 - INFO - Parsing artifacts...
2024-09-06 08:57:36 - INFO - Done. Identified 52790 artifacts.
2024-09-06 08:57:36 - INFO - Checking for 81514 missing artifacts...
2024-09-06 08:58:26 - INFO - Done.
2024-09-06 08:58:29 - INFO - Downloading 404 missing artifacts...
2024-09-06 08:58:29 - INFO - Done.
2024-09-06 08:58:36 - INFO - Done. Wrote rust/known_shas.bzl
```
Note that `beta` sha256 values have been removed in this change.
This introduces the flag
`--@rules_rust//rust/settings:experimental_use_sh_toolchain_for_bootstrap_process_wrapper`
which can be used to embed the shell path from
`@bazel_tools//tools/sh:toolchain_type` in the rustc bootstrap process
wrapper.
Before this, if we re-generate all of the BUILD.bazel files for our
vendored deps, they are invalid because they only have BUILD.bazel files
and the globs present in them expect srcs.
First two commits are real changes, third commit is just a repin.
Doing my best to adhere to https://bazel.build/concepts/labels. This
change updates the label utility to account for modern changes to Bazel
labels (e.g. from bzlmod).
It seems that vendored crates commonly get out of sync. Re-vendoring
seems to currently be a quite manual process, and finding everything to
re-vendor is a hassle.
This adds a bash script, `vendor.sh`, that finds all crate vendor rules
in all workspaces in this repository and runs them. This significantly
improves the workflow for updating these.
This also adds `.bazelrc` files to disable bzlmod to non-bzlmod
workspaces, since otherwise bazel 7 create a MODULE.bazel and
MODULE.bazel.lock when re-vendoring.
This also re-vendors all crates (in a separate commit).
Without much insight into core Bazel's plans for supporting "flagless"
builds across platforms, this seems like the most direct way to select
the platform for a given Rust binary target (all the terminal rules)
that doesn't need additional work to forward providers.
Currently I'm using `platform_transition_binary`
(https://github.com/aspect-build/bazel-lib/blob/main/docs/transitions.md),
but it doesn't work with Rust Analyzer/Clippy/etc. presumably due to not
forwarding the providers. In the case of this particular rule, it also
doesn't work for something like `rust_shared_library()` which is
explicitly not an `executable = True` target.
@illicitonion brought to my attention `with_cfg`
(https://github.com/fmeum/with_cfg.bzl) which could be used as an
alternative by consumers of `rules_rust` instead of this PR. That feels
reasonable, though certainly more work for individual users and appears
to rely on a lot of Bazel black magic.
Along the same lines, this could wait on rule inheritance as presumably
a more formally supported `with_cfg` approach, which would also be up to
individual users and not `rules_rust`.
Seeing as #2279 is merged, this fixes the current Nix built
`cargo-bazel` getting stale because it's not able to watch the source
files. This should make for much better iteration speed as well, as the
Nix built form has to do a clean build every time.
See #2246 for how we declare dependencies automatically for third party
crates. I'm using the same mechanism for all other repositories.
Note that the MODULE.bazel changes in use_repo are autogenerated, and if
you change the third party crates you depend on, you should get an error
message saying something like "run this command to fix it" on your
bzlmod presubmit environment.
@googleson78 originally wrote
https://github.com/bazelbuild/rules_rust/pull/1657 in order to solve
this problem. As discussed in that PR, they're no longer working on
this, so I offered to pick this up. This is the same PR as that one, but
has some bugfixes and refactoring applied.
---------
Co-authored-by: Georgi Lyubenov <georgi.lyubenov@tweag.io>
Co-authored-by: UebelAndre <github@uebelandre.com>
Currently, when you run `bazel build --enable_bzlmod
//crate_universe:bin`, you get the error `undefined repo @cui`.
When you add a dependency on CUI, you get errors like `undefined repo
@cui__<crate>-<version>` (the repo for the third party crate).
This change will allow us to automatically declare dependencies on our
third party crates from bzlmod (see
https://docs.google.com/document/d/1dj8SN5L6nwhNOufNqjBhYkk5f-BJI_FPYWKxlB3GAmA/edit#heading=h.5mcn15i0e1ch).
---------
Co-authored-by: UebelAndre <github@uebelandre.com>
This change aims to ensure the process wrapper is built
determinisitically, thus reducing churn in cases where multiple
developers share a bazel remote cache. The shared cache is notable as
the binaries can be deterministically produced for a single user for a
single checkout as some host information is embedded in the compiled
binaries. The host information is stored in the `debug-info` section of
the executable. This can be resolved by stripping it. The other issue of
determinism is `rust_binary_without_process_wrapper` does not resolve
`${pwd}` like the process wrapper does, thus stripping sandbox paths
from rustc outputs. To solve for this a small bash and batch script was
added to account for this behavior. The intent of these scripts is to
use __no__ host executables and instead rely on pure bash and batch to
accomplish this and keep any actions which use this as hermetic as
possible.
The following tables were produced on macOS. Note that `rules_rust_2` is
simply another checkout of `rules_rust` on the same commit
Before the changes in this PR:
| path | rules_rust sha256 | rules_rust_2 sha256 |
| --- | --- | --- |
|
bazel-out/darwin_arm64-opt-exec-2B5CBBC6/bin/external/rules_rust_tinyjson/libtinyjson-4031717389.rlib
| 60db194b3e98b67cc0702c6b6c48c5bc8fcf7d723f3ece6a7a24a53888158c7e |
3eac0b443ba160e3a1bde3b023f4e953bb9fc9722e430b5ded6dbb723bc2b532 |
|
bazel-out/darwin_arm64-opt-exec-2B5CBBC6/bin/util/process_wrapper/process_wrapper
| 32e7840602c977b76bba0bc39da768d35db3e7a17dbf96e455727be2b2f0151f |
0d248279bbc9b17be5914b41a66759f939ef4da77f8a40a5ce6fa3bf339648ad |
After the changes:
| path | rules_rust sha256 | rules_rust_2 sha256 |
| --- | --- | --- |
|
bazel-out/darwin_arm64-opt-exec-2B5CBBC6/bin/external/rules_rust_tinyjson/libtinyjson-4031717389.rlib
| 07432f5d207da854266ccde212243c67c29907f81a7619434ce9f608b1658d96 |
07432f5d207da854266ccde212243c67c29907f81a7619434ce9f608b1658d96 |
|
bazel-out/darwin_arm64-opt-exec-2B5CBBC6/bin/util/process_wrapper/process_wrapper
| cbf17392338aabfc942d975f95a49a67b731c5e597a7d27e3d9cf4d4a06b8f2c |
cbf17392338aabfc942d975f95a49a67b731c5e597a7d27e3d9cf4d4a06b8f2c |
closes https://github.com/bazelbuild/rules_rust/issues/2092
While running from CARGO_MANIFEST_DIR is the simplest thing for
compatibility, there are cases where a cargo build script may be easier
to run from the exec root as most bazel actions do (e.g. where a C++
toolchain specifies in-repo include paths).
This mirrors the `rundir` attribute of `go_test`, which has similar
concerns:
https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/rules.md#go_test-rundir
This change introduces `experimental_use_coverage_metadata_files`
(https://github.com/bazelbuild/rules_rust/issues/2082) which is required
to support
[--experimental_split_coverage_postprocessing](https://bazel.build/reference/command-line-reference#flag--experimental_split_coverage_postprocessing)'
Changes:
- Implemented coverage collection logic in Rust.
- Added a flag
`--@rules_rust//rust/settings:experimental_use_coverage_metadata_files`
to toggle the changes necessary for supporting
`--experimental_split_coverage_postprocessing`.
- Added regression testing in CI to test
`--experimental_split_coverage_postprocessing`.
* Exclude .tmp_git_root from globs
This directory contains the original git repo when the crate is from git. Including this directory currently makes these rules re-run whenever the repository rule re-runs, although this is fixed by https://github.com/bazelbuild/bazel/pull/18271. Even after this fix, excluding this directory avoids depending on unnecessary files.
Fixes #1927.
* Regenerate vendored crates
UebelAndre