This problem is only relevant when isTypeRefinementEnabled == true (HMPP projects)
Ambiguity accidentally was removed after 471134d
There, for areCallableDescriptorsEquivalent we stopped assuming
as impossible a situation of having identity-different descriptors
in the same containing declaraton that still might be considered equal
So, before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration.
But some of the usages expect that it also makes sure that descriptors
have the same substitution (see org.jetbrains.kotlin.resolve.calls.smartcasts.IdentifierInfo.Variable#equals)
So, the straight solution is using original descriptors for the cases
where we need to make sure that descriptors relates to actually different
declarations
^KT-34027 Fixed
The actual problem was introduced in 4f1e85b468, note how `hashCode` is implemented:
```
var currentHashCode = cachedHashCode
if (currentHashCode == 0) return currentHashCode
...
```
It's a silly bug, there should be check `if (currentHashCode != 0) ...` because `0` is used a marker for "uncomputed value".
Now, in the commit 0219b86d06 I added map with `KotlinType` as a key and because of constant `hash` for `KotlinType`, we basically got `List` instead of `Map`, which caused this performance regression
#KT-34063 Fixed
Alternative message for errors, caused by unexpected lambda expression arguments on a new line.
Both diagnostic are reported, if multiple lambda expressions were passed to the call.
For other errors trailing lambda diagnostic overrides the original one.
Quickfix for erroneous trailing lambdas on a new line after call.
Fix separates lambda expression from previous call with semicolon.
All trailing lambda arguments become standalone lambda expressions.
Previously, ResolverForProjectImpl had multiple callbacks in
constructor. Some of those callbacks were used only to overcome module
visibility and provide an ability to inject IDE-specific logic into
compiler (ResolverForProject is in the 'compiler'-module)
This commit introduces abstract class which implements
environment-independent logic (previously, this logic had been stored in
ResolverForProjectImpl) with several abstract met hods (previously,
callbacks). Then, we provide few concrete implementations of
AbstractResolverForProject with clear semantics:
- IdeaResolverForProject: resolver used in IDE, where we have indices,
oracles, multiple modules, etc.
- ResolverForSingleModuleProject: resolver for project with only one
module, commonly used for CLI compiler/tests
- one anonymous implementation for MultimoduleTests
This refactoring achieves several things:
- now it is easier to see what kinds of ResolverForProject you might see
in some particular environment (previously, one had to inspect all
call-sites of constructor)
- we can easily add IDE-specific logic in IdeaResolverForProject without
adding noisy callbacks (which most probably wouldn't have any other
non-trivial implementations)
Use the class of the subtype of CharSequence when available. When
it is not (for type parameters bounded by CharSequence) call the
CharSequence getter and 'get' method. Using the most specific type
posible fixes the forInStringSpecialized test that expects the
use of INVOKEVIRTUAL and not INVOKEINTERFACE.
Add tests for the type parameter use.
This was missing for IrFunctionReferences, which caused problems when
copying default parameters before CallableReferenceLowering in the
JVM_IR backend.
They are currently marked as defined even when they get a
default implementation. That makes it hard to figure out
if the accessor should be removed when introducing a backing
field in the JVM_IR backend.
Any access to a function from a multi-file part needs to be replaced
with the access to the corresponding public method (if it exists) from
the facade class. Note that this has no immediate effect because we use
KotlinTypeMapper for mapping calls, and it understands that a call to a
function from the part must actually be generated into a call to the
function from the facade in the bytecode. This commit merely changes the
IR to better reflect what's generated in the final bytecode, and to be
able to use simplified IR-based method signature mapping instead of the
legacy KotlinTypeMapper in the future.
There are two parts in this change:
1) Previously, we looked up $default methods with the incorrect
signature in supertypes. For example in defaultInSuperClass.kt, we'd
try to find a method foo$default with the signature `(B, String,
String, int, Object)` in the class A. Now we're modifying the array
of parameter types on each step if we're looking for a static
$default method, by assigning its first element to be the containing
class. This fixes cases when defaults come from a superclass.
2) For interfaces, $default methods are actually located in the
corresponding DefaultImpls class. Now we look up that class and
search for the $default method there. Note that this is needed
because of KT-33430. This fixes cases when defaults come from a
superinterface.
#KT-13936 Fixed
Denis Zharkov