Seems 1 9 0 Beta introduces a bug with applying sourceset la

Question

Seems 1 9 0 Beta introduces a bug with applying sourceset language settings to compiler options 1 9 Beta vs 1 8 21

efemoney · Answer

The problem with applying free args as `ListProperty convention ` is that once user sets their own value on the property including using `ListProperty add addAll` convention is cleared ignored so also language settings are cleared for a user that configures `compilerOptions` in addition to `enableLanguageFeature `

efemoney · Answer

Sorry not at personal computer cannot create an issue so I m reporting here instead pray skin tone 5

efemoney · Answer

Cc < tapchicoma> pray skin tone 5

efemoney · Answer

Workaround for now is to define all language features not in sourceset language settings but in freeCompilerArgs

efemoney · Answer

Also probably should report to Gradle ListProperty add addAll should maybe work in addition to convention shrug skin tone 5

hfhbd · Answer

This is the default behavior of Gradle convention is the default value if the user does not set the value explicitly

hfhbd · Answer

If the user calls value or just set the convention value is overwritten

tapchicoma · Answer

As far as I can remember this was intentional change

tapchicoma · Answer

to support project level compiler options DSL

tapchicoma · Answer

in 1 9 20 `languageSettings` is planned to be deprecated

tapchicoma · Answer

though create an issue with your use case and we will investigate if it could be fixed somehow or close it `As Designed` sweat smile

Javier · Answer

which will be the alternative to language settings < tapchicoma>

efemoney · Answer

gt This is the default behavior of Gradle convention is the default value if the user does not set the value explicitly I know this What I meant is specifically for `add` amp `addAll` it just seems counter intuitive that they arent additive to the convention gt this was intentional change Ah okay if this was intended I m 100 percent with that Maybe document it so others are not as surprised I can create an issue but only when I m back from vacation next weekend gt create an issue with your use case Lol my use case is I m too lazy to type ` XXLanguage + ` sweat smile plus I think the language settings one is less error prone as it validates that the string indeed maps to a `LanguageFeature` but its not an issue I will move back to defining `freeCompilerArgs` for language features

tapchicoma · Answer

< Javier> plan is to add project level compiler options DSL for MPP as well via Should be something similar to but final DSL is yet to be finalized

tapchicoma · Answer

gt Lol my use case is I m too lazy to type ` XXLanguage + ` What kind of `XXLanguage` toggles are you enabling thinking face This thing should never be exposed in `languageSettings` as it is too Kotlin compiler internal crying cat face

tapchicoma · Answer

< efemoney> could you just paste here your build script snippet that stopped working

efemoney · Answer

I am using ContextReceivers amp DefinitelyNonNullableTypes I will past the script in a minute One reason I switched to languageSettings was <https youtrack jetbrains com issue KT 57521 MPP Compiler options declared in places other than languageSettings dont reach shared source sets|this issue> with multiplatform a while ago not sure if its fixed now

efemoney · Answer

Untitled

tapchicoma · Answer

I suppose issue you ve linked is not yet fixed though could be fixed via MPP project level compiler options DSL thinking face

efemoney · Answer

Yes I starred the new issue you shared I also think it would be great to have a central API that just works for all

tapchicoma · Answer

possibly could be something like this ```kotlin compilerOptions Common compiler options that will be used as a convention to options in Kotlin source sets ```

efemoney · Answer

Nice should get rid of most or all of direct kotlin task usage

tapchicoma · Answer

< efemoney> `DefinitelyNonNullableTypes` should be enabled by default since Kotlin 1 7 Why do you enable it explicitly thinking face

efemoney · Answer

Hm I think I missed it tbh The code predates 1 7 I tried it out when it was still in preview

tapchicoma · Answer

and context receivers has better ` Xcontext receivers` slightly smiling face

efemoney · Answer

Yeah I prefer the language variant because the normal one just does the same thing sweat smile

efemoney · Answer

This is in another project for instance theres even more language features I am trying out

tapchicoma · Answer

Generally our idea is that we should not advertise anywhere `LanguageFeature` but for user facing change we should have related ` X` argument

efemoney · Answer

Yup I know I am reaching into compiler but I need to try out these features sweat smile I regularly go through the enum to see which ones I can enable and test

tapchicoma · Answer

Generally we want to remove `freeCompilerArgs` from compiler options and leave it as separate task input which produce a warning on non empty value slightly smiling face But it is a distant change first we need to expose experimental compiler options in DSL sweat smile

efemoney · Answer

Yeah sounds like a great idea

efemoney · Answer

Woah I just noticed your post in < C0KLZSCHF|eap> I didnt know the project level options were ready I have switched my build to use them and remove kotlin task configuration One question since the point is to deprecate languageSettings in the future what would happen to the optIn api should I go back to free compiler args ` opt in= `

tapchicoma · Answer

`optIn` should available in compiler options since 1 9 0 `kotlin compilerOptions optIn add `

tapchicoma · Answer

also `progressive` was added to compiler options

efemoney · Answer

Amazing Didnt know about these thanks