Otherwise this brings incompatibility between kotlin-reflect 1.3.70+ and
kotlin-stdlib 1.3.60-.
This commit reverts the relevant parts of c164745301, 5c89f2fa54 and
896512f7cd.
Consider a call like `select(1, "")`, the resulting type for it is
Comparable<Int & String> & Serializable.
After variable fixation, the compiler incorporates this type into the
constraint system to check for a contradiction, so it checks
applicability of argument to the resulting type.
In other words, for the above call it checks is
`Comparable<Int & String> & Serializable` subtype of `IntegerLiteralType`?
Which ends up in checking is `IntegerLiteralType` subtype of `Int & String`.
Before this commit, such check was leading to the false result, but
because of losing diagnostic (which was fixed in the previous commit:
29f591b1), there was no error
Default type of LazySubstitutingClassDescriptor is not lazy. However, most of default types are,
and there is an optimization in KotlinTypeFactory, which uses default type for simple type without
type arguments and/or annotations. LazySubstitutingClassDescriptor's default type creates simple type
with factory, which may therefore cause recursion.
#KT-34029 Fixed
These fields were originally non-volatile because of an incorrect
assumption I had at the time that a value was safely published if the
underlying object's class has at least one final field. This is true for
almost all values used in lazy/lazySoft: DeserializedFunctionDescriptor,
DeserializedPropertyDescriptor, KTypeImpl, java.lang.reflect.Field, etc.
But of course, this only means that the object was _safely initialized_
and not safely published via the non-volatile reference, where other
threads can still observe null, even after that constructed object was
leaked to the outer world by some other means and led to observable
changes in behavior.
This can fix some concurrency issues in kotlin-reflect. I wasn't able to
reproduce the problem in stress tests though.
Before this commit, the substituted FunctionDescriptor didn't have a source element.
As a result, 'CodeFragmentParameterAnalyzer.isCodeFragmentDeclaration' failed to recognize such a descriptor as fragment-local, and it was erroneously captured.
Function return type can't and should not be used during overload resolution of callable references.
Since it can be DeferredType, its substitution in CS caused exception.
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
If the delegated property operators involved are inline, and delegated
property metadata parameter is not used (which is often the case, e.g.,
'lazy'), we can skip those properties in metadata generation.
NOT implemented: special case when only 'kProperty.name' is used by the
corresponding delegated property operators.
Also a sneak fix for KT-34060.
The changes introduced 471134d31e are only needed
for the case of HMPP project while for other cases it might break the behavior
a bit like in KT-34027
See org.jetbrains.kotlin.resolve.calls.results.OverloadingConflictResolver#filterOutEquivalentCalls
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 straightforward fixing of this exact call-site (using original descriptors)
doesn't help: behavior might change in a very subtle way (see org.jetbrains.kotlin.spec.checkers.DiagnosticsTestSpecGenerated.NotLinked.Dfa.Pos#test72)
So, the main idea is changing the contract for areCallableDescriptorsEquivalent
only when project is HMPP one.
^KT-34027 In Progress
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
move it into appropriate package and ensure that it gets relocated
properly in kotlin-reflect.jar
This change is needed to use the functionality that provides descriptors
from classloaders for scripts compilation.
Make ReifiedTypeInliner and related classes generic over the
KotlinTypeMarker subtype (KotlinType or IrType), add a typeSystem to get
arguments/nullability and other properties of types regardless of their
representation, but still fall back to KotlinType when generating the
actual bytecode of other intrinsics (as/is)
Alexander Udalov