fix(deps): update ksp monorepo to v2.3.12

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
com.google.devtools.ksp (source)	2.3.11 → 2.3.12
com.google.devtools.ksp:symbol-processing-api (source)	2.3.11 → 2.3.12

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

google/ksp (com.google.devtools.ksp)

v2.3.12

Compare Source

What's Changed

Migrating Processors to Support Backing Fields

This release introduces support for explicit backing fields (#​2873), which may now be returned by Resolver.getSymbolsWithAnnotation. To prevent breaking existing processors, new language features require an explicit opt-in.

More generally, the KSP API now explicitly models backing fields for properties. The following is an exhaustive list of functions in KSP API where processor may observe the change after opting in:

• Resolver.getSymbolsWithAnnotation: The function now returns a KSBackingField if the given annotation targeted a field. Previously, if a field were targeted, the function would return a KSProperty.
• Resolver.effectiveJavaModifiers: The function returns fewer modifiers for a KSPropertyDeclaration if it has a backing field, since most of the JVM-specific annotations apply to the backing field. If you are interested in the JVM modifiers, you should call the function with the KSBackingField obtained from the property instead.

Additionally, KSP now models Java fields as properties that always have backing fields. Some of the modifiers now apply to the backing field instead.

Processors adapting to new features must opt in via both of the following steps simultaneously (failing to do both may lead to undefined behavior):

1. The processor should call the registerProcessorForNewFeatures function in SymbolProcessorEnvironment immediately when created (and only once). Example: AbstractTestProcessor.kt#L30
2. All implementations of KSVisitor should move to KSVisitorNext. If their processor code does not directly implement the interface but instead extends one of the KSP-provided visitors (such as KSTopDownVisitor), they should instead extend KSTopDownVisitor(enableNewFeatures = true) and override visitBackingField depending on their code and needs.

Let us know if you run into unexpected behavior!

Bug Fixes

• Fix Resolver.getDeclarationsFromPackage returning incomplete declarations from KLibs in Kotlin Multiplatform (#​2396)
• Fix KSP CLI process hanging indefinitely when a processor throws an unhandled exception (#​3120)
• Fix implicit task dependency error between KSP and Android Lint in Android KMP (#​3128)
• Fix NullPointerException by registering PluginProblemReporter as an application service (#​3140)
• Do not mark companion objects as JAVA_STATIC in Resolver.effectiveJavaModifiers (#​3125)
• Fix JAVA_STATIC modifier resolution for @​JvmStatic members in Resolver.effectiveJavaModifiers (#​3124)
• Update minimum supported Android Gradle Plugin (AGP) version to 8.12.0 (#​3149)

New Contributors

Thanks to @​KlyneChrysler, @​budindepunk, and everyone who reported bugs and participated in discussions!

Full Changelog: google/ksp@2.3.11...2.3.12

---

Configuration

📅 Schedule: (UTC)

• 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 these updates again.

---

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

---

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