https://kotlinlang.org logo
Join Slack
Powered by
Seems 1.9.0-Beta introduces a bug with applying so...
# eap
e
Seems 1.9.0-Beta introduces a bug with applying sourceset language settings to compiler options. 1.9-Beta vs 1.8.21.
Sorry not at personal computer, cannot create an issue so I’m reporting here instead 🙏🏾
Cc @tapchicoma 🙏🏾
Workaround for now is to define all language features, not in sourceset language settings but in freeCompilerArgs
Also probably should report to Gradle, ListProperty.add/addAll should maybe work in addition to convention? 🤷🏾
h
This is the default behavior of Gradle. convention is the default value, if the user does not set the value explicitly.
If the user calls value or just set, the convention value is overwritten.
t
As far as I can remember - this was intentional change
to support project level compiler options DSL
in 1.9.20 
languageSettings
is planned to be deprecated
though create an issue with your use-case and we will investigate if it could be fixed somehow or close it 
As Designed
😅
j
which will be the alternative to language settings @tapchicoma?
e
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
& 
addAll
, it just seems counter intuitive that they arent additive to the convention
this was intentional change
Ah okay if this was intended I’m 💯 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.
create an issue with your use-case
Lol my use case is I’m too lazy to type 
"-XXLanguage:+"
😅 (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.
t
@Javier plan is to add project level compiler options DSL for MPP as well via this issue. Should be something similar to this but final DSL is yet to be finalized.
Lol my use case is I’m too lazy to type 
"-XXLanguage:+"
What kind of 
XXLanguage
toggles are you enabling? 🤔 This thing should never be exposed in 
languageSettings
as it is too Kotlin compiler internal 😿
@efemoney could you just paste here your build script snippet that stopped working?
e
I am using ContextReceivers & DefinitelyNonNullableTypes. I will past the script in a minute. One reason I switched to languageSettings was this issue with multiplatform a while ago (not sure if its fixed now)
Untitled
Untitled
t
I suppose issue you've linked is not yet fixed, though could be fixed via MPP project level compiler options DSL 🤔
e
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!
t
possibly could be something like this:
Copy code
kotlin {
    compilerOptions  { // Common compiler options that will be used as a convention to options in Kotlin source sets }
}
e
Nice. should get rid of most or all of direct kotlin task usage!
t
@efemoney 
DefinitelyNonNullableTypes
should be enabled by default since Kotlin 1.7. Why do you enable it explicitly? 🤔
e
Hm, I think I missed it tbh. The code predates 1.7, I tried it out when it was still in preview.
t
and context receivers has better 
-Xcontext-receivers
🙂
e
Yeah I prefer the language variant (because the normal one just does the same thing 😅)
This is in another project for instance, theres even more language features I am trying out
t
Generally our idea is that we should not advertise anywhere 
LanguageFeature
, but for user-facing change we should have related 
-X
argument
e
Yup I know I am reaching into compiler but I need to try out these features 😅 I regularly go through the enum to see which ones I can enable and test
t
Generally we want to remove 
freeCompilerArgs
from compiler options and leave it as separate task input which produce a warning on non-empty value 🙂 But it is a distant change - first we need to expose experimental compiler options in DSL 😅
e
Yeah sounds like a great idea!
Woah I just noticed your post in #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=...
?
t
optIn
should available in compiler options since 1.9.0: 
kotlin.compilerOptions.optIn.add(..)
also 
progressive
was added to compiler options
e
Amazing! Didnt know about these, thanks!
9 Views
Open in Slack
PreviousNext
Powered by