The regression appeared after
b5a8ffaddc
when we started trying both static and member methods until
first success and when there is no successful
we were just leaving the last one (e.g. private member)
But the actual problem is that we were commiting the trace
in case of single (but incorrect) result in resolution mode of
SHAPE_FUNCTION_ARGUMENTS when we couldn't yet choose the
correct static method
Also we shouldn't choose a shape for callable reference
using only the knowledge that result is single:
it may lead to the wrong inference result
(see test with Pattern::compile)
#KT-17597 Fixed
#KT-10397 Fixed
According to JVMS (p. 4.3.4) inner classes should be separated with `$` in generic signature.
Note that in Java, inner types separated with `.` after first parameterized type, and now we preserve the same behaviour. See tests for clarification.
Local returns normalization can generate POP instructions.
These POP instructions can drop functional parameters, as in KT-17590,
and should be processed in markPlacesForInlineAndRemoveInlinable just
as other POP instructions.
KT-17590 conditional return in inline function parameter argument causes compilation exception
It never terminates, so the corresponding value on stack can't be used.
However, if this happens in an inlined lambda argument, the inliner is
unable to remove the corresponding ALOAD instruction (because default
handler never terminates, and thus corresponding ALOAD is not used for
lambda invocation).
KT-17573 try-finally expression in inlined function parameter argument fails with VerifyError
When a try-catch expression is passed as an argument to the inline
lambda parameter, lambda variable on stack is spilled and restored in
several different locations (1 for try-block, 1 for each catch-blocks).
So it's possible that lambda to be invoked comes from multiple loads,
all of which should have the same "root" lambda parameter.
In cases like KT-17384, where 'break' or 'continue' happens in an argument
to an inlined lambda call, fix-stack transformation sees corresponding
ALOAD for lambda, and inserts corresponding POP instruction before jump.
However, this ALOAD is later removed during inlining.
So, we should also remove the related POP instructions.
com.typesafe.akka:akka-cluster-sharding_2.12:2.5
akka.cluster.sharding.ClusterSharding has the following methods:
public static ClusterSharding get(ActorSystem var0) {
return ClusterSharding$.MODULE$.get(var0);
}
public static Extension get(ActorSystem var0) {
return ClusterSharding$.MODULE$.get(var0);
}
NB: ClusterSharding <: Extension
None of these methods is synthetic or something, but javac allows
calls like ClusterSharding.get(null) and they get resolved
to the first method returning ClusterSharding
It seems that both javac and IntelliJ resolution algorithms filter out
such clashing declarations choosing the one that has the most
specific return type, the same idea is applied in the change
#KT-17560 Fixed
`isScript` gets invoked for each call
(see org.jetbrains.kotlin.resolve.calls.CandidateResolver#checkOuterClassMemberIsAccessible)
And currently it may work for O(|top-level-declarations|),
that is rather slow e.g. for native stubs for gtk
#KT-17562 Fixed
This prevents .idea/kotlinc.xml from being added with an empty
ArgumentParseErrors object and also fixes
ConfigureKotlinInTempDirTest.testKotlincExistsNoSettingsRuntime11
BaseCompilerSettings.validateInheritedFieldsUnchanged() compares
old and new properties of the compiler settings, and the check requires
ArgumentParseErrors.equals() to be correctly implemented
By default we use the fast implementation in CLI compiler,
but in the most of the tests the old one is enabled
Also add tests on CompiledJava with the fast class reading
implementation
See org.jetbrains.kotlin.load.java.structure.impl.classFiles.BinaryJavaClass
as a counter-example, these classes may be used now in CLI too and they
aren't built upon Java PSI
It's only used for CLI compiler, and it should improve performance
of loading Java descriptors from class-files
For IntelliJ, it leads to 10-15% percent speedup of Kotlin Builder
Before this change, we were using a Java model based on Java PSI that
also read class files, but do it less effectively since it performs
some extra work, that we don't need, e.g. eagerly reading all
the inner classes
It seems to be very natural refactoring considering the
following changes: optimizing KotlinCliJavaFileManagerImpl.findClass
to make it read class files manually instead of requesting PSI
Also add a findInnerClass method that can find an inner class
by its name
This change helps to avoid loading all the inner class files
eagerly (that may be rather slow), while all the names are available
in InnerClass attribute
The reason is that canonicalText requires some additional
computations to be done when reading class files, while
in fact we only need a class name of the type
The reason is that searching for a class in a VirtualFile-based
directory (i.e. in a package) happens for O(|amount-of-files-in-dir|),
and it may be rather crucial for packages with a huge amount
of classes
Note that it was checked that the cache should not take a lot of heap
since we call findClass only for really existing classes:
see org/jetbrains/kotlin/load/java/lazy/descriptors/LazyJavaPackageScope.kt:48
For example, there are no more than 10k classes for the whole
intelliJ project (but the cache is flushed for each module)
It's important because even if we know the root where
the package is located we need to go through its parts,
and it's not as fast as it could be since implementation
of VirtualFile.findChild() traverse all files in the directory
to find the relevant one
Denis Zharkov