Rely on the frontend weeding out cases that are not supported.
In psi2ir, introduce all the parameters before processing default
values.
Change the DefaultArgumentStubGenerator to generate code that
matches the behavior of the current backend.
Disable annotation rendering in default type and descriptor renderers.
Preserve annotations in Android and Serialization plugins.
Update error texts in ide tests.
Nullability annotations in Java descriptors are rendered with context-dependent renderer.
#KT-20258 Fixed
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.
Mikhael Bogdanov