More systematic completion for all kinds of case labels

[stephan-herrmann]

#1312 tries to fix a regression in completion after case, which was caused by recent work concerning Java 17.

Looking at the code changes, however, I don't get a clear picture of the various styles of case and what kinds of completions should be proposed for each.

Hence I would like to see this area captured more systematically, before we continue tweaking issues back and forth.

[stephan-herrmann]

Scheduling for 4.30 M3, at which time we need to decide if a systematic approach is ready for prime time, or alternatively merge the regression fix (#1312) now, and continue after the release.

[stephan-herrmann]

@gayanper do you want to join me in this effort? Perhaps @mpalat could help identifying relevant use cases?

[gayanper]

Linking #2260

[stephan-herrmann]

I see the following list of questions:

1. what are the different kinds of switches that determine which case constructs are legal?
2. how can we discriminate those kinds in possibly incomplete code?
3. then per each of these kinds: what are the things that can possibly follow the case keyword?
4. can/should we propose more than just one token?

I suggest we address these questions top to bottom, and at least for those first questions @mpalat is our expert, right? :)

[gayanper]

I see the following list of questions:

1. what are the different kinds of switches that determine which case constructs are legal?
2. how can we discriminate those kinds in possibly incomplete code?
3. then per each of these kinds: what are the things that can possibly follow the case keyword?
4. can/should we propose more than just one token?

I suggest we address these questions top to bottom, and at least for those first questions @mpalat is our expert, right? :)

If I try to answer,

1. If the switch variable has a primitive type binding including String, we should try to suggest matching constants for that type in case. But at the same time the user might need to have use a qualification, which should also allow to do a SingleType completion as well. So one could write Constants.NAME as a case construct using code completions which complete both the qualifier, and then the constant.

2. Today the completion is handled at completionOnSingleNameReference when trying to complete on a case

3. So here we could use something similar:

• If the type is primitive or java.lang.String then we follow the logic above 1
• If the type is a Enum, we provide enum literals which does happens today
• If the type is a Class (not java.lang.Object) or an Interface, we could just let the Type completions cover listing all types or we could only provide the subtypes by being bit more smart. But trying to find subtypes might come with a cost based on the type hierarchy size.

4. What do you mean ?

[gayanper]

I think given the all pattern matching features, such as extracting values out of records as part of pattern matching, i think if would me better to handle all such switch case related logic in a separate handler rather than the current one. So that will give us the opportunity add more better completions for java record pattern recognition scenarios

[gayanper]

https://inside.java/2023/11/06/sip087/

[gayanper]

@stephan-herrmann @mpalat #2265 this is a WIP solution I started on and updated based on above points from @stephan-herrmann.

Let me know what you think ? May be we can start building on this or any other solution you think will be better and scalable.

[stephan-herrmann]

Thanks, @gayanper for your reply.

I'm a little confused, though, as the answers don't seem to exactly match to my questions :)

1. If the switch variable has a primitive type binding including String, we should try to suggest matching constants for that type in case. But at the same time the user might need to have use a qualification, which should also allow to do a SingleType completion as well. So one could write Constants.NAME as a case construct using code completions which complete both the qualifier, and then the constant.

This seems to answer (3) for one specific kind of switches.

2. Today the completion is handled at completionOnSingleNameReference when trying to complete on a case

I didn't yet ask about any location in code :)

This comes close to answering (1) :

3. So here we could use something similar:

• If the type is primitive or java.lang.String ...
• If the type is a Enum ...
• If the type is a Class (not java.lang.Object) or an Interface ...

4. What do you mean ?

Two ideas (there might be more opportunities):

• take the example of an enum switch: instead of case MyConstant, should we propose case MyConstant: or case MyConstant ->?
• when a record pattern is legal, should we propose the full pattern instead of just the record name?

As I recomment to include @mpalat in this discussion, we may have to wait a few days. his avatar says "On vacation - Back on March 7th" - I have an inkling that he may not be back before April 7th.

https://inside.java/2023/11/06/sip087/

Might as well use a source closer to home: https://manojnp.medium.com/record-patterns-building-on-records-d9370b19165f 😄 or https://www.youtube.com/watch?v=C1lAfolOJ6c for that matter (would have loved to introduce you to each other during that event).

[stephan-herrmann]

I think given the all pattern matching features, such as extracting values out of records as part of pattern matching, i think if would me better to handle all such switch case related logic in a separate handler rather than the current one. So that will give us the opportunity add more better completions for java record pattern recognition scenarios

If by "separate handler" you mean a new method inside CompletionEngine, then for sure this makes much sense.