Skip to content

Clean section header order, document it and implement a checkpatch.pl check #1116

@BennoLossin

Description

@BennoLossin
Member

We want to standardize the order in which we list section headers in rustdoc. The reason for this is that the API relevant sections should come first, in order to not miss them. The suggested ordering is:

  • # Safety
  • # Guarantees
  • # Panics
  • # Errors
  • # Examples
  • # Invariants

The first four sections are part of the API surface of the documented item. # Invariants are listed as the last section, because they are implementation detail rather than belonging to the API.
This should only be the standard for items that are not modules. For modules, we usually have custom sections.

Fix the ordering in existing code (for example there are some instances in rust/kernel/workqueue.rs), document the ordering under Documentation/rust/coding-guidelines.rst and create a checkpatch.pl check. Each of theses should be its own patch; depending on the size of the changes in existing code, you might want to split that up into multiple patches as well.

Please note that the checkpatch.pl maintainers will need to agree to the change.


This requires submitting a proper patch to the LKML and the Rust for Linux mailing list. Please recall to test your changes (including generating the documentation if changed, running the Rust doctests if changed, etc.), to use a proper title for the commit, to sign your commit under the Developer's Certificate of Origin and to add a Suggested-by: tag and a Link: tag to this issue. Please see https://rust-for-linux.com/contributing for details.

Please take this issue only if you are new to the kernel development process and you would like to use it as a test to submit your first patch to the kernel. Please do not take it if you do not plan to make other contributions to the kernel.

Activity

frazar

frazar commented on Sep 14, 2024

@frazar

Based on the wording of the last paragraph, I believe this issue is missing the "good first issue" label.

BennoLossin

BennoLossin commented on Sep 14, 2024

@BennoLossin
MemberAuthor

I intentionally did not put the label on there yet: I wanted to know if someone objected to the proposal in the zulip, I plan to add the label tomorrow, if nobody shouts

kuku929

kuku929 commented on Sep 17, 2024

@kuku929

hello, can I work on this?

BennoLossin

BennoLossin commented on Sep 23, 2024

@BennoLossin
MemberAuthor

sure, go ahead (or did @frazar also want to take a shot at this?)

frazar

frazar commented on Sep 23, 2024

@frazar

Thank you, but I don't plan to work on this. @kuku929 you can go ahead!

added
• docsRelated to `Documentation/rust/`, `samples/`, generated docs, doctests, typos...
mediumExpected to be an issue of medium difficulty to resolve.
easyExpected to be an easy issue to resolve.
on Nov 25, 2024
tamird

tamird commented on Feb 14, 2025

@tamird

Perhaps this would be better placed in rustdoc. Have we engaged with upstream about this request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

easyExpected to be an easy issue to resolve.good first issueGood for newcomersmediumExpected to be an issue of medium difficulty to resolve.• docsRelated to `Documentation/rust/`, `samples/`, generated docs, doctests, typos...

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @frazar@ojeda@tamird@kuku929@BennoLossin

      Issue actions

        Clean section header order, document it and implement a `checkpatch.pl` check · Issue #1116 · Rust-for-Linux/linux