Skip to content

Conversation

@yotamofek
Copy link
Contributor

@yotamofek yotamofek commented Nov 9, 2025

Not sure if I like this change or not, but it has some pros (and cons) so thought I'd put it up here for discussion.

In #148585 (comment), I lamented the fact that there was a lot of boilerplate around our print_* fns, due to the fmt::from_fn opening a new block (and indenting everything by another tab).
Using a macro to change the signature of a function is definitely not a good idea, so I attempted to do something similar with a trait and a blanket impl.

Basically, the DisplayFn trait is implemented for fns that take a &mut fmt::Formatter, a "clean" item, and a rustdoc ctx, and adds a display_fn method on such functions that does the whole fmt::from_fn wrapping.

Pros:

  • De-indent all our print fn code by one level
  • Maximalist API - call sites that already have a &mut Formatter can just pass it to the original function, while those that don't can use the display_fn trait method
  • IMHO improves readability for both the fns and the call sites

Major con:

  • Blanket impls on Fns are not the greatest DX. If you get a function signature wrong, the diagnostics are not going to be very helpful. And it's not really clear where that display_fn method is coming from (though I don't think it should matter much most of the time, since its functionality is pretty easy to infer from the context, IMHO)

r? @GuillaumeGomez feel free to just close this if you don't like the idea, not married to it myself :)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Nov 9, 2025
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [rustdoc] tests/rustdoc/return-type-notation.rs stdout ----
------python3 stdout------------------------------

------python3 stderr------------------------------
11: has check failed
 `XPATH PATTERN` did not match
 //@ has - '//pre[@class="rust item-decl"]' "pub fn foo<T: Foo<bar(..): Send>>()"

Encountered 1 errors

------------------------------------------

error: htmldocck failed!
status: exit status: 1
command: "/usr/bin/python3" "/checkout/src/etc/htmldocck.py" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/rustdoc/return-type-notation" "/checkout/tests/rustdoc/return-type-notation.rs"
stdout: none
--- stderr -------------------------------
11: has check failed
 `XPATH PATTERN` did not match
 //@ has - '//pre[@class="rust item-decl"]' "pub fn foo<T: Foo<bar(..): Send>>()"

Encountered 1 errors
------------------------------------------

---- [rustdoc] tests/rustdoc/return-type-notation.rs stdout end ----

@GuillaumeGomez
Copy link
Member

I'm personally not very convinced by this approach. ^^'

We basically exchange a level of indent for a level of indirection. It's a neat trick though.

@yotamofek
Copy link
Contributor Author

I can't convince you of something I don't believe in myself 😬

@yotamofek yotamofek closed this Nov 9, 2025
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 9, 2025
@GuillaumeGomez
Copy link
Member

I mean, we could bring this up at next rustdoc meeting (which is tomorrow haha).

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

Labels

T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants