From: Miguel Ojeda <ojeda@xxxxxxxxxx> commit 04866494e936d041fd196d3a36aecd979e4ef078 upstream. Discuss `#[expect(...)]` in the Lints sections of the coding guidelines document, which is an upcoming feature in Rust 1.81.0, and explain that it is generally to be preferred over `allow` unless there is a reason not to use it (e.g. conditional compilation being involved). Tested-by: Gary Guo <gary@xxxxxxxxxxx> Reviewed-by: Gary Guo <gary@xxxxxxxxxxx> Link: https://lore.kernel.org/r/20240904204347.168520-19-ojeda@xxxxxxxxxx Signed-off-by: Miguel Ojeda <ojeda@xxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- Documentation/rust/coding-guidelines.rst | 110 +++++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) --- a/Documentation/rust/coding-guidelines.rst +++ b/Documentation/rust/coding-guidelines.rst @@ -262,6 +262,116 @@ default (i.e. outside ``W=`` levels). In false positives but that are otherwise quite useful to keep enabled to catch potential mistakes. +On top of that, Rust provides the ``expect`` attribute which takes this further. +It makes the compiler warn if the warning was not produced. For instance, the +following will ensure that, when ``f()`` is called somewhere, we will have to +remove the attribute: + +.. code-block:: rust + + #[expect(dead_code)] + fn f() {} + +If we do not, we get a warning from the compiler:: + + warning: this lint expectation is unfulfilled + --> x.rs:3:10 + | + 3 | #[expect(dead_code)] + | ^^^^^^^^^ + | + = note: `#[warn(unfulfilled_lint_expectations)]` on by default + +This means that ``expect``\ s do not get forgotten when they are not needed, which +may happen in several situations, e.g.: + +- Temporary attributes added while developing. + +- Improvements in lints in the compiler, Clippy or custom tools which may + remove a false positive. + +- When the lint is not needed anymore because it was expected that it would be + removed at some point, such as the ``dead_code`` example above. + +It also increases the visibility of the remaining ``allow``\ s and reduces the +chance of misapplying one. + +Thus prefer ``except`` over ``allow`` unless: + +- The lint attribute is intended to be temporary, e.g. while developing. + +- Conditional compilation triggers the warning in some cases but not others. + + If there are only a few cases where the warning triggers (or does not + trigger) compared to the total number of cases, then one may consider using + a conditional ``expect`` (i.e. ``cfg_attr(..., expect(...))``). Otherwise, + it is likely simpler to just use ``allow``. + +- Inside macros, when the different invocations may create expanded code that + triggers the warning in some cases but not in others. + +- When code may trigger a warning for some architectures but not others, such + as an ``as`` cast to a C FFI type. + +As a more developed example, consider for instance this program: + +.. code-block:: rust + + fn g() {} + + fn main() { + #[cfg(CONFIG_X)] + g(); + } + +Here, function ``g()`` is dead code if ``CONFIG_X`` is not set. Can we use +``expect`` here? + +.. code-block:: rust + + #[expect(dead_code)] + fn g() {} + + fn main() { + #[cfg(CONFIG_X)] + g(); + } + +This would emit a lint if ``CONFIG_X`` is set, since it is not dead code in that +configuration. Therefore, in cases like this, we cannot use ``expect`` as-is. + +A simple possibility is using ``allow``: + +.. code-block:: rust + + #[allow(dead_code)] + fn g() {} + + fn main() { + #[cfg(CONFIG_X)] + g(); + } + +An alternative would be using a conditional ``expect``: + +.. code-block:: rust + + #[cfg_attr(not(CONFIG_X), expect(dead_code))] + fn g() {} + + fn main() { + #[cfg(CONFIG_X)] + g(); + } + +This would ensure that, if someone introduces another call to ``g()`` somewhere +(e.g. unconditionally), then it would be spotted that it is not dead code +anymore. However, the ``cfg_attr`` is more complex than a simple ``allow``. + +Therefore, it is likely that it is not worth using conditional ``expect``\ s when +more than one or two configurations are involved or when the lint may be +triggered due to non-local changes (such as ``dead_code``). + For more information about diagnostics in Rust, please see: https://doc.rust-lang.org/stable/reference/attributes/diagnostics.html Patches currently in stable-queue which might be from ojeda@xxxxxxxxxx are queue-6.12/drm-panic-avoid-reimplementing-iterator-find.patch queue-6.12/documentation-rust-add-coding-guidelines-on-lints.patch queue-6.12/rust-provide-proper-code-documentation-titles.patch queue-6.12/rust-alloc-make-allocator-module-public.patch queue-6.12/rust-alloc-remove-vecext-extension.patch queue-6.12/rust-alloc-implement-reallocfunc.patch queue-6.12/rust-alloc-separate-aligned_size-from-krealloc_aligned.patch queue-6.12/rust-enable-clippy-unnecessary_safety_comment-lint.patch queue-6.12/rust-alloc-update-module-comment-of-alloc.rs.patch queue-6.12/rust-kbuild-expand-rusttest-target-for-macros.patch queue-6.12/rust-error-use-core-alloc-layouterror.patch queue-6.12/rust-str-test-replace-alloc-format.patch queue-6.12/loongarch-use-asm_reachable.patch queue-6.12/rust-alloc-implement-allocator-for-kmalloc.patch queue-6.12/rust-alloc-implement-collect-for-intoiter.patch queue-6.12/rust-alloc-introduce-arraylayout.patch queue-6.12/rust-alloc-implement-vmalloc-allocator.patch queue-6.12/documentation-rust-discuss-in-the-guidelines.patch queue-6.12/rust-error-check-for-config-test-in-error-name.patch queue-6.12/rust-enable-clippy-ignored_unit_patterns-lint.patch queue-6.12/rust-enable-clippy-unnecessary_safety_doc-lint.patch queue-6.12/rust-alloc-add-box-to-prelude.patch queue-6.12/kbuild-rust-remove-the-alloc-crate-and-globalalloc.patch queue-6.12/rust-alloc-add-allocator-trait.patch queue-6.12/rust-treewide-switch-to-our-kernel-box-type.patch queue-6.12/rust-introduce-.clippy.toml.patch queue-6.12/rust-alloc-rename-kernelallocator-to-kmalloc.patch queue-6.12/rust-alloc-implement-cmalloc-in-module-allocator_test.patch queue-6.12/drm-panic-allow-verbose-version-check.patch queue-6.12/rust-map-__kernel_size_t-and-friends-also-to-usize-isize.patch queue-6.12/rust-alloc-add-module-allocator_test.patch queue-6.12/rust-replace-clippy-dbg_macro-with-disallowed_macros.patch queue-6.12/rust-alloc-add-__gfp_nowarn-to-flags.patch queue-6.12/rust-enable-clippy-s-check-private-items.patch queue-6.12/rust-error-make-conversion-functions-public.patch queue-6.12/rust-sort-global-rust-flags.patch queue-6.12/rust-alloc-implement-contains-for-flags.patch queue-6.12/rust-init-remove-unneeded.patch queue-6.12/rust-use-custom-ffi-integer-types.patch queue-6.12/rust-sync-remove-unneeded.patch queue-6.12/rust-treewide-switch-to-the-kernel-vec-type.patch queue-6.12/rust-alloc-implement-kvmalloc-allocator.patch queue-6.12/drm-panic-correctly-indent-continuation-of-line-in-list-item.patch queue-6.12/rust-alloc-implement-kernel-vec-type.patch queue-6.12/rust-workqueue-remove-unneeded.patch queue-6.12/rust-error-optimize-error-type-to-use-nonzero.patch queue-6.12/drm-panic-remove-unnecessary-borrow-in-alignment_pattern.patch queue-6.12/rust-alloc-remove-extension-of-std-s-box.patch queue-6.12/rust-block-fix-formatting-in-gendisk-doc.patch queue-6.12/rust-enable-rustdoc-unescaped_backticks-lint.patch queue-6.12/rust-fix-size_t-in-bindgen-prototypes-of-c-builtins.patch queue-6.12/rust-enable-clippy-undocumented_unsafe_blocks-lint.patch queue-6.12/rust-alloc-add-vec-to-prelude.patch queue-6.12/rust-alloc-implement-intoiterator-for-vec.patch queue-6.12/rust-alloc-implement-kernel-box.patch queue-6.12/drm-panic-remove-redundant-field-when-assigning-value.patch queue-6.12/rust-types-avoid-repetition-in-as-from-bytes-impls.patch queue-6.12/rust-start-using-the-attribute.patch queue-6.12/drm-panic-allow-verbose-boolean-for-clarity.patch queue-6.12/maintainers-add-entry-for-the-rust-alloc-module.patch queue-6.12/rust-alloc-fix-arraylayout-allocations.patch queue-6.12/drm-panic-prefer-eliding-lifetimes.patch
