Skip to content

miri: integrate Bazel Miri tests in communication #370

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dcalavrezo-qorix wants to merge 3 commits into
base: main
Choose a base branch
from
Open

miri: integrate Bazel Miri tests in communication #370

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4346d01
miri: integrate Bazel Miri tests in communication
dcalavrezo-qorix Apr 28, 2026
817b23a
Merge branch 'main' into dcalavrezo_miri
dcalavrezo-qorix Apr 28, 2026
3eaed87
miri: code review
dcalavrezo-qorix Apr 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .bazelrc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,7 @@ common --@score_baselibs//score/memory/shared/flags:use_typedshmd=False
common --//score/mw/com/flags:tracing_library=@score_baselibs//score/analysis/tracing/generic_trace_library/stub_implementation
common --extra_toolchains=@gcc_toolchain_x86_64//:cc_toolchain
common --extra_toolchains=@score_toolchains_rust//toolchains/ferrocene:ferrocene_x86_64_unknown_linux_gnu
common --extra_toolchains=@score_toolchains_rust//toolchains/ferrocene:ferrocene_x86_64_unknown_linux_gnu_miri
build --incompatible_strict_action_env
test --test_output=errors
build --experimental_retain_test_configuration_across_testonly #https://github.com/bazelbuild/bazel/issues/6842
Expand Down
5 changes: 5 additions & 0 deletions .github/workflows/build_and_test_host.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -111,6 +111,11 @@ jobs:
- name: Bazel test communication targets
run: |
bazel test ${{ matrix.config }} //... --build_tests_only

- name: Bazel Miri tests
if: ${{ matrix.identifier == "" }}
run: |
bazel test //:miri_tests --test_output=errors
- name: Bazel test integration as module
run: |
# for the beginning, we do this only with the default configuration
Expand Down
12 changes: 12 additions & 0 deletions BUILD
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,3 +56,15 @@ format_test(
starlark = "@buildifier_prebuilt//:buildifier",
workspace = "//:LICENSE",
)

# Miri test suite
# Keep the CI suite to targets that run cleanly under Miri today.
test_suite(
name = "miri_tests",
testonly = True,
tests = [
"//score/mw/com/impl/rust/com-api/com-api-concept:com-api-concept-macros-unit-tests_miri",
"//score/mw/com/impl/rust/com-api/com-api-concept:com-api-concept-test_miri",
"//score/mw/com/impl/rust/com-api/com-api-runtime-lola:com-api-runtime-lola-tests_miri",
],
)
4 changes: 2 additions & 2 deletions MODULE.bazel
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ bazel_dep(name = "nlohmann_json", version = "3.11.3")
bazel_dep(name = "platforms", version = "1.0.0")
bazel_dep(name = "rules_cc", version = "0.1.5")
bazel_dep(name = "rules_python", version = "1.5.1")
bazel_dep(name = "rules_rust", version = "0.68.1-score")
bazel_dep(name = "rules_rust", version = "0.68.2-score")
bazel_dep(name = "score_baselibs", version = "0.2.6")
bazel_dep(name = "score_baselibs_rust", version = "0.1.0")
bazel_dep(name = "score_bazel_platforms", version = "0.1.2")
Expand Down Expand Up @@ -160,7 +160,7 @@ llvm.toolchain(
)
use_repo(llvm, "llvm_toolchain")

bazel_dep(name = "score_toolchains_rust", version = "0.8.0", dev_dependency = True)
bazel_dep(name = "score_toolchains_rust", version = "0.9.1", dev_dependency = True)

gcc_ferrocene = use_extension(
"@score_toolchains_rust//extensions:ferrocene_toolchain_ext.bzl",
Expand Down
20 changes: 18 additions & 2 deletions score/mw/com/impl/rust/com-api/com-api-concept/BUILD
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************

load("@rules_rust//rust:defs.bzl", "rust_doc_test", "rust_library", "rust_test")
load("@rules_rust//rust:defs.bzl", "miri_test", "rust_doc_test", "rust_library", "rust_test")
Copy link
Copy Markdown
Contributor

@castler castler Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First, thanks for the efforts - but I think we need to be here very, very careful.

I understand to a minor extend, that we have a fork of rules_rust within S-CORE for QNX related patches. Anyhow, these patches should be integrated back into offical rules_rust. We really do not want to have a fork of rules_rust - and then even under the same name!
So features like this, should be really merged into the offical rules_rust and not into a mirror for patches!
We do not want to split the contributing community around rules_rust.

Second, while I highly appreciate the effort put into enabling miri - and I also think it is a must - I doubt the technical solution. From history, we have integrated pylint the very same way as it was done in this PR and we have seen quite quickly that it is impractical.
At the end we want to execute miri for all Rust related code and tests within the project.
Enforcing copy and paste around by re-adding this new rule everywhere will be hard to maintain.

IMHO we need to go the similar way, as we go with C++ Sanitizers. This must be an build option, and then all tests are executed under this toolchain. Best would be, if we would even use the same build option as the one from C++... --config=ubsan

I have limited knowledge about ´miri´ and how it operates, so I am not sure if we would need another rule, or this can be injected at compile time. But if we would really need another rule, I would propose to look into aspects to avoid the manual creation of these rules.

Copy link
Copy Markdown
Author

@dcalavrezo-qorix dcalavrezo-qorix Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback.

In parallel, we should absolutely try to upstream the Miri integration into official rules_rust. I agree that this is the right long-term direction. Realistically, though, I expect this to take quite some time — likely many months, possibly around a year — because proper Miri support requires non-trivial changes.

That said, I think we need to be careful with the assumption that Miri can be enabled in the same way as C++ sanitizers via a global build option such as --config=ubsan.

Miri is not just another compiler flag or sanitizer. It is a separate interpreter/executor for Rust programs. It also has important limitations, especially around FFI. Because of that, we cannot simply run it over the whole code base and all tests in the same way we run sanitizer-enabled C++ tests.

This is also why the current implementation wraps existing rust_test and rust_binary targets instead of trying to inject Miri globally at compile time.

Another important point: the official Miri documentation states that invoking the Miri driver directly is not a supported interface. Making this work in Bazel, while decoupling it from Cargo/cargo-miri and keeping it hermetic and reproducible, required quite some effort.

There have also been several attempts in the rules_rust community to integrate Miri support, but they were abandoned. So while I fully agree that upstream support is the ideal end state, I do not think we should block practical usage in S-CORE on that.

Also, nobody is forced to integrate Miri targets everywhere immediately ( communication included - you can just drop this PR). We can introduce them where they make sense and expand usage gradually, especially for Rust code that is suitable for Miri and does not depend on unsupported FFI behavior.


rust_library(
name = "com-api-concept",
Expand Down Expand Up @@ -39,7 +39,10 @@ rust_test(
name = "com-api-concept-test",
crate = ":com-api-concept",
tags = ["manual"],
deps = [":com-api-concept"],
deps = [
":com-api-concept",
"//score/mw/com/impl/rust/com-api/com-api",
],
)

rust_doc_test(
Expand All @@ -60,3 +63,16 @@ rust_test(
features = ["link_std_cpp_lib"],
deps = ["//score/mw/com/impl/rust/com-api/com-api"],
)
miri_test(
name = "com-api-concept-test_miri",
crate = ":com-api-concept-test",
tags = ["manual"],
visibility = ["//:__pkg__"],
)

miri_test(
name = "com-api-concept-macros-unit-tests_miri",
crate = ":com-api-concept-macros-unit-tests",
tags = ["manual"],
visibility = ["//:__pkg__"],
)
8 changes: 7 additions & 1 deletion score/mw/com/impl/rust/com-api/com-api-runtime-lola/BUILD
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************

load("@rules_rust//rust:defs.bzl", "rust_doc_test", "rust_library", "rust_test")
load("@rules_rust//rust:defs.bzl", "miri_test", "rust_doc_test", "rust_library", "rust_test")

rust_library(
name = "com-api-runtime-lola",
Expand Down Expand Up @@ -46,3 +46,9 @@ rust_doc_test(
crate = ":com-api-runtime-lola",
deps = [":com-api-runtime-lola"],
)
miri_test(
name = "com-api-runtime-lola-tests_miri",
crate = ":com-api-runtime-lola-tests",
tags = ["manual"],
visibility = ["//:__pkg__"],
)
Loading