rust: doctests: Use tabs for indentation in generated C code

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.

---
 scripts/rustdoc_test_gen.rs | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

index 5ebd42ae4a3f..a625cf3517c0 100644
@@ -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

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

index 5ebd42ae4a3f..9623e2e6313d 100644
@@ -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:

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:

Thanks!

Cheers,
Miguel

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