[vyncint]

Closes #1192.

Both cargo oxide new templates emitted use statements in an order rustfmt does not produce, so a freshly scaffolded project failed its own format check on code the user never wrote. CONTRIBUTING points contributors at cargo oxide fmt, so this is the first thing a new project is told to run.

Before / after

Before — sync template, straight after cargo oxide new demo:

$ cargo oxide fmt --check
Diff in src/main.rs:1:
-use cuda_device::{kernel, launch_bounds, launch_contract, thread, DisjointSlice};
-use cuda_host::cuda_module;
 use cuda_core::{CudaContext, DeviceBuffer, LaunchConfig1D};
+use cuda_device::{DisjointSlice, kernel, launch_bounds, launch_contract, thread};
+use cuda_host::cuda_module;

❌ Some files need formatting. Run: cargo oxide fmt

Before — --async, wrong in two places rather than one:

Diff in src/main.rs:1:
-use cuda_device::{kernel, thread, DisjointSlice};
-use cuda_host::cuda_module;
 use cuda_async::device_context::init_device_contexts;
 use cuda_async::device_operation::DeviceOperation;
 use cuda_core::LaunchConfig;
Diff in src/main.rs:6:
+use cuda_device::{DisjointSlice, kernel, thread};
+use cuda_host::cuda_module;

After — both templates:

$ cargo oxide new dsync           && (cd dsync  && cargo fmt --check) && echo CLEAN
CLEAN
$ cargo oxide new dasync --async  && (cd dasync && cargo fmt --check) && echo CLEAN
CLEAN

Two independent orderings were wrong

1. Crate order — cuda_device / cuda_host preceded cuda_core, and in the async template also cuda_async.
2. Order inside the braces — DisjointSlice trailed the lowercase items; under the scaffold's edition = "2024" it sorts first.

Why nothing caught it

The templates are string constants, so the repository's own fmt job formats the file that holds them and never their contents, and no gate runs cargo oxide new.

The existing test also pinned the defect in place:

assert!(files.main_rs.starts_with(
    "use cuda_device::{kernel, launch_bounds, launch_contract, thread, DisjointSlice};"
));

It now asserts the canonical line and leaves ordering to the new test.

The test runs real rustfmt

scaffold_templates_are_rustfmt_clean renders each template and runs the real rustfmt over it, taking the edition back out of the scaffolded Cargo.toml so the check cannot drift from the manifest it describes.

I deliberately did not re-derive rustfmt's import ordering in the test: such a check agrees with a stale template exactly as readily as with a correct one, and sees nothing outside the import block. release_depfile_path_matches_real_cargo_uplift_for_hyphenated_bin shells out to real cargo for the same reason, so this follows that precedent. If rustfmt is absent the test fails loudly rather than passing quietly; it is in rust-toolchain.toml's component list.

Mutations (each applied to the fixed tree, each caught)

mutation	result
sync template reverted to the old import order	caught
async template reverted to the old import order	caught
non-import drift — one line of the sync body re-indented	caught
trailing whitespace after a sync import	caught
control: unmodified fixed tree	passes

The third and fourth matter: they are drift a hand-written ordering check would sail past.

The book moves with it

getting-started/hello-gpu.md presents the async listing as "the generated async vecadd template". #548 exists precisely to keep it in step with scaffold_main_rs(true), and nothing automated holds them together, so leaving it would have silently re-opened that issue. Parity is verified by checking the scaffold's rendered import block appears verbatim in the page.

The book's other use cuda_device::{...} blocks are hand-written examples rather than scaffold output, so they are out of scope here — book code blocks are not formatted by anything today, which is a separate gap I am happy to file if wanted.

Scope

• No device code, so there is no GPU evidence to attach; import order cannot change semantics, and rustfmt parsing both templates establishes they are still syntactically valid.
• Independent of cargo oxide fmt builds the whole codegen backend before formatting anything #1187/cargo-oxide: fmt must not build the codegen backend #1188, which concern fmt building the backend rather than what the scaffold emits.

Test plan

• cargo test -p cargo-oxide — 186 passed, 0 failed (185 + the new test).
• cargo clippy -p cargo-oxide --all-targets -- -D warnings — clean.
• cargo fmt --check — clean.
• RUSTDOCFLAGS="-D warnings" cargo doc --no-deps -p cargo-oxide — clean.
• sphinx-build -W --keep-going -b html cuda-oxide-book — build succeeded.
• Guard scripts (check-book-api-names, check-cli-doc-coverage, check-crate-inventory, check-spdx-headers, check-toolchain-parity, check-test-matrix-coverage, check-error-example-status, check-example-license-policy, check-reserved-prefixes, check-book-catalog-stamp) — all pass.
• End to end: scaffolded both templates with the built binary and confirmed cargo fmt --check is clean in each.

[nihalpasham]

Reviewed and validated; nothing to change, this is ready as-is. The root-cause read is right (the templates are string constants, so the repo's own fmt gate formats the file holding the strings and never the text inside them, and the old test asserted the stale line), and the fix follows what cargo new itself does: ship canonical text, enforce it with a test that runs the real formatter.

Validated on today's main + the new nightly pin (your branch predates the toolchain bump, so this was the open question):

• merge onto main: clean; cargo test -p cargo-oxide 190 passed incl. the new scaffold_templates_are_rustfmt_clean; clippy -D warnings + fmt clean
• end to end: scaffolded both flavors with the built binary, ran rustfmt 1.10.0-nightly (edition read from the generated manifest) over the output:

$ cargo oxide new demo && cd demo && cargo oxide fmt --check
before: Diff in src/main.rs:1  (a project the user didn't write a line of)
after:  clean, exit 0          (same for --async)

• book parity: the block captioned as the generated async template matches the rendered template through the whole import block and main() signature; the tail's teaching comments are the pre-existing "minor formatting edits" the caption already discloses, so we left that alone

The test shelling out to the real rustfmt instead of re-deriving its rules is the part that keeps this fixed: next nightly that changes canonical form fails the test instead of the user's first fmt --check. CI approval + landing next. If you want to file the issue for the hand-written book blocks that still use the old import order, that's a fine follow-up.