A modern programming language that makes developers happier.

kotlinlang

How can I apply the progressive compiler mode for all modules?

```
subprojects {
    tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).all {
        kotlinOptions {
            freeCompilerArgs += ['-progressive']
        }
    }
}
```

Figured out the kotlin dsl one:
```
  tasks.withType(KotlinCompile::class) {
    kotlinOptions.freeCompilerArgs += "-progressive"
  }
```

It would be great if this was shown in the docs

Is there any documentation on what all the things are, the progressive mode does?

Or even ```tasks.withType&lt;KotlinCompile&gt; {}```

Would be nice to have list of all related changes of progressive mode

But probably you will have depreciation warning for all those cases, so if you don't have compiler warnings, nothing will change for you project

There are a few examples of such changes in Kotlin 1.2.50 release notes, when progressive mode was introduced

&gt; you will have depreciation warning for all those cases, so if you don’t have compiler warnings, nothing will change for you project

I’d like to note there can be (a very few) exceptions. They are carefully handpicked and manually reviewed, and we only resort to it when deprecated cases are very esoteric, and the proper deprecation warning would be way too expensive to implement

&gt; Would be nice to have list of all related changes of progressive mode

Yes, that’s a nice idea. I’ve filed a YT issue for discussing it: <https://youtrack.jetbrains.com/issue/KT-28171>

<@U0KBF8D7V> we don’t have any `-proressive`-enabled changes in 1.3.0 yet, so currently it is equal to non-progressive mode. You can start using it now and track release notes; all changes, included in the `-progressive` will be mentioned here.

You could throw an error for the range checks

You mean elevate deprecation warning to compiler error?

Yes, that’s an interesting idea, thanks! There are some complications, because `@Deprecated` mechanism is public, meaning that any of your dependencies may have deprecated declarations, so turning error on for all declarations marked with `@Deprecated` maybe too much. But we’ll consider it, it definitely sounds like a sane request!

I believe propagation of this particular warning to error can make sense in progressive mode, but not sure why this should be related to dependencies, I thought that progressive mode is compilation only check so shouldn't be related to dependencies which are already compiled