Repository navigation
Book Rust blocks still use the pre-#1193 import order, so copying one fails cargo oxide fmt --check #1240
Description
Filing the follow-up invited in the #1193 review.
#1193 made cargo oxide new emit rustfmt-clean projects, because a scaffolded project failing its own first cargo oxide fmt --check is a bad first five minutes. The book's hand-written Rust blocks were out of scope there and still carry the old import order, so a reader who copies one into a project gets the same diff on the same command.
Measured
Over every tracked cuda-oxide-book/**/*.md, taking each ```rust block that contains a cuda_* import and running the pinned rustfmt on it at the book's edition:
blocks containing a cuda_* import 96
blocks rustfmt would change 38 (19 files)
blocks rustfmt cannot parse (partial snippets) 49
The 38 break down as: crates not sorted (cuda_device / cuda_host ahead of cuda_core, and cuda_async where present), and DisjointSlice and friends sorted after the lowercase items inside the braces, which is not where style edition 2024 puts them.
Every one of the 38 diffs is imports-only. rustfmt does not touch a single non-import line in any of them, so this cannot reflow deliberately-formatted teaching code — I checked that specifically before filing, because that was the risk that would have made this not worth doing.
| file | blocks |
|---|---|
appendix/api-quick-reference.md |
4 |
gpu-programming/launching-kernels.md |
4 |
advanced/cluster-programming.md |
3 |
gpu-programming/closures-and-generics.md |
3 |
gpu-programming/memory-and-data-movement.md |
3 |
advanced/shared-memory-and-synchronization.md |
2 |
advanced/tensor-memory-accelerator.md |
2 |
advanced/warp-level-programming.md |
2 |
getting-started/hello-gpu.md |
2 |
gpu-programming/error-handling-and-debugging.md |
2 |
gpu-programming/virtual-memory-and-peer-access.md |
2 |
gpu-safety/the-safety-model.md |
2 |
| seven more files | 1 each |
Why nothing catches it
A markdown code block is compiled by nothing and formatted by nothing. scripts/check-book-api-names.sh verifies that every device-API name the docs show exists, which is a different property and passes today.
Scope
The 49 blocks rustfmt cannot parse are partial snippets with no enclosing item, and are left alone: reformatting them would mean inventing a wrapper, and the ordering question does not arise for most of them anyway.
I have a fix and will open a PR.
Activity
vyncint commentedon Sep 5, 2026
Correcting the numbers above before anyone acts on them: the "38 blocks, every diff imports-only" figure is wrong, and so is the per-file table. My measurement script filtered rustfmt's
--checkoutput withline.startswith("-"), but that output is colourised, so every changed line actually begins with an ANSI escape. Nothing matched, the "is every changed line an import?" test was vacuously true, and 38 was the count of blocks that differ from rustfmt for any reason at all.Re-measured with
--color=never, over the same 96 blocks that contain acuda_*import:The 23 are teaching code rustfmt would reflow for unrelated reasons -- one-parameter-per-line function signatures,
{ /* ... */ }split across lines, collapsing a wrapped call. Touching those is a different change with a different argument, so they stay as they are.So the real scope is 15 blocks across 14 files, not 38 across 19.
Two things this cost, worth recording since both are the same mistake in different clothes:
unsafe { ... }re-split. Caught it by diffing rather than by trusting the classifier.git difffor anything that is not ausestatement or one of its continuation lines.After the fix: 73 clean, 0 differing in imports, the same 23 differing in other formatting as before. The book builds under
sphinx-build -W, andcheck-book-api-names.shstill passes.