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

WIP: Add additional closing brace inlay hints #19207

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

markmurphydev
Copy link
Contributor

@markmurphydev markmurphydev commented Feb 23, 2025

Working on additional inlay hints for #18833, and looking for some guidance.

Currently we traverse the syntax tree, checking if the current node is a block-like expression, then figuring out the type of the parent.

  • It seems possible to go parent node -> child block, which might be more readable. Any opinion one way or the other?

Currently I include almost every child of the parent syntax element (ex. function's visibility, params, types, ...) in the type hint, then join newlines and truncate the string to InlayHintsConfig.max_length.

スクリーンショット 2025-02-22 午後6 48 36
  • HirFormatter has a max_size field, but most of the implementations don't currently respect it. If I updated them to do so, and also added a configuration to exclude specific children, I think the text for each inlay hint could be gotten with a single call like parent.display_truncate_exclude(max_size: 40, exclude: vec![block_child]). Does that seem like a good way to go?
  • I'm using format! on the AST nodes, because I had them already. If hir-format is not respecting max_size, is there still a reason to prefer HIR display functions?
  • Closing hints look pretty bad when the original definition spanned multiple lines. I join the newlines, but line-beginning whitespace from child tokens (ex. function parameters) stays in. To me, the most obvious solution is to do a regex match for whitespace, but I think we don't want to pull in the regex crate?
スクリーンショット 2025-02-22 午後7 35 07
  • I added "// " before closing-brace inlay hints, to make clear that they don't represent code. Does it look ok?

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 23, 2025
@markmurphydev markmurphydev force-pushed the closing_brace_inlay_hints branch from 3c25307 to 983729f Compare February 23, 2025 01:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants