From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: rust: update `kernel::c_str!` documentation
Date: Tue, 10 Mar 2026 12:05:04 +1000
Message-ID: <review-patch1-20260309-cstr-rename-macro-v2-1-25f7de75944e@kernel.org>
In-Reply-To: <20260309-cstr-rename-macro-v2-1-25f7de75944e@kernel.org>
References: <20260309-cstr-rename-macro-v2-1-25f7de75944e@kernel.org> <20260309-cstr-rename-macro-v2-1-25f7de75944e@kernel.org>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

**Summary:** Updates the doc comment on `c_str!` to explain that `c"literal=
"` syntax should be preferred for string literals, and that `c_str!` remain=
s useful for non-literal compile-time strings (e.g. `concat!(file!(), ...)`=
). Also adds a comment explaining why a `compile_error!` arm for literal ar=
guments was intentionally omitted.

**Positive observations:**

1. The updated doc comment at line 379-383 is clear and well-written, corre=
ctly explaining the relationship between `c"..."` literals and the macro.

2. The new "Panics" section (lines 385-387) documenting the interior NUL pa=
nic behavior is a good addition =E2=80=94 the old documentation only said "=
should not contain any `NUL` bytes" without specifying what happens.

3. The example is well-chosen:
   ```rust
   // This is allowed, but `c"literal"` should be preferred for literals.
   const BAD: &CStr =3D c_str!("literal");
  =20
   // `c_str!` is still needed for static non-literal C strings.
   const GOOD: &CStr =3D c_str!(concat!(file!(), ":", line!(), ": My CStr!"=
));
   ```
   Naming the first example `BAD` and the second `GOOD` makes the intent im=
mediately obvious.

4. The NB comment at lines 402-404 explaining the design decision not to ad=
d a `compile_error!` arm for `$str:lit` is valuable =E2=80=94 it preempts t=
he natural follow-up question of "why not just reject literals?" and explai=
ns that it would break macro authors who happen to have a literal at the to=
p of expansions.

**Minor observations:**

- The "Panics" section says the macro "panics" =E2=80=94 technically it's a=
 compile-time `panic!` (since it's used in a `const` context), which is a c=
ompilation error, not a runtime panic. This is arguably a pedantic distinct=
ion and the current wording matches Rust documentation conventions, so it's=
 fine as-is.

**Verdict:** Looks good. No issues found.

---
Generated by Claude Code Patch Reviewer