fix: include trailing underscores when hiding inlay hints

[A4-Tacks]

Using suffix underscores to avoid keywords is one of the common skill, and inlayHints hiding should support it

Example

Before this PR:

fn far(loop_: u32) {}
fn faz(r#loop: u32) {}

let loop_level = 0;
far(loop_level);
  //^^^^^^^^^^ loop_
faz(loop_level);

After this PR:

fn far(loop_: u32) {}
fn faz(r#loop: u32) {}

let loop_level = 0;
far(loop_level);
faz(loop_level);

[ChayimFriedman2]

Personally, I'm opposed to this. This feels like adding confusing magic. If we'll have data that shows that this is common practice in the ecosystem (more common than alternative methods, e.g. choosing alternative words and using #[serde(rename)] etc.), maybe I'll be willing to reconsider my stance.

Something I do consider is removing prefix underscores, as this is codified in the language (to discard unused warning).

[A4-Tacks]

If we'll have data that shows that this is common practice in the ecosystem

Please run git grep -IP '\b[a-z]+_\b' at the root of the rust-analyzer project

At least it is indeed a common pattern

[ChayimFriedman2]

rust-analyzer is unique in that, by its nature, it has many names that are Rust keywords. Other projects will have less. And yet I'm not sure that's the most common way of mangling them - in fact I'm pretty sure it's not. We use krate, konst, ...

[A4-Tacks]

I ran the following command in the ~/.cargo/registry/src/index.crates.io-*

$ grep -RIP '\b[a-z]+_\b' */src | wc -l
6699
$ ls | wc -l
1021

Out of 1021 crates, this skill was used 6699 times

[ChayimFriedman2]

Your regex is incorrect. I printed the first 100 results in my dir. Here's the summary:

• Most are in fact in the docs (doc comments, mostly).
• The majority cite only some part of the name (e.g. If you try to execute a search using a `try_` , ````assert_*_{eq, ne}!` ```)
• Some are using _ for italics in markdown.
• There are also few genuine matches.

[ChayimFriedman2]

I tried to use ((fn|let) \b[a-z]+_\b|\b[a-z]+_\b: ), which should be a more correct representative. From 1,259 crates, I got only 1,516 matches.

[ChayimFriedman2]

And if I become more strict, and uses the regex:

[\(,][\s\n*](as_|async_|await_|break_|const_|continue_|crate_|dyn_|else_|enum_|extern_|false_|fn_|for_|if_|impl_|in_|let_|loop_|match_|mod_|move_|mut_|pub_|ref_|return_|Self_|static_|struct_|super_|trait_|true_|type_|unsafe_|use_|where_|while_|async_|await_|dyn_|abstract_|become_|box_|do_|final_|gen_|macro_|override_|priv_|try_|typeof_|unsized_|virtual_|yield_|try_|macro_rules_|raw_|safe_|union_|i8_|i16_|i32_|i64_|i128_|isize_|u8_|u16_|u32_|u64_|u128_|usize_|char_|bool_|f32_|f64_): 

Which:

• Considers only keywords/type names.
• Excludes self, because it may confuse people to think this is a method.
• Requires a function parameter, which is what relevant here

I get only 188 matches.

And remember, my criterion was not "widely used", it was "widely used more than alternatives, enough to justify special treatment. And that we have no real way to measure with regexes.

---

However, now I see (and sorry for looking too quickly) that this is not about changing the name of the parameter in the hint, just about hiding it when there is a match. That I don't mind both prefix and suffix underscores, we already have a bunch of heuristics there anyway. I will prefer this PR to also strip leading underscores though.

[A4-Tacks]

$ grep -RIP '((fn|let) \b[a-z]+_\b|\b[a-z]+_\b: )' */src | wc -l
2707
$ ls | wc -l
1021

The new regex returned more accurate results

This feels like adding confusing magic.

This seems insignificant, it's just inlayHints and hardly disrupts old behavior

e.g. choosing alternative words

For 'alternative words', proactive typo (such as 'krate') increases the burden of first reading,
while r#crate is considered ugly to some extent

and using #[serde(rename)] etc.

The function parameters have nothing to do with this

• Considers only keywords/type names.
• Excludes self, because it may confuse people to think this is a method.

Do I need to implement these?

[ChayimFriedman2]

Do I need to implement these?

No, because:

However, now I see (and sorry for looking too quickly) that this is not about changing the name of the parameter in the hint, just about hiding it when there is a match. That I don't mind both prefix and suffix underscores, we already have a bunch of heuristics there anyway. I will prefer this PR to also strip leading underscores though.

[A4-Tacks]

I will prefer this PR to also strip leading underscores though.

Using param_name.trim_matches('_') will remove the leading and trailing underscores, right

EDIT: If I understand correctly, is this PR okay?

[ChayimFriedman2]

Yes, thanks!