Руководство по миграции на компилятор K2

Смарт-касты

В определенных случаях компилятор Kotlin может автоматически привести объект к типу, избавляя вас от необходимости указывать это явно. Это называется смарт-кастом. Теперь компилятор Kotlin K2 выполняет смарт-касты в еще большем количестве сценариев.

В Kotlin 2.0.0 мы улучшили работу смарт-кастов в следующих областях:

• Локальные переменные и последующие области видимости

• Проверки типов с оператором логического or

• Встроенные функции

• Свойства с функциональными типами

• Обработка исключений

• Операторы инкремента и декремента

class Cat {
    fun purr() {
        println("Purr purr")
    }
}

fun petAnimal(animal: Any) {
    val isCat = animal is Cat
    if (isCat) {
        // In Kotlin 2.0.0, the compiler can access
        // information about isCat, so it knows that
        // animal was smart-cast to the type Cat.
        // Therefore, the purr() function can be called.
        // In Kotlin 1.9.20, the compiler doesn't know
        // about the smart cast, so calling the purr()
        // function triggers an error.
        animal.purr()
    }
}

fun main(){
    val kitty = Cat()
    petAnimal(kitty)
    // Purr purr
}

interface Status {
    fun signal() {}
}

interface Ok : Status
interface Postponed : Status
interface Declined : Status

fun signalCheck(signalStatus: Any) {
    if (signalStatus is Postponed || signalStatus is Declined) {
        // signalStatus is smart-cast to a common supertype Status
        signalStatus.signal()
        // Prior to Kotlin 2.0.0, signalStatus is smart cast 
        // to type Any, so calling the signal() function triggered an
        // Unresolved reference error. The signal() function can only 
        // be called successfully after another type check:
        
        // check(signalStatus is Status)
        // signalStatus.signal()
    }
}

interface Processor {
    fun process()
}

inline fun inlineAction(f: () -> Unit) = f()

fun nextProcessor(): Processor? = null

fun runProcessor(): Processor? {
    var processor: Processor? = null
    inlineAction {
        // In Kotlin 2.0.0, the compiler knows that processor 
        // is a local variable and inlineAction() is an inline function, so 
        // references to processor can't be leaked. Therefore, it's safe 
        // to smart-cast processor.
      
        // If processor isn't null, processor is smart-cast
        if (processor != null) {
            // The compiler knows that processor isn't null, so no safe call 
            // is needed
            processor.process()

            // In Kotlin 1.9.20, you have to perform a safe call:
            // processor?.process()
        }

        processor = nextProcessor()
    }

    return processor
}

class Holder(val provider: (() -> Unit)?) {
    fun process() {
        // In Kotlin 2.0.0, if provider isn't null,
        // it is smart-cast
        if (provider != null) {
            // The compiler knows that provider isn't null
            provider()

            // In 1.9.20, the compiler doesn't know that provider isn't 
            // null, so it triggers an error:
            // Reference has a nullable type '(() -> Unit)?', use explicit '?.invoke()' to make a function-like call instead
        }
    }
}

interface Provider {
    operator fun invoke()
}

interface Processor : () -> String

class Holder(val provider: Provider?, val processor: Processor?) {
    fun process() {
        if (provider != null) {
            provider() 
            // In 1.9.20, the compiler triggers an error: 
            // Reference has a nullable type 'Provider?', use explicit '?.invoke()' to make a function-like call instead
        }
    }
}

//sampleStart
fun testString() {
    var stringInput: String? = null
    // stringInput is smart-cast to String type
    stringInput = ""
    try {
        // The compiler knows that stringInput isn't null
        println(stringInput.length)
        // 0

        // The compiler rejects previous smart cast information for 
        // stringInput. Now stringInput has the String? type.
        stringInput = null

        // Trigger an exception
        if (2 > 1) throw Exception()
        stringInput = ""
    } catch (exception: Exception) {
        // In Kotlin 2.0.0, the compiler knows stringInput 
        // can be null, so stringInput stays nullable.
        println(stringInput?.length)
        // null

        // In Kotlin 1.9.20, the compiler says that a safe call isn't
        // needed, but this is incorrect.
    }
}
//sampleEnd
fun main() {
    testString()
}

interface Rho {
    operator fun inc(): Sigma = TODO()
}

interface Sigma : Rho {
    fun sigma() = Unit
}

interface Tau {
    fun tau() = Unit
}

fun main(input: Rho) {
    var unknownObject: Rho = input

    // Check if unknownObject inherits from the Tau interface
    // Note, it's possible that unknownObject inherits from both
    // Rho and Tau interfaces.
    if (unknownObject is Tau) {

        // Use the overloaded inc() operator from interface Rho.
        // In Kotlin 2.0.0, the type of unknownObject is smart-cast to
        // Sigma.
        ++unknownObject

        // In Kotlin 2.0.0, the compiler knows unknownObject has type
        // Sigma, so the sigma() function can be called successfully.
        unknownObject.sigma()

        // In Kotlin 1.9.20, the compiler doesn't perform a smart cast
        // when inc() is called so the compiler still thinks that 
        // unknownObject has type Tau. Calling the sigma() function 
        // throws a compile-time error.
        
        // In Kotlin 2.0.0, the compiler knows unknownObject has type
        // Sigma, so calling the tau() function throws a compile-time 
        // error.
        unknownObject.tau()
        // Unresolved reference 'tau'

        // In Kotlin 1.9.20, since the compiler mistakenly thinks that 
        // unknownObject has type Tau, the tau() function can be called,
        // but it throws a ClassCastException.
    }
}

Kotlin Multiplatform

В компиляторе K2 появились улучшения, связанные с Kotlin Multiplatform, в следующих областях:

• Разделение общих и платформенных исходных файлов во время компиляции

• Разные уровни видимости expect- и actual-объявлений

fun foo(x: Any) = println("common foo")

fun exampleFunction() {
    foo(42)
}

// JVM
fun foo(x: Int) = println("platform foo")

// JavaScript
// There is no foo() function overload on the JavaScript platform

expect class Identity {
    fun confirmIdentity(): String
}

fun common() {
    // Before 2.0.0, it triggers an IDE-only error
    Identity().confirmIdentity()
    // RESOLUTION_TO_CLASSIFIER : Expected class Identity has no default constructor.
}

actual class Identity {
    actual fun confirmIdentity() = "expect class fun: jvm"
}

Expected class 'expect class Identity : Any' does not have default constructor

// Example library

// MODULE: common
fun whichFun(x: Any) = println("common function") 

// MODULE: JVM
fun whichFun(x: Int) = println("platform function")

// A project that uses the example library for the JVM target

// MODULE: common
fun main(){
    whichFun(2) 
    // platform function
}

// Example library isn't used

// MODULE: common
fun whichFun(x: Any) = println("common function") 

fun main(){
    whichFun(2) 
    // common function
}

// MODULE: JVM
fun whichFun(x: Int) = println("platform function")

expect internal class Attribute // Visibility is internal
actual class Attribute          // Visibility is public by default,
                                // which is more permissive

expect internal class Attribute                 // Visibility is internal
internal actual typealias Attribute = Expanded

class Expanded                                  // Visibility is public by default,
                                                // which is more permissive

Использование отчетов о сборке Kotlin с Gradle

Отчеты о сборке Kotlin содержат сведения о времени, затраченном на разные этапы компиляции задач компилятора Kotlin, а также о том, какой компилятор и версия Kotlin использовались и была ли компиляция инкрементальной. Эти отчеты полезны для оценки производительности сборки. Они дают больше информации о конвейере компиляции Kotlin, чем отчеты о сборках Gradle, поскольку содержат обзор производительности всех задач Gradle.

kotlin.build.report.output=file

Немедленная инициализация открытых свойств с полями для хранения значения

Что изменилось?

В Kotlin 2.0 все свойства open с полями для хранения значения должны инициализироваться сразу, иначе возникнет ошибка компиляции. Раньше немедленная инициализация требовалась только для свойств open var, но теперь это правило распространяется и на свойства open val с полями для хранения значения:

open class Base {
    open val a: Int
    open var b: Int
    
    init {
        // Error starting with Kotlin 2.0 that earlier compiled successfully 
        this.a = 1 //Error: open val must have initializer
        // Always an error
        this.b = 1 // Error: open var must have initializer
    }
}

class Derived : Base() {
    override val a: Int = 2
    override var b = 2
}

Это изменение делает поведение компилятора более предсказуемым. Рассмотрим пример, в котором свойство open val переопределяется свойством var с пользовательским сеттером.

Использование пользовательского сеттера может привести к путанице при отложенной инициализации, поскольку непонятно, нужно ли инициализировать поле для хранения значения или вызвать сеттер. Раньше компилятор не мог гарантировать, что при вызове сеттера поле для хранения значения будет инициализировано.

Как теперь лучше поступать?

Мы рекомендуем всегда инициализировать открытые свойства с полями для хранения значения, поскольку считаем, что такой подход эффективнее и снижает вероятность ошибок.

Однако, если вы не хотите инициализировать свойство сразу, можно:

• Сделать свойство final.

• Использовать приватное свойство для хранения значения, которое допускает отложенную инициализацию.

Дополнительную информацию см. в соответствующей задаче в YouTrack.

Устаревший синтетический сеттер для проецируемого получателя

Что изменилось?

Если вы используете синтетический сеттер класса Java, чтобы присвоить значение типа, конфликтующего с проецируемым типом класса, возникает ошибка.

Предположим, что у вас есть класс Java с именем Container, содержащий методы getFoo() и setFoo():

public class Container<E> {
    public E getFoo() {
        return null;
    }
    public void setFoo(E foo) {}
}

Если в следующем коде Kotlin экземпляры класса Container имеют проецируемые типы, использование метода setFoo() всегда приводит к ошибке. Однако синтетическое свойство foo будет вызывать ошибку только начиная с Kotlin 2.0.0:

fun exampleFunction(starProjected: Container<*>, inProjected: Container<in Number>, sampleString: String) {
    starProjected.setFoo(sampleString)
    // Error since Kotlin 1.0

    // Synthetic setter `foo` is resolved to the `setFoo()` method
    starProjected.foo = sampleString
    // Error since Kotlin 2.0.0

    inProjected.setFoo(sampleString)
    // Error since Kotlin 1.0

    // Synthetic setter `foo` is resolved to the `setFoo()` method
    inProjected.foo = sampleString
    // Error since Kotlin 2.0.0
}

Как теперь лучше поступать?

Если из-за этого изменения в коде появились ошибки, возможно, стоит пересмотреть структуру объявлений типов. Может быть, вам не нужно использовать проекции типов или следует удалить из кода присваивания.

Дополнительную информацию см. в соответствующей задаче в YouTrack.

Запрет на использование недоступных обобщённых типов

Что изменилось?

В связи с новой архитектурой компилятора K2 мы изменили способ обработки недоступных обобщённых типов. Как правило, не следует использовать недоступные обобщённые типы в коде, поскольку это указывает на неправильную конфигурацию сборки проекта, из-за которой компилятор не может получить информацию, необходимую для компиляции. В Kotlin 2.0.0 нельзя объявить или вызвать функциональный литерал с недоступным обобщённым типом, а также использовать обобщённый тип с недоступными аргументами типа. Это ограничение помогает избежать ошибок компилятора в дальнейшем.

Например, предположим, что вы объявили обобщённый класс в одном модуле:

// Module one
class Node<V>(val value: V)

Если у вас есть другой модуль (модуль два), настроенный как зависимый от модуля один, ваш код может обращаться к классу Node<V> и использовать его как тип в типах функций:

// Module two
fun execute(func: (Node<Int>) -> Unit) {}
// Function compiles successfully

Однако, если проект настроен неправильно и у вас есть третий модуль (модуль три), зависящий только от модуля два, компилятор Kotlin не сможет получить доступ к классу Node<V> в модуле один при компиляции третьего модуля. Теперь любые лямбды или анонимные функции в модуле три, использующие тип Node<V>, вызывают ошибки в Kotlin 2.0.0. Это помогает предотвратить ошибки компилятора, сбои и исключения во время выполнения, которых можно избежать:

// Module three
fun test() {
    // Triggers an error in Kotlin 2.0.0, as the type of the implicit 
    // lambda parameter (it) resolves to Node, which is inaccessible
    execute {}

    // Triggers an error in Kotlin 2.0.0, as the type of the unused 
    // lambda parameter (_) resolves to Node, which is inaccessible
    execute { _ -> }

    // Triggers an error in Kotlin 2.0.0, as the type of the unused
    // anonymous function parameter (_) resolves to Node, which is inaccessible
    execute(fun (_) {})
}

Ошибки возникают не только при использовании в функциональных литералах параметров-значений с недоступными обобщёнными типами, но и в том случае, если тип содержит недоступный аргумент обобщённого типа.

Например, в модуле один объявлен тот же обобщённый класс. В модуле два объявлен другой обобщённый класс: Container<C>. Кроме того, в модуле два объявлены функции, в которых Container<C> использует обобщённый класс Node<V> в качестве аргумента типа:

// Module one
class Node<V>(val value: V)

// Module two
class Container<C>(vararg val content: C)

// Functions with generic class type that
// also have a generic class type argument
fun produce(): Container<Node<Int>> = Container(Node(42))
fun consume(arg: Container<Node<Int>>) {}

Если вызвать эти функции в модуле три, в Kotlin 2.0.0 возникнет ошибка, поскольку обобщённый класс Node<V> недоступен из модуля три:

// Module three
fun test() {
    // Triggers an error in Kotlin 2.0.0, as generic class Node<V> is 
    // inaccessible
    consume(produce())
}

В будущих выпусках мы продолжим отказываться от использования недоступных типов в целом. В Kotlin 2.0.0 мы уже начали это делать, добавив предупреждения для некоторых случаев с недоступными типами, в том числе необобщёнными.

Например, возьмём ту же конфигурацию модулей, что и в предыдущих примерах, но заменим обобщённый класс Node<V> необобщённым классом IntNode и объявим все функции в модуле два:

// Module one
class IntNode(val value: Int)

// Module two
// A function that contains a lambda 
// parameter with `IntNode` type
fun execute(func: (IntNode) -> Unit) {}

class Container<C>(vararg val content: C)

// Functions with generic class type
// that has `IntNode` as a type argument
fun produce(): Container<IntNode> = Container(IntNode(42))
fun consume(arg: Container<IntNode>) {}

При вызове этих функций в модуле три появляются предупреждения:

// Module three
fun test() {
    // Triggers warnings in Kotlin 2.0.0, as class IntNode is 
    // inaccessible.

    execute {}
    // Class 'IntNode' of the parameter 'it' is inaccessible.

    execute { _ -> }
    execute(fun (_) {})
    // Class 'IntNode' of the parameter '_' is inaccessible.

    // Will trigger a warning in future Kotlin releases, as IntNode is
    // inaccessible.
    consume(produce())
}

Как теперь лучше поступать?

Если вы столкнулись с новыми предупреждениями о недоступных обобщённых типах, скорее всего, проблема связана с конфигурацией системы сборки. Рекомендуем проверить скрипты сборки и конфигурацию.

В крайнем случае можно настроить прямую зависимость модуля три от модуля один. Другой вариант — изменить код так, чтобы типы были доступны в рамках одного модуля.

Дополнительную информацию см. в соответствующей задаче в YouTrack.

Единый порядок разрешения свойств Kotlin и полей Java с одинаковыми именами

Что изменилось?

До Kotlin 2.0.0 при работе с классами Java и Kotlin, наследующими друг от друга и содержащими свойства Kotlin и поля Java с одинаковыми именами, поведение при разрешении совпадающих имён было непоследовательным. Кроме того, поведение IntelliJ IDEA и компилятора различалось. Разрабатывая новый механизм разрешения для Kotlin 2.0.0, мы стремились свести влияние на пользователей к минимуму.

Например, предположим, что есть класс Java Base:

public class Base {
    public String a = "a";

    public String b = "b";
}

Предположим также, что есть класс Kotlin Derived, наследующий ранее упомянутый класс Base:

class Derived : Base() {
    val a = "aa"

    // Declares custom get() function
    val b get() = "bb"
}

fun main() {
    // Resolves Derived.a
    println(a)
    // aa

    // Resolves Base.b
    println(b)
    // b
}

До Kotlin 2.0.0 выражение a разрешалось как свойство Kotlin в классе Kotlin Derived, а выражение b — как поле Java в классе Java Base.

В Kotlin 2.0.0 поведение разрешения в этом примере стало последовательным: свойство Kotlin имеет приоритет над одноимённым полем Java. Теперь выражение b разрешается как: Derived.b.

Общее правило: приоритет имеет подкласс. Это видно на предыдущем примере: разрешается свойство Kotlin a из класса Derived, поскольку Derived — подкласс класса Java Base.

Если наследование организовано наоборот и класс Java наследует класс Kotlin, приоритет имеет поле Java в подклассе, а не одноимённое свойство Kotlin.

Рассмотрим пример:

open class Base {
    val a = "aa"
}

public class Derived extends Base {
    public String a = "a";
}

Теперь рассмотрим следующий код:

fun main() {
    // Resolves Derived.a
    println(a)
    // a
}

Как теперь лучше поступать?

Если это изменение влияет на ваш код, подумайте, действительно ли вам нужны совпадающие имена. Если вы хотите, чтобы классы Java или Kotlin содержали поле или свойство с одинаковым именем и наследовали друг друга, учитывайте, что приоритет будет у поля или свойства в подклассе.

Дополнительную информацию см. в соответствующей задаче в YouTrack.

Улучшенная проверка на null для массивов примитивных типов Java

Что изменилось?

Начиная с Kotlin 2.0.0 компилятор корректно определяет допустимость null для массивов примитивных типов Java, импортированных в Kotlin. Теперь он сохраняет исходную информацию о допустимости null из аннотаций TYPE_USE, используемых с массивами примитивных типов Java, и выдаёт ошибки, если значения используются не в соответствии с аннотациями.

Обычно при вызове из Kotlin типов Java с аннотациями @Nullable и @NotNull им присваивается соответствующая информация о допустимости null:

interface DataService {
    @NotNull ResultContainer<@Nullable String> fetchData();
}

val dataService: DataService = ... 
dataService.fetchData() // -> ResultContainer<String?>

Однако раньше при импорте массивов примитивных типов Java в Kotlin все аннотации TYPE_USE терялись, что приводило к платформенной допустимости null и потенциально небезопасному коду:

interface DataProvider {
    int @Nullable [] fetchData();
}

val dataService: DataProvider = ...
dataService.fetchData() // -> IntArray .. IntArray?
// No error, even though `dataService.fetchData()` might be `null` according to annotations
// This might result in a NullPointerException
dataService.fetchData()[0]

Обратите внимание, что эта проблема никогда не затрагивала аннотации допустимости null непосредственно в объявлении, а только аннотации TYPE_USE.

Как теперь лучше поступать?

В Kotlin 2.0.0 проверка на null для массивов примитивных типов Java стала стандартной. Если вы используете такие массивы, проверьте код на наличие новых предупреждений и ошибок:

• Любой код, который использует массив примитивного типа Java @Nullable без явной проверки на null или пытается передать null методу Java, ожидающему массив примитивного типа, не допускающий null, теперь не скомпилируется.

• При использовании массива примитивного типа @NotNull с проверкой на null теперь выдаются предупреждения «Ненужный безопасный вызов» или «Сравнение с null всегда ложно».

Дополнительную информацию см. в соответствующей задаче в YouTrack.

Более строгие правила для абстрактных членов в ожидаемых классах

Что изменилось?

Из-за разделения общих и платформенных исходных файлов при компиляции компилятором K2 мы ввели более строгие правила для абстрактных членов в ожидаемых классах.

В предыдущем компиляторе ожидаемый неабстрактный класс мог наследовать абстрактную функцию, не переопределяя эту функцию. Поскольку компилятор одновременно имел доступ к общему и платформенному коду, он мог проверить, есть ли у абстрактной функции соответствующее переопределение и определение в фактическом классе.

Теперь, когда общие и платформенные исходные файлы компилируются отдельно, унаследованную функцию необходимо явно переопределить в ожидаемом классе, чтобы компилятор знал, что она не является абстрактной. В противном случае компилятор сообщает об ошибке ABSTRACT_MEMBER_NOT_IMPLEMENTED.

Например, предположим, что в общем исходном наборе объявлен абстрактный класс с именем FileSystem, содержащий абстрактную функцию listFiles(). Функция listFiles() определена в платформенном исходном наборе в составе фактического объявления.

Если в общем коде у вас есть ожидаемый неабстрактный класс с именем PlatformFileSystem, наследующий класс FileSystem, класс PlatformFileSystem наследует абстрактную функцию listFiles(). Однако в Kotlin неабстрактный класс не может содержать абстрактную функцию. Чтобы сделать функцию listFiles() неабстрактной, нужно объявить её как переопределение без ключевого слова abstract:

abstract class FileSystem {
    abstract fun listFiles()
}
expect open class PlatformFileSystem() : FileSystem {
    // In Kotlin 2.0.0, an explicit override is needed
    expect override fun listFiles()
    // Before Kotlin 2.0.0, an override wasn't needed
}

actual open class PlatformFileSystem : FileSystem {
    actual override fun listFiles() {}
}

Как теперь лучше поступать?

Если ожидаемый неабстрактный класс наследует абстрактные функции, добавьте неабстрактное переопределение.

Дополнительную информацию см. в соответствующей задаче в YouTrack.

По тематическим областям

В этих тематических областях перечислены изменения, которые вряд ли повлияют на ваш код, но содержат ссылки на соответствующие задачи YouTrack для дополнительной информации. Изменения, отмеченные звездочкой (*) рядом с идентификатором задачи, описаны в начале раздела.

Обновление собственных плагинов компилятора

Процесс обновления зависит от типа вашего собственного плагина и может выполняться двумя способами.