Defer optics generation of invalid classes to later ksp rounds

[johnmave126]

Currently the optics ksp plugin always return emptyList() in every round of ksp processing:

arrow/arrow-libs/optics/arrow-optics-ksp-plugin/src/main/kotlin/arrow/optics/plugin/OpticsProcessor.kt

Lines 31 to 34 in b490817

	// the docs say that [process] should return
	// "deferred symbols that the processor can't process"
	// and in theory we have none
	return emptyList()

However, this becomes problematic when:

1. The project is using other processor(s) other than arrow-optics-ksp-plugin
2. Some other processor generates type A in a single round, and returns emptyList() in its process()
3. Non-generated code with @optics annotation depends on A:

   @optics
   data class B(val a: A)

4. ksp processing terminates in a single round, since all the processors has no deferred symbol.
5. When optics generates code for B, A is unresolvable, resulting in <ERROR TYPE: A> in the generated code.

Kotlin can actually check whether an annotated class is fully resolvable by calling .validate(), and invalid classes should be deferred to later rounds.

This PR checks and splits the annotated symbols into symbols that can be immediately codegen-ed and symbols that should be deferred, enabling better collaboration with other processors.

[serras]

Thanks for this useful addition :)

[johnmave126]

Alright, fixed the build check error, turns out I need to explicitly import com.google.devtools.ksp.validate, which was weirdly not a problem on my machine when arrow lives as a subproject of mine, but became a problem when it is standalone.

[FWest98]

This change is causing issues when the to-be-generated optics are used in the class definition itself, for example in its functions. When this is the case, the class will never be valid (since its validity depends on the optics to be generated), and thus will be deferred indefinitely. At the end, KSP will report:

w: [ksp] Unable to process:arrow.optics.plugin.OpticsProcessor:   Foo;Bar

[johnmave126]

Emmm, that definitely could happen. I am not sure what the most "correct" way to handle the defer is, but let me propose a "reasonable" quick-n-dirty heuristic: if the deferred symbol list is stale for 3 (an arbitrary number I think appropriate) rounds, arrow will then generate the optics no matter what.

[FWest98]

Here is a minimal reproducible example. The key thing is that the type of the function can only be resolved once the lens exists - this causes a stalemate. When I manually specify the function type, the optics can be generated and it all works fine.

@optics
data class UsingLens(val field: String) {
  fun getLens() = UsingLens.field
  companion object
}