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
Before this commit, we generated fake overrides at last FIR2IR stage,
after having all functions and classes built. This could lead to a
situation when fake override was called before it was generated.
This commit fixes this situation.
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
Dmitry Petrov