Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustdoc wanted features & bugfixes #350

Open
5 of 17 tasks
ojeda opened this issue Jun 4, 2021 · 3 comments
Open
5 of 17 tasks

rustdoc wanted features & bugfixes #350

ojeda opened this issue Jun 4, 2021 · 3 comments
Labels
meta Meta issue. • toolchain Related to `rustc`, `bindgen`, `rustdoc`, LLVM, Clippy...

Comments

@ojeda
Copy link
Member

ojeda commented Jun 4, 2021

Note: there is the "A-rust-for-linux" label in the rust repository: https://github.com/rust-lang/rust/labels/A-rust-for-linux.

Features that we would like to see

Required (we almost certainly want them)

  • External references map file.

    • The idea is to be able to write intra-doc-like links that point to external resources, e.g.:

      /// Uses the kernel's C [`struct mutex`].

      where the URL is automatically provided, e.g. to some C documentation. Similarly, it could be use to avoid duplicating URLs that need to be manually updated, e.g. like a BibTeX database file. For instance, references to external articles, page/webs, papers, Wikipedia entries, etc.

      To define those links, rustdoc could be given a "external references" file containing a map of (term, URL) pairs (e.g. in a JSON or Markdown-references-like file with one reference per line), possibly passed via the CLI, e.g.:

      --external-references-file books.json

      That way, the user is the one that defines the links and terms, possibly exporting them from other tooling (such as a documentation tool for another programming language).

      Multiple files could also be allowed -- having different files for different topics/categories of references may be useful/cleaner for users.

      An interesting extension could be to allow references to contain extra metadata (i.e. not just the URL), like in BibTeX. rustdoc could then potentially render that metadata somehow, like Wikipedia's references (e.g. when clicking them, or when clicking a small information button close to the link, or as a footnote, or on hover...). Another possibility is that, even without any extra metadata, rustdoc could also decide to render them differently than "normal links".

      There is potential for ambiguity with existing links. Possibly a syntax could be provided to disambiguate (whether required in all cases or just in cases of ambiguity), as suggested by @aDotInTheVoid, e.g.:

      /// Uses the kernel's [extern@`struct mutex`].

      Currently (Rust 1.78), when one uses an intra-doc link that matches a Markdown one (i.e. the intra-doc link title is the same as the Markdown link label of a link reference definition), rustdoc renders it as the Markdown link, rather than the intra-doc link, without warning, e.g.:

      /// This ambiguous link ([`ThisModule`]) goes to the website, not to the Rust item.
      ///
      /// [`ThisModule`]: https://rust-for-linux.com

      An alternative could have been to use:

      --markdown-after-content references.md

      with a references.md file with:

      [Wikipedia]: https://www.wikipedia.org

      but currently (Rust 1.78) those references cannot be used from elsewhere. Instead, a potential --markdown-after-every-item could work.

      Similarly, including the references via include_str! as suggested by @jyn514 works, e.g.:

      /// Here are all the docs, with [Wikipedia] links.
      ///
      #[doc = include_str!("references.md")]

      but requires doing so in each case/item (rather than globally).

    • Status: Idea seemed reasonable to maintainers, RFC to be written.

    • Cc: @aDotInTheVoid, @GuillaumeGomez, @jyn514.

  • rustdoc lint to flag potential intra-doc links.

  • Documentation under conditional compilation.

  • Custom logo/favicon flag (for local/bundled image files).

Nice to have (not critical, we could workaround if needed, etc.)

Low priority (we will likely not use them in the end)

Done (stabilized, fixed, not needed anymore, etc.)


Bugs that we would like to see fixed

Required (we almost certainly want them)

Nice to have (probably not critical, we could workaround if needed, etc.)

Low priority (we will likely not use them in the end)

Done (stabilized, fixed, or not needed anymore, etc.)

@ojeda ojeda added • toolchain Related to `rustc`, `bindgen`, `rustdoc`, LLVM, Clippy... prio: low meta Meta issue. and removed prio: low labels Jun 4, 2021
@ojeda ojeda changed the title rustdoc wanted features rustdoc wanted features & bugfixes Jun 4, 2021
ojeda pushed a commit that referenced this issue Jun 11, 2024
Add a test case to assert that the skb->pkt_type which was set from the BPF
program is retained from the netkit xmit side to the peer's device at tcx
ingress location.

  # ./vmtest.sh -- ./test_progs -t netkit
  [...]
  ./test_progs -t netkit
  [    1.140780] bpf_testmod: loading out-of-tree module taints kernel.
  [    1.141127] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel
  [    1.284601] tsc: Refined TSC clocksource calibration: 3408.006 MHz
  [    1.286672] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fd9b189d, max_idle_ns: 440795225691 ns
  [    1.290384] clocksource: Switched to clocksource tsc
  #345     tc_netkit_basic:OK
  #346     tc_netkit_device:OK
  #347     tc_netkit_multi_links:OK
  #348     tc_netkit_multi_opts:OK
  #349     tc_netkit_neigh_links:OK
  #350     tc_netkit_pkt_type:OK
  Summary: 6/0 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
@lolbinarycat
Copy link

Idea seemed reasonable to maintainers, RFC to be written.

Any progress on that? I've been working on rustdoc, and recently I've been cleaning up a few things in the intra-doc link system.

@ojeda
Copy link
Member Author

ojeda commented Nov 9, 2024

Not yet -- I will eventually get to it, since we are definitely interested in it. I have had a few more ideas around it. If you have time to put into it, please let me now!

@lolbinarycat
Copy link

I have plenty of time, the limitation is actually if t-rustdoc has enough time to review the contributions!

being able to say "rust4linux wants it" would probably help a fair bit towards getting it prioritized, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Meta issue. • toolchain Related to `rustc`, `bindgen`, `rustdoc`, LLVM, Clippy...
Development

No branches or pull requests

2 participants