You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to preface this by saying that the underlying issue isn't a rules_rust issue, but rather a bazel issue: bazelbuild/bazel#21474
If I have a setup with the following conditions:
A rust target which is unsandboxed (e.g. a test with tags = ["no-sandbox"])
--@rules_rust//:rustc_output_diagnostics=true is set
--incompatible_allow_tags_propagation is enabled (default in bazel 7.x)
...and then I run the clippy aspect, I get spurious failures. I am currently seeing this in our internal CI and my temporary solution is to disable clippy for any unsandboxed tests.
Thanks to the above-linked issue, in bazel 7.x, the action in the clippy aspect runs unsandboxed if the underlying target is unsandboxed. This in itself is not a problem, but it's not great. When combined with rustc_output_diagnostics (used for editor integration), the clippy aspect tries to write an output file (in this case bazel-out/k8-fastbuild/bin/test-383275658/some_test.rustc-output) which is also produced by the rustc compile action. That file is not a declared output of the action, so when sandboxing is enabled it doesn't cause any issues. But when sandboxing is disabled, if the file already exists (because the compile action already ran), writing the file will fail since bazel outputs have the write permission disabled.
I was able to work around this locally with the following patch to rules_rust:
diff --git a/rust/private/clippy.bzl b/rust/private/clippy.bzl
index 9fd9842c..6f5346f8 100644
--- a/rust/private/clippy.bzl+++ b/rust/private/clippy.bzl@@ -127,6 +127,7 @@ def _clippy_aspect_impl(target, ctx):
build_flags_files = build_flags_files,
emit = ["dep-info", "metadata"],
skip_expanding_rustc_env = True,
+ no_rustc_output = True,
)
if crate_info.is_test:
diff --git a/rust/private/rustc.bzl b/rust/private/rustc.bzl
index eff542eb..e26c562e 100644
--- a/rust/private/rustc.bzl+++ b/rust/private/rustc.bzl@@ -804,7 +804,8 @@ def construct_arguments(
use_json_output = False,
build_metadata = False,
force_depend_on_objects = False,
- skip_expanding_rustc_env = False):+ skip_expanding_rustc_env = False,+ no_rustc_output = False):
"""Builds an Args object containing common rustc flags
Args:
@@ -945,9 +946,9 @@ def construct_arguments(
if build_metadata:
# Configure process_wrapper to terminate rustc when metadata are emitted
process_wrapper_flags.add("--rustc-quit-on-rmeta", "true")
- if crate_info.rustc_rmeta_output:+ if crate_info.rustc_rmeta_output and not no_rustc_output:
process_wrapper_flags.add("--output-file", crate_info.rustc_rmeta_output.path)
- elif crate_info.rustc_output:+ elif crate_info.rustc_output and not no_rustc_output:
process_wrapper_flags.add("--output-file", crate_info.rustc_output.path)
rustc_flags.add(error_format, format = "--error-format=%s")
But this doesn't seem like a particularly clean solution. I'm not sufficiently familiar with the code to know what a cleaner solution would look like. I understand that rustc_output_diagnostics is a pretty niche and unsupported feature at the moment, and I'm happy to keep using a workaround internally, but I figured I should share in case others run into the same issue.
The text was updated successfully, but these errors were encountered:
I want to preface this by saying that the underlying issue isn't a rules_rust issue, but rather a bazel issue: bazelbuild/bazel#21474
If I have a setup with the following conditions:
tags = ["no-sandbox"]
)--@rules_rust//:rustc_output_diagnostics=true
is set--incompatible_allow_tags_propagation
is enabled (default in bazel 7.x)...and then I run the clippy aspect, I get spurious failures. I am currently seeing this in our internal CI and my temporary solution is to disable clippy for any unsandboxed tests.
Here's a gist with this setup: https://gist.github.com/william-smith-skydio/f7821eb732c539f878fdfb00986230db
If I build the test first, and then build the clippy target, I get a failure:
Error (with
--verbose_failures
):Thanks to the above-linked issue, in bazel 7.x, the action in the clippy aspect runs unsandboxed if the underlying target is unsandboxed. This in itself is not a problem, but it's not great. When combined with
rustc_output_diagnostics
(used for editor integration), the clippy aspect tries to write an output file (in this casebazel-out/k8-fastbuild/bin/test-383275658/some_test.rustc-output
) which is also produced by the rustc compile action. That file is not a declared output of the action, so when sandboxing is enabled it doesn't cause any issues. But when sandboxing is disabled, if the file already exists (because the compile action already ran), writing the file will fail since bazel outputs have the write permission disabled.I was able to work around this locally with the following patch to rules_rust:
But this doesn't seem like a particularly clean solution. I'm not sufficiently familiar with the code to know what a cleaner solution would look like. I understand that
rustc_output_diagnostics
is a pretty niche and unsupported feature at the moment, and I'm happy to keep using a workaround internally, but I figured I should share in case others run into the same issue.The text was updated successfully, but these errors were encountered: