as we need access to the lookup tracker to compute classpath changes
more efficiently and reduce the size of the saved classpath snapshot.
The previous commit only changed the files' paths, this
commit actually updates the files' contents.
Note that classpath snapshotting still happens in Gradle artifact
transforms. (However, the previous commit also moved the code for
classpath snapshotting together with the code for classpath diffing as
they are closely related.)
In reality plugin key was used only in two ways:
- found corresponding generator for member scope of generated class
- pass it to declaration origin so it can be read in backend IR plugin
Because of first usage plugin key was required to be an object, which
reduces functionality of second usage, because there was no way to
pass any additional info via key to IR (in future this usecase will be
covered with IR declaration attributes, but right now we don't have
them)
So now generator which created some class is now saved in its attributes
and plugins can use any keys they want. And since there is no other
usages of `FirExtension.key` it removed from FirExtension API at all
After that commit it's allowed to register any FIR plugin using
existing extension infrastructure (`-Xplugin` CLI argument,
plugin.xml for IDE plugins, etc)
For properties which delegate to other property via the getValue
operator from stdlib (see KT-39054), we generate `$receiver` field which
stores the receiver of the property reference used in the delegate. The
problem was that this backing field was missing `correspondingProperty`.
It's needed because it is used as a map key to store static fields in
`JvmCachedDeclarations.getStaticBackingField`. If it's null, accesses to
the static $receiver fields are not remapped correctly in
`RemapObjectFieldAccesses` and
`MoveOrCopyCompanionObjectFieldsLowering`, which led to ICCE or NSFE.
#KT-49793 Fixed
Elvis now is being resolved a bit differently and in case
of inconsistent types, the while expression has error type,
but no diagnostic is reported since the element has no valid source element
When one sets the source
https://github.com/JetBrains/kotlin/commit/817316cdc93457c1de7cf10c3b422e3a4b486e5b
it brings back the issue KT-45989 that was effectively unresolved but hidden
due to diagnostic loss
^KT-45989 Open
Some existing tests start failing after previous commits adding @Exact
attribute to `?:`
They have a form:
var x: String? = nullable()
if (x == null) {
x = nullable() ?: "" // considering @Exact the whole elvis is inferred to nullable from expect type
}
x.length // should be smart cast
Previously, it was obtained from expected type of a variable being assigned,
but it's better to use the type of resulting expression
Initially this part was brought in 4ab0897d7d,
but as we see in commit message and tests it was all about unit-coercion
If compiler plugin removes source files between rounds of incremental
compilation, it may result into incorrect state of stubs. But rebuilding
stubs may require services available in UI mode only and cause
compiler failure.
This commit contains work-around allowing to avoid incorrect state of
stubs.
#KT-49340 Fixed
Hung Nguyen