summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorVincent Woltmann <vincent@woltmann.art>2024-08-16 23:01:42 +0300
committerMiguel Ojeda <ojeda@kernel.org>2024-08-21 14:29:36 +0300
commit5d88f98b2e73b2928cab7f8bd3d67777cb9ea1e7 (patch)
treedf2647040cf64c6c0ba13e8c0bba61104d256d87
parentfd764e74e5b75512be1b55ec9680a6c35885cc63 (diff)
downloadlinux-5d88f98b2e73b2928cab7f8bd3d67777cb9ea1e7.tar.xz
docs: rust: remove unintended blockquote in Coding Guidelines
An unordered list in coding-guidelines.rst was indented, producing a blockquote around it and making it look more indented than expected. Remove the indentation to only output an unordered list. Reported-by: Miguel Ojeda <ojeda@kernel.org> Closes: https://github.com/Rust-for-Linux/linux/issues/1063 Fixes: d07479b211b7 ("docs: add Rust documentation") Signed-off-by: Vincent Woltmann <vincent@woltmann.art> Link: https://lore.kernel.org/r/20240816200339.2495875-1-vincent@woltmann.art [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
-rw-r--r--Documentation/rust/coding-guidelines.rst38
1 files changed, 19 insertions, 19 deletions
diff --git a/Documentation/rust/coding-guidelines.rst b/Documentation/rust/coding-guidelines.rst
index 05542840b16c..329b070a1d47 100644
--- a/Documentation/rust/coding-guidelines.rst
+++ b/Documentation/rust/coding-guidelines.rst
@@ -145,32 +145,32 @@ This is how a well-documented Rust function may look like:
This example showcases a few ``rustdoc`` features and some conventions followed
in the kernel:
- - The first paragraph must be a single sentence briefly describing what
- the documented item does. Further explanations must go in extra paragraphs.
+- The first paragraph must be a single sentence briefly describing what
+ the documented item does. Further explanations must go in extra paragraphs.
- - Unsafe functions must document their safety preconditions under
- a ``# Safety`` section.
+- Unsafe functions must document their safety preconditions under
+ a ``# Safety`` section.
- - While not shown here, if a function may panic, the conditions under which
- that happens must be described under a ``# Panics`` section.
+- While not shown here, if a function may panic, the conditions under which
+ that happens must be described under a ``# Panics`` section.
- Please note that panicking should be very rare and used only with a good
- reason. In almost all cases, a fallible approach should be used, typically
- returning a ``Result``.
+ Please note that panicking should be very rare and used only with a good
+ reason. In almost all cases, a fallible approach should be used, typically
+ returning a ``Result``.
- - If providing examples of usage would help readers, they must be written in
- a section called ``# Examples``.
+- If providing examples of usage would help readers, they must be written in
+ a section called ``# Examples``.
- - Rust items (functions, types, constants...) must be linked appropriately
- (``rustdoc`` will create a link automatically).
+- Rust items (functions, types, constants...) must be linked appropriately
+ (``rustdoc`` will create a link automatically).
- - Any ``unsafe`` block must be preceded by a ``// SAFETY:`` comment
- describing why the code inside is sound.
+- Any ``unsafe`` block must be preceded by a ``// SAFETY:`` comment
+ describing why the code inside is sound.
- While sometimes the reason might look trivial and therefore unneeded,
- writing these comments is not just a good way of documenting what has been
- taken into account, but most importantly, it provides a way to know that
- there are no *extra* implicit constraints.
+ While sometimes the reason might look trivial and therefore unneeded,
+ writing these comments is not just a good way of documenting what has been
+ taken into account, but most importantly, it provides a way to know that
+ there are no *extra* implicit constraints.
To learn more about how to write documentation for Rust and extra features,
please take a look at the ``rustdoc`` book at: