RESOLVED_WITH_ERROR was initially added for reproducing OI behavior.
The intention was to preserve resolution into unstable smart cast and to keep failing candidate.
However, this idea was abandoned after OI behavior proved inconsistent in cases involving generics.
This commit restores RUNTIME_ERROR status of UnstableSmartCastDiagnostic.
^KT-41357 Fixed
Use known type parameters substitutor after substitutor for fresh variables.
The old logic of substituions had the following order:
- replace known type parameters
- replace type parameters with type variables
- complete inference
- replace type variables with inferred types
According to the updated logic, replacement goes as follows:
- replace type parameters with type variables
- replace known type parameters; if they were variables, this will effectively remove them from inference
- complete inference
- replace remaining type variables with inferred types
Support projection substitution in new type substitutor.
It is needed for correct interaction with old type substitutor.
Old type substitutors can contain mappings constructor -> projection
which couldn't be expressed correctly with existing substitutor API in some cases.
^KT-41386 Fixed
- Merge `duplicatingItemsSameHashCode.kt` and
`duplicatingItemsSameHashCode2.kt` into one test enabled on both
backends, and rename it to
`duplicatingItemsSameHashCodeFewBranches.kt`.
- Rename `duplicatingItemsSameHashCode3.kt` to
`duplicatingItemsSameHashCodeMoreBranches.kt`, and also enable it for
both backends.
- Use JVM_TEMPLATES/JVM_IR_TEMPLATES to check backend-specific behavior:
1) JVM IR does not optimize less than 2 branches by design
2) JVM IR does not generate duplicate branches, also by design
Related to KT-36846.
Before this change, we incorrectly mangled the names of annotation
methods (e.g. `getI-pVg5ArA` instead of `i`) because the isSpecial
condition was false.
Previous changes related to this in the old JVM backend were in
582b1c5e66 and
0482f7e9c5, but they did not affect the
`ProperIeee754Comparisons` mode which became the default in 1.4.0. As a
result, we had a regression here.
Since the `PRIMITIVE_NUMERIC_COMPARISON_INFO` slice is used in psi2ir to
determine how to generate the comparison, this fixes the regression both
in the old JVM backend, and in all IR backends.
#KT-41426 Fixed
In 1.3.x, for inline class member inline vals 'getFoo-impl' method was
generated in corresponding inline class.
Since 1.4.0, getters for properties returning inline class values are
mangled (so corresponding getters are named 'getFoo-<mangling_hash>'.
However, to maintain backward compatibility with libraries compiled with
1.3.x, inliner should be able to find 'getFoo-impl' method in the
bytecode.
...in class members. The corresponding classes end up nested in the
class initializer of the surrounding class and we need to take this into
account when creating instances of ClassCodegen.
This fixes KT-40332 on the JVM IR backend.
The main change here is that when kotlin-reflect is being run under Java
9+, we use another implementation of BuiltInsResourceLoader (see
libraries/reflect/api/src/java9) which loads .kotlin_builtins files from
the java.lang.Module instance of kotlin-stdlib, instead of the class
loader of kotlin-reflect, which may not have access to those resources.
If the application is being run in the old (classpath) mode, that Module
represents the unnamed module, which contains everything on the
classpath, and everything works as before. But if it's being run in the
modular mode, that Module instance is an encapsulated module for
kotlin-stdlib classes and resources, exactly where .kotlin_builtins
files are located.
This fixes a regression in 1.4.0. Prior to 1.4, kotlin-reflect and
kotlin-stdlib were not named modules (see KT-21266) and were loaded as
_automatic_ modules even if the application was run in the modular mode.
Apparently, they shared the same class loader in that case and looking
up .kotlin_builtins resources worked.
This change was supposed to go alongside
828cc6dbf3, but was overlooked because
adding module-info to standard libraries was postponed at that point.
Also slightly refactor Java9ModulesIntegrationTest to simplify running
compiled code, and add a smoke test on using kotlin-reflect in modular
mode.
#KT-40842 Fixed
JVM_IR has consistent stepping behavior for secondary constructors
and init blocks. This change fixes the expectations for tests that
expect the less consistent JVM backend behavior.
Temporary variable loads in when expressions had the offsets
of the variable declaration. That leads to hacks during codegen
for line number generation.
Instead of those hacks, give the variable loads the offsets of
the context in which they occur. That avoids the codegen hacks
and fixes stepping behavior for more when expressions.
NB some cases such as captured extension receiver for an extension
lambda are not supported yet; to be discussed, to what extent should we
actually follow JVM code shape here.
Dmitry Petrov