Make ExtractExplicitConstructorInvocationArguments templates context-free#1140
Merged
Conversation
…free The two JavaTemplate uses were context-sensitive, which reconstructs and reparses the enclosing class and method on every application. Neither needs it: contextSensitive() only reconstructs surrounding local scope into the parse stub, not type resolution. Every type these templates declare is the type of an existing super(..)/this(..) argument, so it is already present in the unit and resolves via the shared type cache, and the spliced result is re-attributed against the real cursor afterward. Also bail on the cheapest decisive check (no method-invocation/object-creation argument) before any variable-name generation, scope scanning, or templating. Add regression tests covering a source-path parameter type and a widening source-path supertype, asserting the rewritten reference keeps its variable binding and the extracted declaration keeps a resolved type.
timtebeek
approved these changes
Jun 23, 2026
github-project-automation
Bot
moved this from In Progress
to Ready to Review
in OpenRewrite
timtebeek
reviewed
Jun 23, 2026
timtebeek
reviewed
Jun 23, 2026
- Replace the `anyComplex` flag + loop + `if` with a single `noneMatch` guard. - Use the static `JavaTemplate.apply(..)` for the argument-list rewrite.
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
2 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.
Motivation
ExtractExplicitConstructorInvocationArguments(JEP 513) applied both of itsJavaTemplates withcontextSensitive(). Context-sensitive templating reconstructs and reparses the enclosing class and method on every application, which is the dominant cost when the recipe actually fires. Neither template needs it:contextSensitive()only reconstructs the surrounding local scope (leading variable declarations, method parameters) into the parse stub — it does not govern type resolution. Every type these templates declare is the type of an existingsuper(..)/this(..)argument, so it is already present in the unit, resolves via the sharedJavaTypeCache, and the spliced result is re-attributed against the real cursor afterward. DroppingcontextSensitive()therefore produces byte-identical, fully type-attributed output while skipping the enclosing-context reparse.Summary
contextSensitive()from both templates (the local-variable declarations and the argument-list rewrite).fieldType) and the extracted declaration keeps a resolved fully-qualified type (notUnknown).Test plan
ExtractExplicitConstructorInvocationArgumentsTestpasses (all existing cases plus the two new source-path regression tests).afterRecipe: thesuper(..)reference has a non-null type andfieldType, and the extracted declaration's type resolves to a real FQ type.