Case split plugin

[Aster89]

This PR is for (re-¹)introducing the so called case-split plugin, as requested in #5013, and it is part of my project for GSoC 2026.

To see the full summary of the project, click here. The summary also contains a list of stretch goals, some of which have been addressed already.

The work I've done and that I plan to submit via the present pull request, has consisted mainly of:

• implementing the case-split plugin by incrementally focusing on several use-cases from less to more complex,
• making use of ghc-exactprint for correctly layout out the patterns to be inserted,
• contextually writing tests for guarding such use-cases as I enabled them,
• finally, striving to address some stretch goals.

The result of such work is a plugin providing a code action for adding missing patterns to a case/\case expression that has a non-exhaustive list of patterns.

For instance, the plugin turns this

data X = A
       | B
       | C Int
       | D Int Int
       | E Int Int Int Int
       | F

foo :: X -> Int
foo x = case x of
          A -> 3;
                B -> 4;
              C _ -> 5

into this

data X = -- same as above

foo :: X -> Int
foo x = case x of
          A -> 3;
                B -> 4;
              C _ -> 5
          D _ _ -> _
          E {} -> _
          F -> _

---

¹ Earlier attempts

Indeed, there were some earlier attempts. See the summary for some pointers.

[dschrempf]

Everybody is eagerly anticipating this change, thank you!

Given the many WIP commits, I just wanted to ask if you could sqaush or reword them. I guess you had this in mind anyways.

[Aster89]

Everybody is eagerly anticipating this change, thank you!

Glad to hear that!

Given the many WIP commits, I just wanted to ask if you could sqaush or reword them. I guess you had this in mind anyways.

Yep, see 3rd paragraph at the top :P

[dschrempf]

Ah, the second sub-clause :-P my attention had already shifted before that one, I apologize :-)! Thanks!

[MangoIV]

First pass. I think after you clean up the main logic a bit more and add some documentation there, I can take another look. :)

Very good work, looking forward to having this in HLS!

[MangoIV]

another small round :)

[fendor]

Very nice, this looks like it is making great progress!

I reviewed the plugin, I have mostly comments regarding readability and suggestions for improvements that hopefully improve the maintainability in the long run.

Some things are nitpicks, and you should feel free to ignore them.

I think we need one Note that outlines what the implementation strategy of the case split plugin is (e.g., reads the structured error message, etc...) so that it is easier to tell what the individual steps for case splitting are.

[fendor]

There is inspectCodeAction which might be what you are looking for here, should also be helpful to get rid of the _CACodeAction

[fendor]

I am not a huge fan of the title, as it exposes implementation details... But I don't have a better idea for now

[Aster89]

Do I understand that you're alluding to the fact I mention -fmax-uncovered-patterns? I'd argue that this is rightfully documenting a current limitation of the plugin, rather than exposing an implementation detail.

[fendor]

If you case split on the non exhausted patterns, how soon would you like to know its current limitations?
Like this, it is the second thing you learn, and you learn that there is a flag called -fmax-uncovered-patterns. As a user, what are you supposed to do about this?

I just don't think we need to say in the code action title, why we are only completing -fmax-uncovered-patterns cases, as it doesn't mean anything to beginners, and is maybe not even observable in many applications.

[Aster89]

If you case split on the non exhausted patterns, how soon would you like to know its current limitations?

I would say "soon", personally.

As a user, what are you supposed to do about this?

"Supposed to", nothing, but at least I'm given pointers to look for if I care about it.

I just don't think we need to say in the code action title, why we are

Well, technically I'm not telling why. I'm just saying what's the number of completions they get, to avoid surprising them when they don't see them all.

But I guess this is already in the land of preference/opinions? 😄

[fendor]

Yes, my opinion is, mentioning the option (not even the number of patterns you are going to match) doesn't add anything worthwhile to the average users. But I am not going to fight over it.

@MangoIV what do you think?

[MangoIV]

I don't think it's crucial information in general here but I see an issue in users reporting bugs upstream because they think this is not a known caveat. I don't know where else to put the information though except perhaps in the documentation / on the website of HLS itself?

[fendor]

The documentation on the website feels like the appropriate place. (Should be added regardless)

I expect users are going to report it either way, as it doesn't really mean anything to them.

[Aster89]

The documentation on the website feels like the appropriate place.

Which website?

Are you by any chance referring to the bullet list here?

(Should be added regardless)

Before GSoC submission deadline, or can I do it afterwards?

---

Since

But I am not going to fight over it.

and

I see an issue in users reporting bugs upstream because they think this is not a known caveat

I'll keep the message as is. And take note (of changing this String) in the stretch goals.

[fendor]

If I understand correctly, this is doing the heavy lifting of actually pushing the new matches to the AST.

Afaict, there are four ways we support grafting:

1. LambdaCase with braces
2. LambdaCase without braces
3. case with braces
4. case without braces

I am not sure merging these cases altogether is the best strategy.
What would the code look like if we differentiated between these cases explicitly? More duplication, but maybe also simpler?