for performance reasons: (1) the snapshots are too big, and (2) they are
usually updated only at the end of the task execution--in a failed task
run, they are usually unchanged and therefore don't need to be restored.
The previous commit added gson to `incremental-compilation-impl` module.
However, gson is currently not added to -libraryjars for Proguard, so
running with -Pteamcity=true would fail with
```
> Task :kotlin-compiler:proguard
Warning: ... can't find referenced class com.google.gson.Gson
Warning: ... can't find referenced class com.google.gson.GsonBuilder
You may need to add missing library jars or update their versions.
If your code works fine without the missing classes, you can suppress
the warnings with '-dontwarn' options.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
```
This commits adds -dontwarn com.google.gson.** to work around this
error. The proper fix is probably to add gson (and many other libraries)
to Proguard's -libraryjars.
Also visit a class file with ASM once to extract all information we need
in advance, instead of visiting the class file each time some piece of
info is needed.
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)
In JS, RegExp can return a match before the specified start index,
if it has matched at that index, but it is in the middle of a surrogate
pair. Account for that when advancing to the next position after
a zero-width match so that it doesn't get to the middle of SP.
Currently JS/IR and WASM targets share this attribute.
This causes issues for HMPP projects on
Variant-resolution stage when both JS/IR and WAS published.
Given the fact that WASM compilation uses IR only it is logical
to exclude such attribute which should fix variant resolution in HMPP
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
konstantin.tskhovrebov