Remove repetitive inlay hints

[matthewsanetra]

This removes/fixes unnecessary hints when the function name ends with the first param name, and increases readability.

Example:

s.strip_suffix(suffix: "Hello");

would now become

s.strip_suffix("Hello");

Happy Hacktoberfest! 🎉

[lnicola]

I'm surprised at the amount of heuristics that we've amassed here.

In this specific case, though, I'm worried about something like fn max(x: u32, y: u32). Maybe we should check that the function name matches the parameter name, or ends in _ followed by it? Also, this could probably use a test.

And thank you for the PR!

[matthewsanetra]

Oh wow, I didn't think about the fn max(x: u32, y: u32) scenario, I think the simplest way to fix this is to check if the fn_name ends with param_name prepended with _.

However, since single letter parameters aren't used unless its obvious, maybe we also just don't display single letter params?

[lnicola]

I think the simplest way to fix this is to check if the fn_name ends with param_name prepended with _.

Maybe? There might be functions with the same name as their arguments, but I can't think of an example.

However, since single letter parameters aren't used unless its obvious, maybe we also just don't display single letter params?

Maybe? 😆

[matthewsanetra]

I am extremely sorry for accidentally closing it, I'm going to remove the unnecessary allocation now.

[Veetaha]

I think to be more flexible we should just expose a configuration for a list of regular expressions with call patterns like it is done in Intelij

[Veetaha]

I didn't mean to stall this PR, it is definitely useful now. My comment is more about possible far future changes =)

[lnicola]

I think the heuristics work better because nobody has to compile a list of "obvious function signatures", not to mention that different people would have different notions of obviousness wrt. e.g. strncmp.

[matthewsanetra]

expose a configuration for a list of regular expressions with call patterns

Wouldn't that be best to do in an extension/client side?
To switch over you would need to:

• Encourage every r-a extension out there to add this functionality
• Slowly phase out heuristics inside the language server, making sure that users don't see any difference in user experience while this is happening.

[matthewsanetra]

CI is failing when testing proc_macro_srv, exiting with STATUS_ILLEGAL_INSTRUCTION. Any help?

[lnicola]

Try to rebase over master.

[matthewsanetra]

Hey -- I'm sorry, I'm new to contributing. I tried to rebase as with the help provided by the check_merge_commits check, but now it's saying conflicting files, and if I try to resolve that on GitHub the check fails. Any guidance?

[SomeoneToIgnore]

Hey, I've checked your branch and looks like you have the conflicts with master branch indeed:

both modified:   crates/ide/src/inlay_hints.rs
both modified:   crates/ide/src/references.rs
added by us:     crates/ide_db/src/apply_change.rs

Since you seem to have a single new commit in you branch, I suggest you to first pull the latest changes for the rust-analyzer's master branch and then rebase on top of it, fixing the conflicts for all 3 files.
Then you can force push into your remote branch to propagate the changes to the server.

[matthewsanetra]

Hi, Sorry @SomeoneToIgnore , I just did what you suggested, but then the build was failing as an import was missing, I just added that in the fix build commit, and now there's a conflict again. I'm really sorry, why does this happen?

[SomeoneToIgnore]

There can be many reasons: you could have not actually updated the master branch before resolving the conflicts, there can be new changes in that branch after you resolution, there can be something else I'm not aware of.

Anyway, you have to resolve those conflicts, so use the same approach again until they are gone.
If the merge conflicts do not disappear after a couple attempts, then you're doing something wrong and it'a a good time to stop and think thoroughly.

[matklad]

THere are also some hints here: https://github.com/rust-analyzer/rust-analyzer/blob/ef33953c70e361e8ab6b0bb6b0f5604e1f1c7f29/xtask/tests/tidy.rs#L67-L90