chore(deps): update dependency dev.zacsweers.metro:dev.zacsweers.metro.gradle.plugin to v0.12.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
dev.zacsweers.metro:dev.zacsweers.metro.gradle.plugin	0.11.4 → 0.12.0

---

Release Notes

ZacSweers/metro (dev.zacsweers.metro:dev.zacsweers.metro.gradle.plugin)

v0.12.0

Compare Source

2026-03-24

New

[MEEP-2014] Implicit class (map) keys

MapKey.implicitClassKey is a new API to allow for class-based map keys to have their class parameters inferred on classes and @Binds declarations.

This means that instead of redeclaring the annotated class in the key, for example @ViewModelKey, you can now omit it and it will be inferred.

@&#8203;ViewModelKey // <-- implicitly HomeViewModel::class
@&#8203;ContributesIntoMap(AppScope::class)
class HomeViewModel : ViewModel()

For classes, the implicit type is the annotated class. For @Binds declarations, the receiver or single parameter are the implicit type.

You may still specify an explicit type. The compiler will warn you if you specify a redundant one. If you need to suppress this diagnostic temporarily to ease migration, you can add -Xwarning-level=MAP_KEY_REDUNDANT_IMPLICIT_CLASS_KEY:disabled to your compiler arguments.

The compiler will also error if you attempt to do this on @Provides declarations, as those cannot be inferred.

Metro's first-party class-based map keys (like @ClassKey, @ViewModelKey, etc.) now support this. Custom map keys can opt-in to this by setting MapKey.implicitClassKey to true. See its doc for more details.

@​MapKey(implicitClassKey = true)
annotation class ViewModelKey(val value: KClass<out ViewModel> = Nothing::class)

Misc

• [metrox-viewmodel] Add mingwX64 target.

Enhancements

• [FIR] Add diagnostic to ensure map key annotations support FUNCTION targets if they have a @Target annotation.
• [FIR] Improve annotation argument matching to only use fully resolved names or none at all. This helps avoid situations in the past with interop where an argument at the same index and type but different name could incorrectly be used.

Fixes

• [IR] Fix IllegalArgumentException thrown when there are multiple top-level functions with the same name but only one is annotated with @Inject.
• [IR] Only store a given binding container's own provider factories in metro metadata. This resolves a bug where we could end up duplicate-processing upstream providers in dynamic factories.
• [IR] Fix a severity conversion compat function call for Kotlin 2.3.20+.
• [IR] Ensure stable sort of output SuspiciousUnusedMultibinding locations.
• [IR] Don't skip dynamic keys inherited from parent graphs when working with dynamic graphs.
• [IR] Propagate @OptionalBinding annotations to generated static factory creators if present.
• [IR] Preserve nullability when remapping parameters with generic layers.
• [Runtime] IntoSet and IntoMap no longer have a Target of AnnotationTarget.CLASS

Changes

• The Metro compiler now requires JVM 21+. Note that the runtime JVM artifacts still target 11 unless otherwise documented.
• The Metro Gradle plugin now requires JVM 21+.
• The Metro Gradle plugin now requires Gradle 9+. Note that if you do not use Kotlin Gradle DSL, it may work on older versions but YMMV.
• The Metro Gradle plugin now targets Kotlin 2.2.
• @Assisted.value is formally deprecated now. See the docs on why in case you missed this! TL;DR, Metro matches by parameter names going forward.
• Metro's main branch now builds with Kotlin 2.3.20 but still targets Kotlin 2.2 for its runtime artifacts and supports 2.2.20 all to 2.4.0 dev builds in its compiler.
• Remove deprecated macosX64, tvosX64, and watchosX64 targets.
• Update Kotlin 2.4 compat support from 2.4.0-dev-539 to 2.4.0-dev-2124. This should support the upcoming IntelliJ 2026.1 release as well as the upcoming Kotlin 2.4.0-Beta1.
• Test IntelliJ 2026.1 RC.
• Update shaded Wire dependency to 6.1.0.

Contributors

Special thanks to the following contributors for contributing to this release!

• @​Asapha
• @​ChristianKatzmann
• @​grandstaish
• @​jonamireh
• @​kevinguitar
• @​svenjacobs
• @​vRallev

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[greptile-apps]

Greptile Summary

This Renovate-generated PR intends to update dev.zacsweers.metro:dev.zacsweers.metro.gradle.plugin to v0.12.0, but it has updated the wrong version field. The Versions.kt data class holds two separate Metro version strings: metro (runtime library) and metroPlugin (Gradle plugin). The PR only bumps metro (runtime) from 0.11.4 → 0.12.0, while metroPlugin — which is the field that actually controls the Gradle plugin version used in generated projects — remains at 0.10.2. This leaves the generated projects with a runtime and plugin that are two minor versions apart, which may lead to compilation or runtime issues.

Key changes and concerns:

• metro (runtime) bumped from 0.11.4 → 0.12.0 ✅ (possibly correct)
• metroPlugin (Gradle plugin dev.zacsweers.metro.gradle.plugin) still at 0.10.2 ❌ (should have been updated to 0.12.0 per the PR's stated intent)
• The v0.12.0 release notes include several breaking changes (Gradle 9+ required, JVM 21+ required for the compiler/plugin), so verifying that the metroPlugin update is intentionally deferred or needs to be part of this PR is important.

Confidence Score: 2/5

• The PR updates the wrong version field — the Gradle plugin version is not actually bumped as intended, leaving the runtime and plugin at mismatched versions.
• The single changed line updates metro (the runtime library) instead of metroPlugin (the Gradle plugin), which is what the PR claims to update. This mismatch between the runtime at 0.12.0 and the plugin at 0.10.2 is a meaningful correctness issue for generated project configurations.
• project-generator/src/main/kotlin/io/github/cdsap/projectgenerator/model/Versions.kt — the metroPlugin field on line 83 should also be updated to 0.12.0.

Important Files Changed

Filename	Overview
project-generator/src/main/kotlin/io/github/cdsap/projectgenerator/model/Versions.kt	The metro runtime version was bumped to 0.12.0, but metroPlugin (the actual Gradle plugin version, dev.zacsweers.metro.gradle.plugin) was left at 0.10.2. This mismatches the PR's stated intent and leaves the runtime and plugin at incompatible versions.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Versions.kt\n(Android data class)"] --> B["metro: String\n(runtime library)"]
    A --> C["metroPlugin: String\n(Gradle plugin)"]

    B -->|"version.ref = 'metro'"| D["libs.metro.runtime\ndev.zacsweers.metro:runtime"]
    C -->|"version.ref = 'metro-plugin'"| E["libs.metro.gradle.plugin\ndev.zacsweers.metro.gradle.plugin"]
    C -->|"version.ref = 'metro-plugin'"| F["libs.plugins.metro\nid = dev.zacsweers.metro"]

    subgraph PR_Change ["This PR's change"]
        B -->|"0.11.4 → 0.12.0 ✅"| G["Runtime updated"]
        C -->|"0.10.2 → still 0.10.2 ❌"| H["Plugin NOT updated\n(PR intended to update this)"]
    end

Loading

_{Reviews (1): Last reviewed commit: "chore(deps): update dependency dev.zacsw..." | Re-trigger Greptile}

[greptile-apps]

Wrong field updated — runtime and plugin versions now mismatched

The PR title claims to update dev.zacsweers.metro:dev.zacsweers.metro.gradle.plugin (the Gradle plugin) to 0.12.0. However, looking at how these fields are consumed in AndroidToml.kt:

• metro → version.ref = "metro" → used for the runtime library (dev.zacsweers.metro:runtime, line 279)
• metroPlugin → version.ref = "metro-plugin" → used for the Gradle plugin (dev.zacsweers.metro.gradle.plugin, line 296) and the plugin alias (line 312)

This PR updated metro (the runtime library) from 0.11.4 → 0.12.0, but left metroPlugin (the actual Gradle plugin) at 0.10.2. The Gradle plugin version was not updated, despite that being the stated intent of this Renovate PR. The runtime library and the Gradle plugin are now two major versions apart, which may cause compatibility issues in generated projects.

The correct change should also bump metroPlugin to 0.12.0:

Suggested change

	val metro: String = "0.12.0",
	val metroPlugin: String = "0.10.2",
	val metro: String = "0.12.0",
	val metroPlugin: String = "0.12.0",