Fulfill the new requirements for Kotlin User Projects

[dkhalanskyjb]

No description provided.

[osipxd]

Probably, should be used API compatible with isolated projects?

Suggested change

	when (val prop = project.rootProject.properties["kotlin_Werror_override"] as? String) {
	when (val prop = project.providers.gradleProperty("kotlin_Werror_override").orNull) {

[dkhalanskyjb]

Sorry, but I don't know what the difference is. rootProject.properties is already used throughout our build scripts, and I haven't heard of any issues because of that. Could provide/link to a clear explanation of the downsides of the existing approach?

[osipxd]

Sure!
Calling Project.properties is quite expensive because it collects not only properties from gradle.properties and CLI arguments, but also tasks and their fields, extensions, extras, conventions, etc (see gradle/gradle#25053)
getProperty and hasProperty are better, but they're not compatible with isolated projects because of the access to properties of other projects.

Since you're getting the property from the root project, it should be safe to use providers.gradleProperty which looks for Gradle properties in the root project. As a bonus, this API is compatible with isolated projects (which I hope will be stable someday) as there is no need in calling methods of the rootProject

[osipxd]

However, as soon as this syntax is used everywhere in this file, this change is indeed out of the scope of the current PR.

[woainikk]

@dkhalanskyjb can you please also like this?:
Implement a Gradle property for passing additional CLI options to the Kotlin compiler
(property naming is not critical but kotlin_additional_cli_options is suggested for consistency). And the passed kotlin_additional_cli_options should be applied as compiler options

[dkhalanskyjb]

@woainikk, are there examples (either of other libraries doing this or of this property being used)? What exactly is the content of the property? Is it a space-separated list of strings? A comma-separated list? Something else? Should the options go before or after the usual ones (if that's important)?

[woainikk]

@dkhalanskyjb values are space-separated (quoting values with spaces is not supported);
e.g.: -nowarn -Xwarning-level=CONTEXT_RECEIVERS_DEPRECATED:warning
The options should go after the usual ones

[woainikk]

@dkhalanskyjb Can you please also add logging to somewhere, to all applied compiler flags were printed to log?