There is no class that overrides this method.
Also replaced `newValue` call with `newExceptionValue`. Under the hood,
`newExceptionValue` still calls `newValue` if the interpreter doesn't
redefine it. And it kind of makes sense to call `newExceptionValue`
here because we are handling try-catch block.
In the FIR generator, the `AbstractElement` class was used to
represent either an element type without type arguments applied
(using the `Element` subclass), or an element type with applied type
arguments (using the `ElementWithArguments` subclass).
Instead, it is more logical to use the `Element` class to always
represent a non-parameterized element type, and for a parameterized
element type use the `ElementRef` class, just like we do
in the IR generator.
In these cases we have a `FirVarargArgumentsExpression`
with a `FirNamedArgumentExpression` inside as its first
argument, which, in turn, has a `FirArrayLiteral`
argument.
^KT-62146 Fixed
Test for the case when enum entry has constructor call but doesn't have
body already exist in
`compiler/testData/diagnostics/tests/multiplatform/enum/constructorInHeaderEnum.kt`.
^KT-59978 Fixed
...accidental use of tree-specific implementation instead of common one.
Actually, I stepped on this rake myself in next commit, when
accidentally imported function from `PsiSourceNavigator`.
^KT-59978
Before this commit, test data for 'synthesizedDataClassMembers' test
was different between PSI and LT, because we had SYNTHETIC_OFFSET = -2
for synthetic functions and NaiveSourceBasedFileEntryImpl calculated
line/column as 0 for LT. In this commit the dumper was edited to
count -1 as line -1 / column -1 independent of a file entry used.
After this commit there are three different versions of
IR source range tests: classic (K1), FIR/PSI (K2), FIR/LT (K2).
Since 5 tests behave differently for FIR/PSI and FIR/LT,
in this commit their test data was set to FIR/LT state,
so relevant 5 tests are failing for FIR/PSI right now.
They will be fixed in two subsequent commits
Related to KT-59864, KT-60111, KT-59584
- Java combined declared member scopes are implemented as a composition
of the non-static and static scope, so we have to exclude inner
classes from the non-static scope to avoid duplicates.
- This is not an issue for Kotlin combined declared member scopes,
because the combined scope is already the base scope.
^KT-61800
- Comparing the callable ID with the owner's class ID is the simplest
way to check whether a callable is declared inside an owner class.
However, this does not work for local classes, because they do not
have proper class IDs. The same issue occurs when trying to get the
containing class, because it is a lookup tag search in symbol
providers.
- Given that the scope is only needed for Java classes and local Java
classes cannot leak from function bodies, the easiest solution is to
disallow creating this scope for local classes.
^KT-61800
Ivan Kylchik