This way caller don't need to first check if the symbol is allowed to
override. The current API throws for cases like Java field, or enum
entry, which is not very user-friendly.
These two fields references the parent of the import rather than the
classes that are imported. For example
```
import java.util.Map // resolvedClassId -> null
import java.util.Map.Entry // resolvedClassId -> java.util.Map
import java.util.Map.* // resolvedClassId -> java.util.Map
import java.util.Map.someStaticMethod // resolvedClassId -> java.util.Map
import kotlin.package.someTopLevelFuntion // resolvedClassId -> null
import kotlin.package.MyObject.someObjectFuntion // resolvedClassId -> kotlin.package.MyObject
```
ImplicitReceiverValue is mutable and FIR body resolve could alter it
while analysing code with smartcast. Hence, previously the IDE may see
inconsistent receiver values for a local scope. For example
```
open class A
interface Foo {
fun foo()
}
fun A.bar() {
if (this is Foo) {
// scope here has implicit receiver type to be `A` rather than `it<A, Foo>`
}
}
```
This change creates snapshots for local statements so later changes
during body resolve won't affect the collected context.
Assuming Java class `Super` has a protected `getName` method and a
public `setName` method.
Then, in a subclass of `Super`, FE1.0 allows calls to `setName` via the
property syntax if the property is protected and invisible due to
dispatch receiver is not `this` or `super`.
Previously actual value was dependent on the order of calls to `updateJvmTarget` and `configureJava9Compilation` in build script that may lead to inconsistencies
`compileOnly` configuration is unresolvable, and it's more preferable to create new configuration that extends from it rather than making it resolvable
val y = 1
object { val x = y }
->
class XKt$1(`$y`: Int) { val x: Int = `$y` }
Note that `$y` is not stored in a field because it's not used outside
the primary constructor.
One exception is captured inline parameters on the JVM backend, as the
bytecode inliner uses field assignment instructions (setfield) to locate
them; removing the field is thus not possible.
It won't fix KT-48181 completely, but it will allow to create such annotations
if all value arguments are specified.
For the full fix, we need to read default annotation values from classfiles in jar.
#KT-48181 In progress
Tianyu Geng