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 JEP-440: Pattern matching for Records #4925

Merged
merged 16 commits into from
Jan 23, 2025
Merged

Conversation

Laurens-W
Copy link
Contributor

@Laurens-W Laurens-W commented Jan 20, 2025

What's changed?

Add full blown support for record pattern matching

Anyone you would like to review specifically?

Any additional context

https://openjdk.org/jeps/440

Checklist

  • I've added unit tests to cover both positive and negative cases
  • I've read and applied the recipe conventions and best practices
  • I've used the IntelliJ IDEA auto-formatter on affected files

@Laurens-W Laurens-W marked this pull request as ready for review January 20, 2025 16:27
@timtebeek timtebeek changed the title Full blown support for record pattern matching Support JEP-440: Pattern matching for Records Jan 20, 2025
private @Nullable J getNodePattern(@Nullable PatternTree pattern, JavaType type) {
if (pattern instanceof JCBindingPattern b) {
return new J.Identifier(randomId(), sourceBefore(b.getVariable().getName().toString()), Markers.EMPTY, emptyList(), b.getVariable().getName().toString(),
type, typeMapping.variableType(b.var.sym));
} else if (pattern instanceof DeconstructionPatternTree r) {
return visitDeconstructionPattern(r, whitespace());
} else {
if (pattern == null) {
return null;
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to keep the J.Unknown code path below? I'd kind of expected that to be dropped, or are there still paths that hit that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's currently 3 types of patterns, binding which is mapped to variable, deconstruction which currently only implements records and any which is a preview feature. So in theory we no longer need it for Java 21, but it could help us with Java 24/25 print idempotency

Copy link
Contributor

@knutwannheden knutwannheden left a comment

Choose a reason for hiding this comment

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

I want to check a few more things, but here is a first set of comments.

Copy link
Contributor

@knutwannheden knutwannheden left a comment

Choose a reason for hiding this comment

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

I added a few small comments. After merging this it would further be cool if we could also look into updating the formatter to support adding spaces before or after parentheses as configured in the style.

@@ -61,6 +61,7 @@ public enum Location {
IF_ELSE(Space.Location.IF_ELSE_SUFFIX),
IF_THEN(Space.Location.IF_THEN_SUFFIX),
IMPLEMENTS(Space.Location.IMPLEMENTS_SUFFIX),
PATTERN(Space.Location.PATTERN),
Copy link
Contributor

Choose a reason for hiding this comment

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

This should reference a different Space.Location. These locations are frequently used by the formatting visitors, so it makes sense to bind unique locations to the various padding elements. A _SUFFIX suffix is the pattern here. But we should actually consider renaming the PATTERN locations to DECONSTRUCTION_PATTERN as that would match how we typically name these things.

@Laurens-W Laurens-W merged commit c7a28a6 into main Jan 23, 2025
2 checks passed
@Laurens-W Laurens-W deleted the implement-jep-440 branch January 23, 2025 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants