add KAPT arguments to define_kt_toolchain

[mohamadk]

Adding KAPT arguments to define_kt_toolchain

By this, we can configure KAPT.

Build.bazel

load("@io_bazel_rules_kotlin//kotlin:core.bzl", "define_kt_toolchain", "kapt_options")

kapt_options(
    name = "kapt_options",
    correctErrorTypes = True,
)

define_kt_toolchain(
    name = "kotlin_toolchain",
    api_version = "1.6",
    experimental_multiplex_workers = True,
    experimental_report_unused_deps = "off",
    experimental_strict_kotlin_deps = "off",
    experimental_use_abi_jars = True,
    jvm_target = "11",
    kapt_args = "//:kapt_options",
    language_version = "1.6",
)

[arunkumar9t2]

Can we follow snake case i.e correct_error_types here to stay consistent with rest of the args?

[arunkumar9t2]

Notes:

All available options: https://kotlinlang.org/docs/kapt.html#using-in-cli

Kapt is in maintenance mode at the moment hence we could consider adding options statically as it is not expected to change much between versions. The structure outlined in this PR is similar to what is already done in Kotlin Gradle Plugin for example, the kapt {}

kapt {
   showProcessorStats = true
   correctErrorTypes = true
}

If this structure is accepted we could look into adding support for showProcessorStats as well via -Kapt-dump-processor-timings JetBrains/kotlin#4280

[nkoroste]

Sounds reasonable to me. Also we might want to bring in all the other defaults from Gradle as that the source of truth we should follow at this point.
cc @restingbull @Bencodes

[Bencodes]

We should just pass all the options in here like we do for Kotlinc/Javac/Ksp, otherwise we'd end up having to create new proto entries for every single kapt option that we want to support.

[restingbull]

I'm against adding these to the toolchain -- we want to move away from specific plugin arguments being embedded in the core infrastructure.

KSP has shown that the plugin ecosystem is robust enough to foster an entire new ecosystem of plugins on top of the old one.

It would be better to move KAPT (and KSP) into an extendable subsystem, as we've previously discussed.

[mohamadk]

It would be better to move KAPT (and KSP) into an extendable subsystem, as we've previously discussed.

@restingbull I'm not aware of the discussion care to elaborate more?

[pswaminathan]

@restingbull can you elaborate on the preferred direction? Would having something like cc_library.copts or java_library.javacopts be workable? Maybe something like kapt_copts/ksp_copts and passing them directly in the rules?