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.
Relates to KT-8834, we continue reducing differences between old and new
inference. Note that as for `SamConversionPerArgument`, this feature
is enabled in the compiler and not in the IDE to avoid breaking code
for those users that already enabled new inference in the compiler
Bug was introduced in b99efb because of lack of tests.
All code in `AbstractTypeCheckerContextForConstraintSystem.extractTypeVariableForSubtype`
related to IN projection looks suspicious and needs further investigation
There was an inconsistency on creating PSI call and corresponding
descriptor. See variable `catchBlocks` from visitor, it's created
only if PSI elements are not null, but for descriptor parameters
there wasn't such check
#KT-32134 Fixed
#EA-139748 Fixed
Consider call `foo(bar())` where bar() returns some type variable `T`;
We had a contract that call `bar` can be completed without completion
of foo (type variables can be inferred from the current context) if `T`
has at least one proper lower constraint (ProperType <: T).
Indeed, new constraints can be added only as upper ones, so there is
no need to grow constraint system.
Unfortunately, we have Exact annotation that is used on return type of
elvis. Now, consider the following situation:
```
fun foo(a: Any) {}
fun bar(e: T): @Exact T
foo(bar("str"))
```
Here, because of Exact annotation, constraint with `Any`-type will be
added as an equal one => our prerequisite that there will be no new
lower constraints is false. `bar("str")` is inferred to Any in OI,
this seems conceptually wrong, but it's another topic of discussion.
In NI we can't just grow constraint system to use outer call because
of another important use-case:
```
fun <T> generic(i: Inv<T>) {}
fun test(a: Inv<*>?, b: Inv<*>) {
generic(a ?: b)
}
```
Common constraint system for these two calls can't be solved
(fundamentally) for this example, only if (a ?: b) and generic(result)
are computed separately.
So, to mitigate initial issue, we'll grow constraint system only if
there is at least one non-proper constraint.
#KT-31969 Fixed
This commit doesn't change behaviour of any inference algorithm, it
introduces opportunity to switch constraint system that is used for
overload resolution and fix problematic cases by changing one enum
entry.
Due to fundamental changes, there are cases where a new inference
algorithm reports overload resolution ambiguity errors (#KT-31670,
#KT-31758), which is correct from its point of view. However, this is
a breaking change and to really make it, we should be very confident
and have enough motivation for it, therefore, we don't change behavior
now in order to collect more examples (if there are any). And if we
find a lot of erroneous examples, we'll be able to change the behavior
quite simply
It's enough to have at least one good constraint.
Note that the whole algorithm can be a bit more general:
we could check also Out<T>, In<T> and verify that T has good only
lower constraint or upper constraint, but there are questions for
types like Inv<Out<T>>, where T should have lower and upper constraints
#KT-31514 Fixed
There is added a new service named `SubstitutingScopeProvider`, that
provides factory that creates captured types and approximator for them.
In OI they are the same as before commit, for NI they are empty, because
that approximation interferes with NI algorithm
That service is injected into function descriptors and property descriptors
and used for creating `SubstitutingScope` with correct services
Also there is changed time when we approximate captured types in NI
(after all call checkers)
#KT-25290 Fixed
Mostly, these optimisations are picked from the old inference.
Also, remove exponential complexity for flexible types in approximation,
note that more correct fix for this would be to introduce new types
that corresponds just to platform types to avoid nullability problems,
but due to complexity it will be done later
#KT-31415 Fixed
There is an inconsistency between old and new inference for storing
receivers of resolved calls. In new inference, for captured types,
receiver will be changed and to preserve behavior of the old inference,
we use original one during important checks.
This is more a workaround than a solution and should be revisited.
#KT-31356 Fixed
#KT-29948 Fixed
#KT-31360 Fixed
Pavel Kirpichenkov