If new inference is enabled only for IDE analysis, then this feature
will be disabled to reduce difference between new and old inference,
but if new inference is enabled in the compiler, then this feature
will be enabled too to preserve behavior of new inference for
compilation
#KT-32175 Fixed
#KT-32143 Fixed
#KT-32123 Fixed
#KT-32230 Fixed
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
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
This is a large commit, which introduces general API for working with
abstraction of Platform.
- Add new abstraction to 'core' - SimplePlatform - which represents
exactly one platform
- Clients are strongly prohibited to create instances of SimplePlatform
by hand, instead, corresponding *Platforms abstraction should be used
(e.g. JvmPlatforms, JsPlatforms, KonanPlatforms)
- Move TargetPlatform to 'core', it represents now a collection of
SimplePlatforms
- Clients are strongly encouraged to use TargetPlatform
(not SimplePlatform) in API, to enforce checks for multiplatform
- Provide a helper-extensions to work with TargetPlatform
(in particular, for getting a specific component platform)
- Remove MultiTargetPlatform in favour of TargetPlatform
- Notably, this commit leaves another widely used duplicated abstraction,
namely, IdePlatform. For the sake sanity, removal of IdePlatform is
extracted in the separate commit.
Up-to-date check is very heavy for intellij repo due to artifact size.
If module directory in repo is written only by one task we can assume
that task if up-to-date if target directory exists.
Inline function descriptor in derived class represented as FAKE_OVERRIDE.
So we should find it in base class declaration
(not interface cause inline function can't be virtual, but always final)
and then check class version.
#KT-29402 Fixed
Declare AnalysisFlags in module 'frontend', and JvmAnalysisFlags in
module 'frontend.java', to avoid leaking Java-related logic to common
compiler code
This is effectively a revert of
447c127036, which was an (incorrect) fix
for KT-22379.
The bug was that we've cleared data-flow info for assigned variables
*after* knowledge that loop condition if 'false' was applied (we can
claim that if loop has no jump-outs). Therefore, we broke smartcasts in
the innocent code like that:
var x: Int? = null
while (x == null) {
x = readPotentiallyNullableInt()
}
// x should be non-null here
Commit reverts that "fix" for 1.3.0 and postpones deprecation until 1.4
KT-22379 Open
KT-27084 Fixed
Mikhail Zarechenskiy