Incorporate PR from Steven Schäfer into IrType-based implicit cast
insertion (commit 17b925636e8717e7648c5d7b792c6ab4d18f776d).
NB this still uses originalKotlinType to determine if the type was
nullability flexible. It is somewhat error-prone and something we want
to get rid of. However, it boils down to some design questions related
to implicit null checks in Kotlin - e.g., it might be Ok to just treat
nullability flexible type `T!` as `T?` in IR, generate null checks for
all usages of type `T?` where a non-null type is expected, and later
eliminate the null checks that are redundant according to the (quite
conservative) criterion in the redundant null check elimination.
Given an expression with SAM conversion, e.g.:
```
fun test(a: Any?) {
if (a is () -> Unit) {
Runnable(a).run()
}
}
```
Here `Runnable(a)` expects `a` to be a value of functional type
`() -> Unit` (and corresponding type check makes smart cast possible).
Relation between `Runnable` and `() -> Unit` is somewhat non-trivial,
is implemented in terms of KotlinTypes and DeclarationDescriptors,
and so should be encapsulated in psi2ir if possible.
Thus, psi2ir generates IR such as
```
TYPE_OP type=java.lang.Runnable origin=SAM_CONVERSION ...
TYPE_OP type=kotlin.Function0<kotlin.Unit> origin=IMPLICIT_CAST ...
[| a |]
```
and InsertImplicitCasts knows that IMPLICIT_CAST actually might be
unnecessary (which also allows to use InsertImplicitCasts in some other
context that might require IMPLICIT_CAST rewriting, such as inlining).
In 192 it's important to have service registered since
https://github.com/JetBrains/intellij-community/commit/f204718c885034bc2fa4be4b281ff4bbd5fa4ef4
Caused by: java.lang.IllegalArgumentException: Argument for @NotNull parameter 'value' of com/intellij/openapi/util/UserDataHolderBase.putUserDataIfAbsent must not be null
at com.intellij.openapi.util.UserDataHolderBase.$$$reportNull$$$0(UserDataHolderBase.java)
at com.intellij.openapi.util.UserDataHolderBase.putUserDataIfAbsent(UserDataHolderBase.java)
at com.intellij.openapi.util.NotNullLazyKey.getValue(NotNullLazyKey.java:41)
at com.intellij.lang.injection.InjectedLanguageManager.getInstance(InjectedLanguageManager.java:41)
at com.intellij.psi.impl.PsiCachedValue.isVeryPhysical(PsiCachedValue.java:74)
at com.intellij.psi.impl.PsiCachedValue.anyChangeImpliesPsiCounterChange(PsiCachedValue.java:57)
Reproduced with Fir2IrTextTestGenerated
Before this commit, implicit Unit type for function with body and
without type, implicit Boolean type for conditions etc. were 'implicit'
types and resolved types together.
Sometimes this could lead to hard-to-find issues in FIR resolve, because
'implicit' types are usually handled there as 'necessary to resolve'
which is wrong for such effectively-resolved types.
Profiling the compilation of kotlinx.serialization, MaxStackFrameSizeAndLocalsCalculator
causes ~7% of the runtime to be spent in java.lang.Object.hashCode
This is through two uses:
- visitMaxs(..) has a pushed hashSet that causes ~2%
- labelWrappersMap used to attach additional data to asm Labels, causes ~ 5%
visitMaxs can use the existing SmartSet (not to be confused with SmartHashSet)
Analysis of the visitMaxs HashSet creation & sizes:
| What | Amount |
| calls to visitMaxs | 4416 |
| max pushed | 158 |
| median pushed | 4 |
| average pushed | 5.20 |
| stddev pushed | 7.66 |
| 90 percentile | 10 |
Analysis of labelWrappersMap creation & sizes:
| What | Amount |
| ------------------ | ------ |
| hashtables created | 4006 |
| max entries | 175 |
| median entries | 5 |
| average entries | 6.10 |
| stdev entries | 8.28 |
| 90 percentile | 11 |
testing with a non hash based map using an array for keys and an array for values
showed that the cost of MaxStackFrameSizeAndLocalsCalculator became neglible to
the overall running time.
SmartIdentityTable is a Map like structure that uses reference identity for keys.
It uses 2 arrays to store keys & values until the number of entries stored is larger than 10.
At that point it switches to using an IdentityHashMap.
This structure can be used instead of HashMap when reference identity can be used and
the number of entries inserted is small (<= 10) on average, drastically reducing the overhead
of calls to Object.hashCode
Between the two changes, compilation of kotlinx.serialization through kotlinc
commandline decreased from 14 seconds to 11 seconds on my machine
Dmitry Petrov