typetools / typetools/checker-framework
Model possible `MatchException`s in control-flow graphs
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 440
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 134
Description
In various cases, recent Java language constructs like switch expressions may throw a MatchException even when the matching is statically checked to be exhaustive. E.g., this can happen due to separate compilation, where more cases exist in an enum at runtime than were visible at compile time; see the MatchException javadoc for more examples. Currently I don't believe these MatchException cases are modeled by the control-flow graphs generated by the Checker Framework. E.g., I don't see any MatchException case for this test, but you can see the MatchException cases get generated in the bytecodes for a simplified version.
At some point, it would be good to handle at least some cases where MatchExceptions can be thrown, for soundness.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with dataflow/tests/java22/unnamed-pattern/Test.java and compare its generated control-flow graph with the linked bytecode example. Trace how Java switch expressions and exhaustive matching are represented, then identify which MatchException cases can be modeled soundly. Done means supported cases appear in the CFG with regression coverage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100