diff options
| author | Jiri Kosina <jkosina@suse.com> | 2025-12-02 14:52:36 +0100 |
|---|---|---|
| committer | Jiri Kosina <jkosina@suse.com> | 2025-12-02 14:52:36 +0100 |
| commit | 1a2f09ae11b4657d49df6fa86744795f99c2ee27 (patch) | |
| tree | cb178345ab4408702ec6de5fe9910924bfae96d7 /Documentation/rust/coding-guidelines.rst | |
| parent | 59c752c59f12cfb56bbc0b213a4d24407959688a (diff) | |
| parent | 3b86c87f8dcbb8ba3b00d7adf7ccfff086f0f23e (diff) | |
Merge branch 'for-6.19/hid-bpf' into for-linus
- Bring in a couple more BPF drivers for various devices (Benjamin Tissoires)
Diffstat (limited to 'Documentation/rust/coding-guidelines.rst')
| -rw-r--r-- | Documentation/rust/coding-guidelines.rst | 75 |
1 files changed, 75 insertions, 0 deletions
diff --git a/Documentation/rust/coding-guidelines.rst b/Documentation/rust/coding-guidelines.rst index 6ff9e754755d..3198be3a6d63 100644 --- a/Documentation/rust/coding-guidelines.rst +++ b/Documentation/rust/coding-guidelines.rst @@ -38,6 +38,81 @@ Like ``clang-format`` for the rest of the kernel, ``rustfmt`` works on individual files, and does not require a kernel configuration. Sometimes it may even work with broken code. +Imports +~~~~~~~ + +``rustfmt``, by default, formats imports in a way that is prone to conflicts +while merging and rebasing, since in some cases it condenses several items into +the same line. For instance: + +.. code-block:: rust + + // Do not use this style. + use crate::{ + example1, + example2::{example3, example4, example5}, + example6, example7, + example8::example9, + }; + +Instead, the kernel uses a vertical layout that looks like this: + +.. code-block:: rust + + use crate::{ + example1, + example2::{ + example3, + example4, + example5, // + }, + example6, + example7, + example8::example9, // + }; + +That is, each item goes into its own line, and braces are used as soon as there +is more than one item in a list. + +The trailing empty comment allows to preserve this formatting. Not only that, +``rustfmt`` will actually reformat imports vertically when the empty comment is +added. That is, it is possible to easily reformat the original example into the +expected style by running ``rustfmt`` on an input like: + +.. code-block:: rust + + // Do not use this style. + use crate::{ + example1, + example2::{example3, example4, example5, // + }, + example6, example7, + example8::example9, // + }; + +The trailing empty comment works for nested imports, as shown above, as well as +for single item imports -- this can be useful to minimize diffs within patch +series: + +.. code-block:: rust + + use crate::{ + example1, // + }; + +The trailing empty comment works in any of the lines within the braces, but it +is preferred to keep it in the last item, since it is reminiscent of the +trailing comma in other formatters. Sometimes it may be simpler to avoid moving +the comment several times within a patch series due to changes in the list. + +There may be cases where exceptions may need to be made, i.e. none of this is +a hard rule. There is also code that is not migrated to this style yet, but +please do not introduce code in other styles. + +Eventually, the goal is to get ``rustfmt`` to support this formatting style (or +a similar one) automatically in a stable release without requiring the trailing +empty comment. Thus, at some point, the goal is to remove those comments. + Comments -------- |