rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] rust: Remove erronous blockquote in coding guidelines
@ 2024-08-16 20:01 Vincent Woltmann
  2024-08-21 10:52 ` Miguel Ojeda
  0 siblings, 1 reply; 2+ messages in thread
From: Vincent Woltmann @ 2024-08-16 20:01 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Vincent Woltmann, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
	Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
	Andreas Hindborg, Alice Ryhl, Jonathan Corbet, Wei Liu,
	Yuki Okushi, open list:DOCUMENTATION, open list

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>
---

Changes since v1:
 - Readded the last paragraph to the list, which was removed because I
   deleted too much indentation in v1

 Documentation/rust/coding-guidelines.rst | 38 ++++++++++++------------
 1 file 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:
-- 
2.41.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH v2] rust: Remove erronous blockquote in coding guidelines
  2024-08-16 20:01 [PATCH v2] rust: Remove erronous blockquote in coding guidelines Vincent Woltmann
@ 2024-08-21 10:52 ` Miguel Ojeda
  0 siblings, 0 replies; 2+ messages in thread
From: Miguel Ojeda @ 2024-08-21 10:52 UTC (permalink / raw)
  To: Vincent Woltmann
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
	Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
	Andreas Hindborg, Alice Ryhl, Jonathan Corbet, Wei Liu,
	Yuki Okushi, open list:DOCUMENTATION, open list

On Fri, Aug 16, 2024 at 10:04 PM Vincent Woltmann <vincent@woltmann.art> wrote:
>
> 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>

Applied to `rust-fixes` -- thanks!

    [ Reworded title. - Miguel ]

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-08-21 10:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-16 20:01 [PATCH v2] rust: Remove erronous blockquote in coding guidelines Vincent Woltmann
2024-08-21 10:52 ` Miguel Ojeda

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).