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

Support record positional construction inlay hints #4447

Merged
merged 9 commits into from
Dec 24, 2024

Conversation

jetjinser
Copy link
Contributor

@jetjinser jetjinser commented Nov 10, 2024

Resolves #4391, resolves #4212.

@jetjinser jetjinser requested a review from ozkutuk as a code owner November 10, 2024 18:22
mkCodeAction exts uid = InR CodeAction
{ _title = mkTitle exts
{ _title = mkTitle exts -- TODO: `Expand positional record` without NamedFieldPuns if RecordInfoApp
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing codeActionProvider only needs "the list of extensions, and a int to allow us to resolve it later", but here mkTitle needs to be decided based on the RecordInfo how to generate it; If the RecordInfo is obtained here, does it not conform to the idea of ​​resolve?

should I adjust the RecordInfo to make two codeActionProvider? Or is there any better way?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we probably don't want to get the RecordInfo here if we can avoid it, that's the expensive bit, right?

I would have thought that the code action doesn't apply it all if it's a RecordInfoApp. Isn't the code action only for record wildcards?

Copy link
Contributor Author

@jetjinser jetjinser Dec 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I also think we should avoid getting RecordInfo before resolve.

Since RecordInfoApp is a constructor of RecordInfo, so it is also processed in the code action provider that process RecordInfo.
I thought that the construction of positional record can also have code actions, which should also be considered?

When the code action resolves, we can get the RecordInfo, so a useless extension RecordWildCards will not actually be inserted if RecordInfo is RecordInfoApp.
The only problem with the current code is that the title of the code action will display Expand record wildcard (needs extension: NamedFieldPuns) (when the extension does not exist in current file), no matter what it is RecordInfo.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess what I'm saying is that we shouldn't have any code actions where the RecordInfo is RecordInfoApp, since RecordInfoApp can't be a wildcard, and that's what the code action applies to?

@jetjinser jetjinser changed the title Inlay hints positional record Support record positional construction inlay hints Nov 10, 2024
@jetjinser jetjinser force-pushed the inlay-hints-positional-record branch from 056a622 to b7f110f Compare November 12, 2024 10:20
@jetjinser jetjinser requested a review from wz1000 as a code owner November 12, 2024 10:20
@fendor fendor requested review from michaelpj and fendor November 30, 2024 15:22
@fendor fendor added the status: needs review This PR is ready for review label Nov 30, 2024
Copy link
Collaborator

@michaelpj michaelpj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good!

, _kind = Nothing -- neither a type nor a parameter
, _textEdits = Just (maybeToList te) -- same as CodeAction
, _tooltip = Just $ InL "Expand positional record" -- same as CodeAction
, _paddingLeft = Nothing -- padding after dotdot
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comment is not quite right?

getFields :: HsExpr GhcTc -> [LHsExpr GhcTc] -> Maybe RecordAppExpr
getFields (HsApp _ (unLoc -> (XExpr (ConLikeTc (conLikeFieldLabels -> fls) _ _))) _) _
| null fls = Nothing
getFields (HsApp _ constr@(unLoc -> (XExpr (ConLikeTc (conLikeFieldLabels -> fls) _ _))) arg) args
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can just guard this case with | not (null fls) and then delete the case above, since the fallthrough case will handle it?

mkCodeAction exts uid = InR CodeAction
{ _title = mkTitle exts
{ _title = mkTitle exts -- TODO: `Expand positional record` without NamedFieldPuns if RecordInfoApp
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we probably don't want to get the RecordInfo here if we can avoid it, that's the expensive bit, right?

I would have thought that the code action doesn't apply it all if it's a RecordInfoApp. Isn't the code action only for record wildcards?

@michaelpj
Copy link
Collaborator

Let's merge this!

@michaelpj michaelpj added merge me Label to trigger pull request merge and removed status: needs review This PR is ready for review labels Dec 24, 2024
@mergify mergify bot merged commit f09500b into haskell:master Dec 24, 2024
38 checks passed
@jetjinser jetjinser deleted the inlay-hints-positional-record branch December 25, 2024 02:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge me Label to trigger pull request merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Code action: switch to record syntax Inlay hints for positional record construction
3 participants