Skip to content

Conversation

@ozkutuk
Copy link
Collaborator

@ozkutuk ozkutuk commented Jan 31, 2026

While reviewing #4813, I realized that the code action for the expansion of positional records was producing the message "Expand record wildcard". This must be confusing for users on multiple levels, since:

  1. the actual effect is not at all related to wildcards
  2. depending on the set of enabled extensions the message may have "needs extension: NamedFieldPuns" suffix, which is not correct

This PR aims to fix this by producing different titles for the code action depending on whether it is a wildcard expansion or "positional record expansion". I have opted to rephrase the latter as "Convert to traditional record syntax", both to be consistent with the GADT conversion code action, and also with -XTraditionalRecordSyntax.

Copy link
Collaborator

@fendor fendor left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for fixing this :)

Perhaps let's land #4813 first and then this PR?

@ozkutuk ozkutuk force-pushed the improve-rec-conversion-msg branch from 4a98c22 to 0c84caa Compare February 1, 2026 17:34
@ozkutuk
Copy link
Collaborator Author

ozkutuk commented Feb 1, 2026

@fendor I have rebased the PR on top of master, and it is ready to merge from my perspective.

@fendor
Copy link
Collaborator

fendor commented Feb 1, 2026

Thanks!

In the future, you should also be able to merge, right?
We should probably document our policies, I think you should have the autonomy to merge plugin changes at your own responsibility... Perhaps a topic for the next HLS meeting.

@fendor fendor merged commit cff49d2 into haskell:master Feb 1, 2026
52 of 57 checks passed
@ozkutuk
Copy link
Collaborator Author

ozkutuk commented Feb 1, 2026

In the future, you should also be able to merge, right?

@fendor Yes, there were no technical blockers for me to merge, I was just being cautious (perhaps overly so) by leaving the final decision to a more "authoritative" maintainer.

We should probably document our policies, I think you should have the autonomy to merge plugin changes at your own responsibility... Perhaps a topic for the next HLS meeting.

Sounds like a good idea!

@fendor
Copy link
Collaborator

fendor commented Feb 1, 2026

I was just being cautious (perhaps overly so) by leaving the final decision to a more "authoritative" maintainer.

I understand that and it makes sense to me! I am a little worried, we have few "authoritative" maintainers left at the moment, rendering us kind of reliant on these few maintainers, waiting for their approval...
So we need to empower the maintainers we have to at least act with authority over the parts they "own". Hence, making sure that you do have the permissions to actually merge if no one else was around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants