Compared to FE1.0, instead of using UNRESOLVED_REFERENCE, a new
UNRESOLVED_IMPORT diagnostic is introduced. This is so that we can use a
different positioning strategy to highlight the last part of the import
if the entire import is passed.
Also, this change fixed some incorrectly rejected imports in FIR. Such
cases are covered the newly added test file staticFunAndPropertyImport.kt
* kotlinx.atomicfu compiler plugin for JS_IR
Support transformations of atomic operations introduced by the kotlinx.atomicfu library for the JS_IR backend. Compiler plugin is applied externally by the kotlinx.atomicfu gradle plugin.
* Apply compiler plugin for JS platform only
* New plugin test structure
* testGroupOutputDirPrefix changed
Interfaces (regular and sealed) are by default polymorphic. To benefit
from sealing (i.e. knowledge of all inheritors in compile-time), @Serializable
annotation may be added on sealed interface, generating the same serializer
that can be used for sealed classes.
Synthetic nested classes are not generated in DEFAULT_IMPLS mode because
it causes problems when adding a synthetic companion to an interface.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/1576
This method was used for coercing `Long` values to JavaScript
`number`. However, it caused issues when `Long` values were
concatenated to a string (see KT-8666, KT-26706).
Inline functions called by the fragment is detected by the fragment
frontend and the PSI for them is supplied to the compiler backend.
For the purpose of compilation, the inline function is considered as
part of the same source module as the fragment, and then discarded
upon loading the compiled fragment for evaluation.
This commit changes the slice implementation used for
`USED_AS_EXPRESSION`.
Here is the problem as identified and mitigated by this commit:
Slices are key-value maps. They are not total over the domain of keys,
so "looking up" a key not in the slice is a valid operation, yielding
`null`.
A binding context is a collection of slices.
Binding contexts can be stacked as composite binding contexts to
e.g. facilitate scoped analyses. Looking up a key proceeds down the
stack, yielding the first non-null value, or `null` if no slice in the
stack of binding contexts contain that key.
A slice made by `createSimpleSetSlice` models a "set" of keys that can
be enlarged by inclusion: adding `(k, true)` to the slice indicates
`k` belongs to the set. `(k, false)` indicates non-membership.
However, looking up a key _not in_ the slice yields _false_, rather
than null.
Hence, simple set slices do not compose in composite binding traces.
This was encountered porting the expression evaluator to the IR
backend. PSI2IR uses `USED_AS_EXPRESSION` to generate expression body
functions properly. The frontend analysis of the fragment is layered
ontop of the binding context from the editor's analysis of the
underlying project being debugged, which contains speficially the
analysis results of inline functions called from the fragment.
If we implement default function with default parameters in inline
class, the receivers will be added to parameter list
(see ac7538a269). But since they
are not present in source parameters, we should not count them when we
compute mask for default parameters.
#KT-49977 Fixed
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.
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)
Ilya Muradyan