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);
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
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
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
linux-kselftest-mirror@lists.linaro.org