Update to JavaParser 3.28.1#197
Merged
mernst merged 54 commits intoMay 11, 2026
Merged
Conversation
Fix: issue 4949 Parsing issue in switch with yield with Java 25 parser configuration
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…ation This PR extracts and centralizes indentation-related logic from the lexical preservation system into dedicated, well-tested utility classes. This is the first step in a larger effort to improve the maintainability and readability of the LexicalPreservingPrinter codebase. Changes 1. New Classes Created IndentationConstants Centralizes indentation-related constants Eliminates duplication of STANDARD_INDENTATION_SIZE across multiple classes Impact: Difference and other classes now reference a single source of truth IndentationContext Encapsulates stateful indentation management Provides clean API for increase/decrease/get operations Replaces ad-hoc indentation list manipulation in LexicalPreservingPrinter.interpret() IndentationCalculator Provides stateless utility methods for indentation calculations Core methods: computeFromPrecedingElements(): Extracts indentation from preceding tokens extractIndentationFromTokens(): Gets leading whitespace from token list createIndentationBlock(): Creates standard indentation block analyzeEnforcingContext(): Analyzes whitespace for enforcement (replaces logic in Difference) enforceIndentation(): Applies indentation enforcement removeExcessIndentation(): Removes excess whitespace
…gin to v3.1.0 (javaparser#4953) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…n to v2.21.0 (javaparser#4954) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…migrate core classes
…migrate core classes - Create TextElementSequence interface with specialized search/filtering operations (findFirst, findLast, takeWhile, anyMatch, allMatch, noneMatch) - Implement TextElementList with optimized index-based operations and method chaining support - Introduce TextElementIterator for bidirectional traversal with currentIndex() tracking - Replace IndexTrackingIterator<T> with generic implementation, removing ArrayIterator - Migrate Difference.java: refactor processIndentation(), posOfNextComment(), removeElements() (-96 lines, ~8% reduction) - Migrate NodeText.java to use TextElementList internally (code simplification, -16% logic, -25% complexity) - Add factory method TextElementList.of(List) for fluent API chaining - Distinguish toList() (unmodifiable) from toMutableList() (mutable) for clear intent - Fix indentation preservation bugs and iterator edge cases
Before regenerating code, the system now identifies which part of the tree actually owns the formatting information for the changed element. If this owner differs from the immediate parent, it regenerates the owner instead. This ensures changes are properly reflected in the output.
Adds 71+ unit tests covering all 58 rules identified in Difference.apply(): - 22 REMOVED rules (node/token removal, indentation cleanup) - 21 KEPT rules (AST/token synchronization, type preservation) - 13 ADDED rules (insertion with indentation management) - 7 LEFTOVER rules (end-of-processing edge cases) Tests organized in 7 classes inheriting AbstractLexicalPreservingTest. Some tests disabled due to known indentation bugs (e.g., adding statement at beginning of block). Serves as specification for future refactoring.
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…avaparser#4959) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…avaparser#4962) * Resolve parsing issue for module-info classes with multiple exports * Fix formatting
…r-plugin to v3.15.0 (javaparser#4964) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…53.1 (javaparser#4966) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This commit adds full support for resolving the type of Java switch expressions in the type solver. Prior to this, the solver either couldn’t compute a meaningful type for a switch expression or didn’t implement the logic at all. This change implements the Java Language Specification rules for switch expression type inference, by:
Visiting SwitchExpr AST nodes during type resolution and collecting the types of all its result expressions.
Handling the various forms of cases:
Expression cases (case L -> value) by extracting the expression’s type.
Block cases (case L -> { … yield value; }) by searching for yield inside and using that type.
Colon-style cases with yield inside conventional case blocks.
Throw-only cases which have no result value (these contribute null for type resolution).
Filtering out nulls (cases with no yielded value) and combining the remaining types:
If all result expressions are the same type, that becomes the switch expression’s type.
If all are Boolean or unboxable to Boolean, the switch is typed as boolean.
If all are numeric types, it performs numeric promotion (like Java’s binary numeric promotion).
Otherwise, it computes the least upper bound (common supertype) of reference types.
Throwing an error only if the result set is unexpectedly empty (though earlier validation should prevent this).
Also this commit introduces additional semantic validation logic and tests to ensure switch expressions are semantically valid. In Java, a switch expression must produce a value on every possible path, because it’s used as an expression (e.g., in assignments or returns). This commit:
Adds a validator that inspects a SwitchExpr and checks whether at least one branch actually produces a returnable expression (via yield or arrow syntax).
Detects switch expressions where all entries throw exceptions or otherwise never produce a result value. Such constructs are invalid as a switch expression because they don’t compute a value.
Adds unit tests (e.g., SwitchExprTest) to ensure these invalid cases are flagged correctly by the symbol solver or validation framework.
Ensures the solver rejects or reports errors for switch expressions that have no result expressions, rather than silently attempting to compute a type or returning an incorrect result. (Internally, the type extraction logic assumes that validation runs first, so it can safely expect at least one value-producing branch).
…ncy-plugin to v3.10.0 (javaparser#4970) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…er#4972) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…e-plugin to v3.5.5 (javaparser#4973) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…#4978) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…54.0 (javaparser#4980) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…es-plugin to v3.5.0 (javaparser#4981) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…er#4990) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
javaparser#5000) * Fix: issue javaparser#4974 How to detect array.length ValueDeclaration * The test (Issue2374Test) has been disabled because it fails on Ubuntu systems regardless of the Java version, but works on Windows and macOS systems. Further research will be needed to understand this finding.
…er#4993) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…er#5002) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…avaparser#5003) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…55.1 (javaparser#5004) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…avaparser#5006) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Per JLS 14.30, the component list in a RecordPattern is optional:
RecordPattern: ReferenceType ( [ComponentPatternList] )
The PatternList() production in java.jj required at least one
component, causing a parse error on valid patterns like Point()
or case Pair() in switch expressions.
Wrap the content of PatternList() in an optional block [ ... ]
so that an empty parenthesised list produces an empty NodeList
rather than a parse failure. Also update the Javadoc comment to
match the JLS definition.
Add emptyRecordPatternListShouldWork() test to PatternExprTest
to cover the zero-component case.
…odecov-action-6.x chore(deps): update codecov/codecov-action action to v6
|
Important Review skippedToo many files! This PR contains 300 files, which is 150 over the limit of 150. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (300)
You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
mernst
force-pushed
the
updating-javaparser-parent-3.28.1
branch
from
6932a13 to
0554e7f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.