[JS IR] Fix line number test
[JS IR] Ignore isInstance repl test
[JS IR] Ignore isInstance repl test
[JS IR] Add test with unsafe variance
Revert "[JS IR] Optimize away upcasts"
This reverts commit 8149189585.
Get rid of duplicated signatures
Revert "[JS IR] Consider erasing type parameters in return type in js signatures"
This reverts commit 6adcbe081e.
Revert "rra/ilgonmic/exported-bridges-2 [JS IR] Use js name for signature"
This reverts commit 00289d35
[JS IR] Leave as is
[JS IR] Add test with overloading by generic
[JS IR] Add test from master
[JS IR] Add tests from master
Merge-request: KT-MR-5987
Merged-by: Ilya Goncharov <Ilya.Goncharov@jetbrains.com>
^KT-51700 fixed
^KT-51523 fixed
^KT-51685 fixed
1. Extension functions declared in data classes are generated earlier by `generateMembersDeclaredInClassBody`
2. Extension functions fake override from parent class are generated earlier by `generateFakeOverrideMemberDeclarations`
So it is safe to filter out extension functions inside `generateAdditionalMembersForDataClass`
#KT-49715
#KT-51798
If we do not do this, the state-machine builder will not know the type
of the ACONST_NULL, defaulting to Object, leading to VerifyError.
Alternatively, we could use LVT to deduce the type, but getting types
from LVT is something I got rid of long time ago, and I have no desire
to return it back.
Generating CHECKCAST hints the state-machine builder the type of the
variable avoiding the issue of VerifyError. However, this CHECKCAST
replaces StrictBasicValue.NULL_VALUE with BasicValue in
OptimizationBasicInterpreter. To preserve optimization on not-spilling
known nulls, introduce BasicValues, which represent typed nulls and
create BasicInterpreter, which is aware of them. This way we have the
best of two worlds - we do not spill known nulls, and we know the type
of ACONST_NULL.
#KT-51718 Fixed
Previously it was like "null cannot be cast to MyObject" or
"MyObject cannot be cast to null", because `KClass.qualifiedName` is
`null` for local classes (including anonymous ones).
Use `KClass.toString()` instead, for both object actual dynamic type
and cast target type. This string representation is generally more
meaningful for such cases, and contains useful details for local
classes.
- 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
Incorrect `valueParameter` was passed to `generateValueArgument`, which
resulted in incorrect type being considered for generating suspend
conversion.
#KT-50949 Fixed
- Fix the predicate used for finding the member function `next`: check
that there's no extension receiver parameter, don't filter out
abstract functions.
- Do not copy iterator expression, instead change the type in all
references to the iterator variable.
- Fix some style issues.
#KT-47171 Fixed
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
Always serialize type table (and version requirement table) after
everything else, to prevent bugs like KT-51446 where inline class
underlying type was added to the type table after it has already been
serialized.
#KT-51446 Fixed
Do not generate linenumber for the start of the finally block, because
that is usually where the only word 'finally' is located. Instead,
generate linenumber for the first expression inside the finally block.
Not generating this linenumber fixes an issue in code coverage tools
which would consider such finally uncovered. Although this might be
technically considered as designed, it makes more sense to NOT detect it
as uncovered because semantics of the finally block shouldn't really
differ whether it's executed normally or because an exception happened.
It's also beneficial for the tool support to behave like javac, which
doesn't generate the linenumber either.
#KT-50973 Fixed
Supported IrDefinitelyNotNullType explicitly for now
(later it will be better to handle it at the call sites)
Co-authored-by: Svyatoslav Scherbina <svyatoslav.scherbina@jetbrains.com>
Ilmir Usmanov