2023-07-20 07:10:13

by David Gow

[permalink] [raw]
Subject: [PATCH] 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.

Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones")
Signed-off-by: David Gow <[email protected]>
---
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



2023-07-20 10:58:04

by Miguel Ojeda

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

On Thu, Jul 20, 2023 at 8:30 AM David Gow <[email protected]> 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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

Thanks!

Cheers,
Miguel

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

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 <[email protected]>
> ---
> [...]
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 <[email protected]>

2023-07-21 16:51:54

by Miguel Ojeda

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

On Fri, Jul 21, 2023 at 2:27 AM Martin Rodriguez Reboredo
<[email protected]> 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