Add FIR-to-IR conversion phase to KotlinParser#6793
Merged
timtebeek merged 2 commits intotimtebeek/gradle-kts-templatesfrom Feb 23, 2026
Merged
Add FIR-to-IR conversion phase to KotlinParser#6793timtebeek merged 2 commits intotimtebeek/gradle-kts-templatesfrom
timtebeek merged 2 commits intotimtebeek/gradle-kts-templatesfrom
Conversation
After FIR analysis, run JvmFir2IrPipelinePhase to populate the irFile field on KotlinSource, enabling future use of IR-based type mapping for improved Kotlin parsing.
9 tasks
timtebeek
added a commit
that referenced
this pull request
Feb 23, 2026
* Add Kotlin script template support for Gradle KTS parsing Leverage K2 FIR compiler extensions to configure implicit receivers and default imports for build.gradle.kts and settings.gradle.kts files. This improves type information for Gradle DSL methods, enabling better recipe matching and method resolution. Implements FirScriptConfiguratorExtension and FirScriptResolutionConfigurationExtension to provide Project/Settings as implicit receivers and Gradle API packages as default imports. * Unify Gradle recipe visitors for Groovy and Kotlin DSL Now that Kotlin script templates provide type information for .gradle.kts files, merge separate GroovyVisitor/KotlinVisitor pairs into single JavaVisitor implementations where possible. - UpdateJavaCompatibility: replace dual GroovyIsoVisitor + KotlinIsoVisitor with a single JavaVisitor that handles both DSLs - UpgradeTransitiveDependencyVersion: replace inline GroovyIsoVisitor and KotlinIsoVisitor literal visitors with shared ChangeStringLiteral, and simplify the constraints precondition check * Fix FindRepository matching for KTS with type information Replace MethodMatcher-based pluginManagement/buildscript detection with simple name matching, since the synthetic class names (RewriteSettings, RewriteGradleProject) don't match the real types resolved by the K2 compiler (org.gradle.api.initialization.Settings, org.gradle.api.Project). * Add FIR-to-IR conversion phase to KotlinParser (#6793) After FIR analysis, run JvmFir2IrPipelinePhase to populate the irFile field on KotlinSource, enabling future use of IR-based type mapping for improved Kotlin parsing. * Unify more Gradle recipe visitors for Groovy and Kotlin DSL Convert ChangeDependencyGroupId and ChangeDependencyArtifactId from GroovyIsoVisitor to JavaIsoVisitor so they work with both Groovy and Kotlin DSL build files. * Use real Gradle API types in MethodMatcher patterns for KTS support Update MethodMatcher patterns from synthetic Groovy template types (RewriteGradleProject, RewriteSettings, PluginSpec, Plugin) to real Gradle API types (org.gradle.api.Project, Settings, PluginDependenciesSpec, PluginDependencySpec) with matchOverrides=true, enabling matching for both Groovy DSL and Kotlin DSL scripts. * Increase test heap to 2g for rewrite-gradle The K2 compiler used for KTS parsing loads many JDK modules and consumes significant memory. The default test worker heap is insufficient, causing OutOfMemoryError on CI. * Use regular imports in Plugin.groovy * Restore `isKotlin` conditions in RemovePluginVisitor due to missing types * Verify `ChangeDependencyArtifactId` works with .kts * Verify `ChangeDependencyGroupId` works with .kts * Verify `DependencyInsight` works with .kts * Verify `DependencyConstraintToRule` works with .kts * Merge Groovy/Kotlin visitors into single JavaIsoVisitor in `UpdateJavaCompatibility`
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
1 participant
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.
After FIR analysis completes in KotlinParser.parse(), run JvmFir2IrPipelinePhase to convert FIR to IR
Populates the existing irFile field on KotlinSource, enabling future use of KotlinIrTypeMapping for improved Kotlin type resolution
FIR-to-IR conversion is best-effort: if it fails (e.g. for certain annotation expressions with KClass.java), parsing continues with just FIR data
The FIR-to-IR conversion populates the
irFilefield onKotlinSource, which enables switching from the FIR-basedKotlinTypeMappingto the IR-basedKotlinIrTypeMappingfor type resolution. The benefits:Better type information. IR (Intermediate Representation) is a lower-level, more fully resolved representation than FIR. After FIR-to-IR conversion, types are fully desugared — type aliases are expanded, implicit conversions are made explicit, and synthetic members (like
copy()on data classes) are materialized. This meansKotlinIrTypeMappingcan produce more accurateJavaTyperesults than the FIR-based mapping.Simpler type mapping code. The existing
KotlinTypeMapping.kt(FIR-based) is ~1400 lines and handles many FIR-specific complexities — Java interop types (FirJavaTypeRef,BinaryJavaClass), symbol resolution throughFirSession, and various FIR expression forms. The IR-basedKotlinIrTypeMapping.ktis ~790 lines because IR is a more uniform representation — there's oneIrClassinstead of multiple FIR class variants, oneIrFunctionhierarchy instead of scattered FIR function types.Alignment with the Kotlin compiler pipeline. The Kotlin compiler itself uses FIR → IR → bytecode. By running the same FIR-to-IR phase, OpenRewrite's parser sees the same resolved types that the compiler would use for code generation. This reduces the chance of type mismatches between what OpenRewrite sees and what the compiler produces.
Enables future improvements. With IR available, features like resolving operator overloads, understanding delegation patterns, and mapping extension functions become more straightforward since these are all lowered to explicit IR constructs.