Lines Matching +full:single +full:- +full:instance

1 .. SPDX-License-Identifier: GPL-2.0
10 ------------------
22 style is followed. For instance, 4 spaces are used for indentation rather
33 otherwise), for instance for a CI, with::
37 Like ``clang-format`` for the rest of the kernel, ``rustfmt`` works on
46 the same line. For instance:
48 .. code-block:: rust
60 .. code-block:: rust
82 .. code-block:: rust
94 for single item imports -- this can be useful to minimize diffs within patch
97 .. code-block:: rust
118 --------
124 comments more easily. For instance:
126 .. code-block:: rust
132 of a sentence and ended with a period (even if it is a single sentence). This
135 .. code-block:: rust
143 For instance, for a ``TODO`` list or to comment on the documentation itself.
148 .. code-block:: rust
159 	pub fn f(x: i32) -> Foo {
167 should still be used. For instance:
169 .. code-block:: rust
179 .. code-block:: rust
193 ------------------
195 Rust kernel code is not documented like C kernel code (i.e. via kernel-doc).
199 To learn Markdown, there are many guides available out there. For instance,
204 This is how a well-documented Rust function may look like:
206 .. code-block:: rust
215 	/// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
223 	pub unsafe fn unwrap_unchecked(self) -> T {
235 - The first paragraph must be a single sentence briefly describing what
238 - Unsafe functions must document their safety preconditions under
241 - While not shown here, if a function may panic, the conditions under which
248 - If providing examples of usage would help readers, they must be written in
251 - Rust items (functions, types, constants...) must be linked appropriately
254 - Any ``unsafe`` block must be preceded by a ``// SAFETY:`` comment
265 	https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html
268 prefixing the link destination with ``srctree/``. For instance:
270 .. code-block:: rust
276 .. code-block:: rust
282 -----------
286 not use the aliases from ``core::ffi`` -- they may not map to the correct types.
289 as a single segment path. For instance:
291 .. code-block:: rust
293 	fn f(p: *const c_char) -> c_int {
299 ------
303 	https://rust-lang.github.io/api-guidelines/naming.html
308 back and forth between the C and Rust sides. For instance, macros such as
313 repeated in the item names. For instance, when wrapping constants like:
315 .. code-block:: c
322 .. code-block:: rust
337 -----
346 .. code-block:: c
349 	#pragma GCC diagnostic ignored "-Wunused-function"
359 .. code-block:: rust
370 It makes the compiler warn if the warning was not produced. For instance, the
374 .. code-block:: rust
382 	 --> x.rs:3:10
392 - Temporary attributes added while developing.
394 - Improvements in lints in the compiler, Clippy or custom tools which may
397 - When the lint is not needed anymore because it was expected that it would be
405 - Conditional compilation triggers the warning in some cases but not others.
412 - Inside macros, when the different invocations may create expanded code that
415 - When code may trigger a warning for some architectures but not others, such
418 As a more developed example, consider for instance this program:
420 .. code-block:: rust
432 .. code-block:: rust
443 configuration. Therefore, in cases like this, we cannot use ``expect`` as-is.
447 .. code-block:: rust
459 .. code-block:: rust
475 triggered due to non-local changes (such as ``dead_code``).
479 	https://doc.rust-lang.org/stable/reference/attributes/diagnostics.html
482 --------------
487 	https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust