[PATCH] rust: doctests: Use tabs for indentation in generated C code

[PATCH] rust: doctests: Use tabs for indentation in generated C code

[David Gow]

While Rust uses 4 spaces for indentation, we should use tabs in the
generated C code. This does result in some scary-looking tab characters
in a .rs file, but they're in a string literal, so shouldn't make
anything complain too much.

Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones")
Signed-off-by: David Gow <davidgow@google.com>
---
 scripts/rustdoc_test_gen.rs | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/rustdoc_test_gen.rs b/scripts/rustdoc_test_gen.rs
index 5ebd42ae4a3f..a625cf3517c0 100644
--- a/scripts/rustdoc_test_gen.rs
+++ b/scripts/rustdoc_test_gen.rs
@@ -242,13 +242,13 @@ macro_rules! assert_eq {{
 {c_test_declarations}
 
 static struct kunit_case test_cases[] = {{
-    {c_test_cases}
-    {{ }}
+	{c_test_cases}
+	{{ }}
 }};
 
 static struct kunit_suite test_suite = {{
-    .name = "rust_doctests_kernel",
-    .test_cases = test_cases,
+	.name = "rust_doctests_kernel",
+	.test_cases = test_cases,
 }};
 
 kunit_test_suite(test_suite);
-- 
2.41.0.255.g8b1d071c50-goog

Re: [PATCH] rust: doctests: Use tabs for indentation in generated C code

[Miguel Ojeda]

On Thu, Jul 20, 2023 at 8:30 AM David Gow <davidgow@google.com> wrote:
>
> While Rust uses 4 spaces for indentation, we should use tabs in the
> generated C code. This does result in some scary-looking tab characters
> in a .rs file, but they're in a string literal, so shouldn't make
> anything complain too much.
>
> Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones")
> Signed-off-by: David Gow <davidgow@google.com>

The indentation for the `KUNIT_CASE()` lines should be changed too:

diff --git a/scripts/rustdoc_test_gen.rs b/scripts/rustdoc_test_gen.rs
index 5ebd42ae4a3f..9623e2e6313d 100644
--- a/scripts/rustdoc_test_gen.rs
+++ b/scripts/rustdoc_test_gen.rs
@@ -213,7 +213,7 @@ macro_rules! assert_eq {{
         .unwrap();

         write!(c_test_declarations, "void {kunit_name}(struct kunit
*);\n").unwrap();
-        write!(c_test_cases, "    KUNIT_CASE({kunit_name}),\n").unwrap();
+        write!(c_test_cases, "    KUNIT_CASE({kunit_name}),\n").unwrap();
     }

     let rust_tests = rust_tests.trim();

With that:

    Acked-by: Miguel Ojeda <ojeda@kernel.org>

Since the changes are within string literals, I don't expect issues,
but I just in case I ran it through `checkpatch.pl`, `rustfmt` and
`CLIPPY=1`:

    Tested-by: Miguel Ojeda <ojeda@kernel.org>

Thanks!

Cheers,
Miguel

Re: [PATCH] rust: doctests: Use tabs for indentation in generated C code

[Martin Rodriguez Reboredo]

On 7/20/23 03:29, David Gow wrote:
> While Rust uses 4 spaces for indentation, we should use tabs in the
> generated C code. This does result in some scary-looking tab characters
> in a .rs file, but they're in a string literal, so shouldn't make
> anything complain too much.
> 
> Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones")
> Signed-off-by: David Gow <davidgow@google.com>
> ---
> [...]
I find it weird to mix indentations in one file, but if it leaves a
good result then I'll hold my tongue.

Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>

Re: [PATCH] rust: doctests: Use tabs for indentation in generated C code

[Miguel Ojeda]

On Fri, Jul 21, 2023 at 2:27 AM Martin Rodriguez Reboredo
<yakoyoku@gmail.com> wrote:
>
> I find it weird to mix indentations in one file, but if it leaves a
> good result then I'll hold my tongue.

In general I would agree, but I guess we can consider these as "data"
since they are part of a literal, and thus we could consider it is not
mixing indentations in that sense (for the Rust code).

It could potentially confuse a script or tool that does not know about
the language and make it report an inconsistency. But there is always
going to be a corner case or similar that you need to skip/ignore in a
tool like that. And, in other cases, like the analysis that was done
for the potential `.editorconfig` file, it would just be noise since
we don't do this kind of generation often within `.rs` files.

Either way is fine for me: I don't mind the status quo, because it is
just a generated file, so I don't expect many readers; and I don't
mind the file having the proper tabs for its file extension either,
and I guess perhaps having those tabs helps avoid some other tool
complaining about the file if it is run when the file exists.

Cheers,
Miguel