Add stdarch-gen-common: shared check/bless harness for generators by xonx4l · Pull Request #2157 · rust-lang/stdarch

xonx4l · 2026-06-09T18:10:57Z

This PR adds a library crate stdarch-gen-common that gives every generator three modes -:

Write - Generator writes files straight into the committed location.
Check - Generator write into a temporary directory . The crate diffs it against committed and fails on any mismatch without touching the working copy .
Bless - Generator writes into a temp directory the crate then mirrors temp over committed. Adding, overwriting, and deleting files as needed.

Mode is picked via the STDARCH_GEN_MODE env var. The harness only touches files the generator explicitly lists as its own so hand-written files in the same directory are safe.

This PR also hooks stdarch-gen-hexagon to use it as the first example.

r? @folkertdev

Kobzol · 2026-06-09T19:05:16Z

For a bit more context, this is done for the stdarch GSoC project, where we try to integrate stdarch's tests in rust-lang/rust's CI. We want to move the blessing logic out of the CI YAML files and into Rust, to make it easier to reuse, and also share code amongst the various generators.

I'll take a look, but also CC @folkertdev , in case you have in mind who owns this code amongst the stdarch maintainers and who could also chime in.

Kobzol

Thanks for creating the crate! I left a few comments.

View changes since this review

Kobzol · 2026-06-10T18:53:09Z

+use std::path::{Path, PathBuf};
+
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum Mode {


How does Write differ from Bless? I'd expect those two modes to be the same. Could you please add some doc comments on the mode to explain what the individual modes mean? Thanks!

Added doc comments .The two modes hit different code paths in run write skips the owned-list filter entirely.

These comments use a lot of terms and I'm not sure what do they mean 😆

What is target directory? How does "committed tree" differ from "owned list"?

Haha I used those in order to differentiate better and more readable but I think rewording made them confusing . Here target directory and committed tree mean the same thing the folder the generator writes into to make it less confusing I will simplify it naming to just committed and owned list means the list of file names inside that folder that this generator is responsible for .

Kobzol · 2026-06-10T18:53:37Z

+}
+
+impl Mode {
+    pub fn from_env() -> Self {


Please add a doc comment here that explains how to use the function, i.e. which env var it expects to read and what are the possible values.

Kobzol · 2026-06-10T18:54:05Z

+
+// owned is the list of relative paths the generator manages. Files in
+// committed not listed here are left untouched by Bless and ignored by Check.
+pub fn run<F, E>(committed: &Path, owned: &[&str], mode: Mode, generate: F) -> Result<()>


Could you please add a doc comment that explains in more detail what the function is supposed to be doing? The signature is kinda complex.

I think that we can simplify the function by changing it to only work with a single subdirectory, it doesn't really need to handle slices and multiple paths at once.

Added doc comment explaining the signature . I kept the slice instead of switching to one folder per generator because generated files are aligned next to hand-written ones in the same folder . if we owned the whole folder bless would delete those hand-written files. Thank you!

I don't understand, you can still just take the for loop that is now executed inside run, and perform it outside the function, by just passing it a since owned string, right?

Yes makes sense , the the loop can move out.

Kobzol · 2026-06-10T18:55:15Z

+                    write!(f, "{}: committed but no longer generated", path.display())
+                }
+                MismatchKind::ContentsDiffer => write!(f, "{}: contents differ", path.display()),
+                MismatchKind::MissingFromGenerated => write!(


When we bless, it can happen that the new blessed output has less files than before, right? 🤔

Yes there's a case for it already MissingFromGenerated. Added the comment that explains . Thank you!

What I meant was that MissingFromGenerated shouldn't happen, if something is not present in the generated output, we should delete it from the committed tree.

Ok will drop.

Kobzol

I think I'll have to examine how the generator behaves a bit deeper (I'll try to do that on Monday), because I'm still quite surprised from the behavior here 😅 I think that we might wanna do some targeted changes to the generator and the directory layout to make blessing simpler, if the complexity here is caused by the current directory layout.

View changes since this review

Kobzol · 2026-06-12T07:17:19Z

+use std::path::{Path, PathBuf};
+
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum Mode {


These comments use a lot of terms and I'm not sure what do they mean 😆

What is target directory? How does "committed tree" differ from "owned list"?

Kobzol · 2026-06-12T07:17:58Z

+                    write!(f, "{}: committed but no longer generated", path.display())
+                }
+                MismatchKind::ContentsDiffer => write!(f, "{}: contents differ", path.display()),
+                MismatchKind::MissingFromGenerated => write!(


What I meant was that MissingFromGenerated shouldn't happen, if something is not present in the generated output, we should delete it from the committed tree.

xonx4l · 2026-06-12T10:42:27Z

I think I'll have to examine how the generator behaves a bit deeper (I'll try to do that on Monday), because I'm still quite surprised from the behavior here 😅 I think that we might wanna do some targeted changes to the generator and the directory layout to make blessing simpler, if the complexity here is caused by the current directory layout.

View changes since this review

Yes targeted changes to the generator will likely make this crate much simpler. Btw we are in a fixing loop :)

folkertdev

Overall this seems fine as a design. I'd probably just do the other generators in a separate PR using this as a foundation.

View changes since this review

folkertdev · 2026-06-13T18:08:47Z

+        match std::env::var("STDARCH_GEN_MODE").as_deref() {
+            Ok("check") => Mode::Check,
+            Ok("bless") => Mode::Bless,
+            _ => Mode::Write,


I'd rather panic on an unknown value? Unless this is standard practice somehow?

folkertdev · 2026-06-13T18:11:13Z

+/// - [`Mode::Bless`]:  runs the generator into a temp dir and copies `owned`
+///   into `committed`, or removes `committed`'s copy if the generator no
+///   longer produces it.
+pub fn run<F, E>(committed: &Path, owned: &str, mode: Mode, generate: F) -> Result<()>


Suggested change

pub fn run<F, E>(committed: &Path, owned: &str, mode: Mode, generate: F) -> Result<()>

pub fn run_generator<F, E>(committed: &Path, owned: &str, mode: Mode, generate: F) -> Result<()>

maybe? run itself is quite vague at the use site.

Add stdarch-gen-common

9d9978a

rustbot assigned Kobzol Jun 9, 2026

rustbot assigned folkertdev and unassigned Kobzol Jun 9, 2026

Kobzol reviewed Jun 10, 2026

View reviewed changes

add: doc comments

9aca67e

Kobzol reviewed Jun 12, 2026

View reviewed changes

update review changes and fixes

f106944

folkertdev reviewed Jun 13, 2026

View reviewed changes

	pub fn run<F, E>(committed: &Path, owned: &str, mode: Mode, generate: F) -> Result<()>
	pub fn run_generator<F, E>(committed: &Path, owned: &str, mode: Mode, generate: F) -> Result<()>

Conversation

xonx4l commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kobzol commented Jun 9, 2026

Uh oh!

Kobzol left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kobzol left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xonx4l commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

folkertdev left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

xonx4l commented Jun 9, 2026 •

edited

Loading

Kobzol left a comment •

edited by rustbot

Loading

Kobzol left a comment •

edited by rustbot

Loading

xonx4l commented Jun 12, 2026 •

edited

Loading

folkertdev left a comment •

edited by rustbot

Loading