NB: in order to produce correct IR origins, the source element kinds for
some FIR elements has been changed. As a side effect, mapping PSI to FIR
slightly changed: namely, for `a[b]++`, `a[b]` used to be mapped on
`set` call or callable reference, but now it is mapped on `get` call.
^KT-61891: Fixed
^KT-64387: Fixed
Rework rendering of kt-like dump and signatures dump in order to avoid
unstable blank line between declarations of the same level:
1. No blank line for the first declaration inside the member scope of
the class.
2. Always a single blank line between each two subsequent declarations
inside the member scope of the class.
1. Local declarations don't participate in IR-linkage, because they
can be referenced only inside the same body -> can be dropped
from IR text tests.
2. Mangled names for private declarations computed by descriptors/fir
are actually not used anywhere (they are recomputed by IR
immediately before serialization of IR). But sometimes such
mangled names diverge between K1 and K2 -> don't check them, but
always check mangled names computed by IR even for private
declarations.
3. Also: Drop DUMP_LOCAL_DECLARATION_SIGNATURES test directive.
^KT-57428 Obsolete
^KT-57430 Obsolete
^KT-57434 Obsolete
^KT-57778 Obsolete
^KT-57775 Obsolete
We plan to disable computing full mangled names of declarations in all
manglers except the IR mangler (see the subsequent commits).
From now on, in irText tests we dump only the following mangled names:
- Full mangled names computed using the IR mangler
- Signature mangled names computed using the Descriptor mangler
- Signature mangled names computed using the IR mangler
- Signature mangled names computed using the FIR mangler
Here by a full mangled name we mean the mangled name of a declaration
computed using the `MangleMode.FULL` mode. Those mangled names include
the mangled names of the declaration'a parents.
By a signature mangled name we mean the mangled name of a declaration
computed using the `MangleMode.SIGNATURE` mode.
These mangled names are used to compute an `IdSignature` for
the declaration, hence the name.
If some function is not fake-override, then its type should be just
default type of containing class
For fake overrides the default type calculated in the following way:
1. Find first overridden function, which is not fake override
2. Take its containing class
3. Find supertype of current containing class with type constructor of
class from step 2
^KT-60252 Fixed
In this commit we have a lot of change in test data. This was caused
by the way where we evaluate constants. We split constant evaluation
into two distinct parts: only necessary evaluations for `fir2ir`
(like const val and annotations) and optimizations for lowering.
Now we don't do all constant evaluation on `fir2ir`, but IR
dump is executed after this phase, so test data changed.
#KT-58923
This only applies to JVM and fq-names in declaration references
in IR dumps.
This enables us to run more irText tests on platforms other than JVM
(see KT-58605).
This doesn't reduce the quality of tests, because the flags are still
printed for declarations themselves. We only omit them in references.
However, this makes the tests more compatible with non-JVM backends
(see KT-58605), because flags of referenced stdlib declarations may
differ among target platforms.
- Mangled names of property accessors now include context receiver
types of the corresponding property when computed from FIR.
- Context receivers are now supported when computing mangled names
from IR
- IrBasedDescriptors now account for context receivers
^KT-57435 Fixed
The reason #1 for this feature is that we want to test IdSignatures
generated for declarations. Currently, there is no (easy) way to ensure
that a change in the signature building logic doesn't cause any breaking
changes wrt klibs.
Now, most IdSignatures include hashed mangled names in them, so even if
we catch a regression where the included hash changes, there would be no
way of knowing immediately what caused it, unless we'd also have mangled
names in the expectations.
The reason #2 is to test the manglers themselves. Currently, there are
no tests for them. They heavily duplicate each other, this is already
causing issues (see KT-57427) that would be very hard to catch without
these tests.
^KT-58238 Fixed
The expression needs to be resolved first to determine if there is a
receiver that needs to be extracted to a temporary variable. Also, the
special case for prefix increment/decrement on local variable without
delegates requires resolution to check if the variable is local.
^KT-56771 Fixed
^KT-56659 Fixed
* `return` should only be added to the last statement if the return
type is not Unit
* If there is a `return` without an argument, then the expected return
type is Unit and the last expression is not a return argument (unless
it's an incomplete call, in which case it is inferred to return Unit;
this behavior is questionable, but inherited from K1)
* There should be a constraint on return arguments even if the expected
type is Unit, otherwise errors will be missed
* When the expected type is known, using the call completion results
writer is pointless (and probably subtly wrong).
^KT-54742 Fixed
Previously, FIR used `_context_receiver_n` while FE10 used `<this>` for
all context receiver parameters. This commit changes the code in FE10
to follow the convention from FIR.
- Huge refactoring for IC
- Update hash combination logic
- Introduce value class for IC hashes
- Calc md5 directly by function IR
- Split IC logic by classes
- Move JsIrLinkerLoader into separate file
- CacheUpdateStatus is a sealed class
- Render TYPE_PARAMETER reified flag
^KT-51081 Fixed
^KT-51084 Fixed
Pavel Kunyavskiy