Support defining extra compiler arguments in the tool chain.

[jongerrish]

Supports the following attributes in the toolchain:-

extra_copts - supports passing extra arguments to kotlinc
jvm_opts - supports passing extra arguments to the Java compiler + KAPT

[restingbull]

I'm really not in favor of arbitrary opts. I realize this is a carryover from java, but I've seen how much of a mess those can be. From a maintainer standpoint, it's a fair bit of increased overhead around triage (issues associated with combination of flags and internal setup) and as well as keeping a parsing structure in one piece. The current implementation would allow all sorts of difficult to diagnose issues including adding arbitrary compiler plugins without any kind of ordering (just add a jar and a library), random "friend" associations, and so forth.

Considering the -X options are subject to change, I'd prefer to see a more structured and validated approach. Additionally, a lot of the performance gains that Gradle realizes come from running the compiler via the embeddable api. Arbitrary fields increase the maintenance burden associated with changing the underlying implementation.

I'd much prefer to see a structured options around the actual for compiler options.

[jongerrish]

I'm really not in favor of arbitrary opts. I realize this is a carryover from java, but I've seen how much of a mess those can be. From a maintainer standpoint, it's a fair bit of increased overhead around triage (issues associated with combination of flags and internal setup) and as well as keeping a parsing structure in one piece. The current implementation would allow all sorts of difficult to diagnose issues including adding arbitrary compiler plugins without any kind of ordering (just add a jar and a library), random "friend" associations, and so forth.

Considering the -X options are subject to change, I'd prefer to see a more structured and validated approach. Additionally, a lot of the performance gains that Gradle realizes come from running the compiler via the embeddable api. Arbitrary fields increase the maintenance burden associated with changing the underlying implementation.

I'd much prefer to see a structured options around the actual for compiler options.

Thats a fair point.

We're currently passing the following values:-

extra_copts = [
    "-nowarn"
],
jvm_opts = [
    "-Xlint:none",
    "-XDsuppressNotes",
],

How would you feel about adding a boolean warnings flag to control all of these?

[restingbull]

#383

[restingbull]

So, um, what is the -XepDisableAllChecks? flag for the error prone processor?

[jongerrish]

@restingbull has implemented a better solution, closing this PR