Skip to content

Generics signature help should include type parameter defaults #12729

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

Closed
jonas-schievink opened this issue Jul 9, 2022 · 1 comment · Fixed by #19596
Closed

Generics signature help should include type parameter defaults #12729

jonas-schievink opened this issue Jul 9, 2022 · 1 comment · Fixed by #19596
Assignees
Labels
C-feature Category: feature request S-actionable Someone could pick this issue up and work on it right now

Comments

@jonas-schievink
Copy link
Contributor

For example, in std::ops::ControlFlow::<$0, the signature help is rendered as enum ControlFlow<B, C>, which does not tell the user that C is optional and only B needs to be provided. Rendering the default type would fix that, and result in enum ControlFlow<B, C = ()>.

It's possible that a default type would be too long when fully rendered, so the length should probably be limited (the HirDisplay machinery can already do that).

@jonas-schievink jonas-schievink added the S-actionable Someone could pick this issue up and work on it right now label Jul 9, 2022
@flodiebold flodiebold added the C-feature Category: feature request label Jul 11, 2022
@lowr
Copy link
Contributor

lowr commented Jul 15, 2022

I'm working on this. (I hope I'm not conflicting with anyone else...:sweat_smile:)

Should the limit on the rendered type length be configurable like rust-analyzer.inlayHints.maxLength, or can it be a hard-coded arbitrary value?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature Category: feature request S-actionable Someone could pick this issue up and work on it right now
Projects
None yet
4 participants