Confirming something - with incremental compilatio...

# compiler

[Zac Sweers]

Confirming something - with incremental compilation, files are marked as dirty IFF they reference a symbol that has changed since the last compilation, correct? i.e. there's no scenario where changing a file in an upstream module that is not referenced by a downstream class will result in it not being recompiled, correct? To extrapolate from the above - compiler plugins would not be run over the non-recompiled class in this scenario correct? And finally - do star imports in sources defeat this since they require recompiling against a package?

Assuming all the above is correct, is it possible to link a declaration generated via compile plugin to custom symbols? Or even a matcher? For example - new/removed/modified symbols in a known upstream package?

[dmitriy.novozhilov]

> with incremental compilation, files are marked as dirty IFF they reference a symbol that has changed since the last compilation, correct?
Generally yes, but I need to clarify that "reference" here means "declaration with same name and kind was looked from this file", not "resolved to this declaration".
So in this example recompilation of b.kt would make the c.kt dirty despite the fact that foo was actually resolved to the function from a.kt

// FILE: a.kt
fun foo() {}
// FILE: b.kt
fun foo(x: Int) {}
// FILE: c.kt
fun test() {
    foo()
}

> To extrapolate from the above - compiler plugins would not be run over the non-recompiled class in this scenario correct?
Yes. This is one of issues related to non-local lookups with plugins which is not addressed yet.

> And finally - do star imports in sources defeat this since they require recompiling against a package?
By default no, the whole IC based on simple names, not packages.
There are cases when the star import could trigger the recompilation though:

// FILE: a.kt (old)
package foo

// FILE: a.kt (new)
package foo

fun bar() {}

// FILE: b.kt
import foo.*

fun bar() {}

fun test() {
    bar()
}

Here b.kt would be considered as dirty as it references the name bar in package foo and the declaration with such name was added in the new version of a.kt.
If the new a.kt would look like this then b.kt won't be recompiled:

// FILE: a.kt (new)
package foo

fun baz() {} // baz is not referenced from anywhere

> Assuming all the above is correct, is it possible to link a declaration generated via compile plugin to custom symbols? Or even a matcher? For example - new/removed/modified symbols in a known upstream package?
No, here is the issue: KT-55982

[Zac Sweers]

got it, thanks!