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 commit fixes the receiver of these method in FIR2IR code
by removing a particular hack.
However, as the consequence of it 2 black box tests become broken in K2.
The reason is KT-54952 which is not yet fixed
Related to KT-54887
Before this fix, changes that were made to the arguments list by calling
argumentList.transformArguments() were overriden by replaceArgumentList.
This fixes reverses the order in which these calls are made.
This also aligns the logic between the completion of qualified accesses
and delegated constructor calls.
#KT-59102 Fixed
Generating IR declarations for use-site substitution overrides leads
to IR that is different from K1 as well as problems in signature
generation which relies on mangling. Use-site substitutions can contain
references to type parameters from the call-site which aren't handled
in mangling.
#KT-57022 Fixed
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.
Previously, the semantic was more-or-less correct for most of the cases
but some corner one, like `sort` in MutableList didn't work properly.
Namely, `sort` should be marked there in a way to forbid to call it
everywhere beside super-calls.
Also, overriding it should be allowed.
Mostly, the logic was re-written to K2 model from K1-related
JvmBuiltInsCustomizer.
^KT-57694 In progress
^KT-57269 Fixed
For type parameters of generic properties,
`DeclarationDescriptor#getContainingDeclaration` must return
the property descriptor instead of the accessor function descriptor.
^KT-57436 Fixed
^KT-58346 Fixed
Review: https://jetbrains.team/p/kt/reviews/9967
BTW this commit accidentaly and partially fixes KT-57553 for K2, because
of a cleaner K2 architecture. I will unify MUST_BE_INITIALIZED behaviour
in K1 and K2 in the next commits
- 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 test is not in any way JVM-specific, but it fails on the JS BE
because of different fq-names of stdlib symbols on JVM and JS.
The fix is in progress. Mute the test until the fix is ready.
Before this commit, for property candidates in K2 their types wasn't
inferred/susbtituted properly.
So, when candidate for fooBar.liveLoaded.invoke() was created,
the type of `fooBar.liveLoaded` was just X type parameter for which
there is no any `bar()` functions in its member scope.
While proposed semantics is a bit different from K1, where
both property and invoke candidates are united into common system,
it doesn't contradict to the specification (https://kotlinlang.org/spec/overload-resolution.html#callables-and-invoke-convention)
which says explicitly that invoke-convention should be desugared as
`r.foo.invoke()`, thus `r.foo` should be completed independently.
Also, this strategy supports some reasonable use-cases like KT-58259
while it's still a breaking change but for more artificial-looking
situations (see KT-58260) and should be passed through
the language committee.
The changes in stubTypeReceiverRestriction* tests looks consistent
because of how `genericLambda` now works
(with full completion of property call).
NB: The code is going to be red once KT-54667 is fixed and also there's
already similar diagnostic in K1 (INFERRED_INTO_DECLARED_UPPER_BOUNDS)
^KT-58142 Fixed
^KT-58259 Fixed
^KT-58260 Related
Use the same condition as in the already existing `createIrEnumEntry`
function (and as in psi2ir): enum class should be final unless there's
an enum entry with any declaration other than its constructor.
#KT-57216
Sometimes when running MPP tests we may
observe js-specific modules running with
the jvm-specific fir2ir converter
(probably because the name didn't contain
the JVM affix).
In this example we get 2 variants of `kotlin/toString()`:
one coming from the KLib provider, and the
other coming from the builtins provider.
These are identical deserialized functions.
^KT-57601 Fixed
Sergej Jaskiewicz