This makes it a bit more apparent, in profiler snapshots, where
parameter types are really needed. Also, hopefully it will improve
performance somewhat in cases where types are not needed.
For example, before this change about 1/3 of the time of
`DefaultArgumentStubGenerator.lower` on JVM was actually computing types
of parameters from dependencies, even though the actual types were not
needed, only the presence of defaultValue was used. This made it the
most time-consuming lowering phase on JVM.
After this change, default argument lowering is thus 50% faster, however
this time is in part distributed among other lowerings that visit the
whole override hierarchy for all methods and really need the types of
parameters, e.g. BridgeLowering, SyntheticAccessorLowering. So the
profiler snapshots are now more "honest".
When resolving a name that is used as a receiver and all
candidates are classifier symbols, we need to perform
qualifier resolution. The code used to only do that for
regular classes, and would not perform qualifier resolution if
there was a type alias candidate.
^KT-51171 Fixed
We do not know for sure if there is any dependency between the
two classes passed to `checkIsInheritor`. To avoid the problem described
in KT-51240, we try to analyse them both and hope that the dependency
in some direction exists.
`NoCacheForModuleException` is introduced to signal about this
particular problem and avoid catching just any `NoSuchElementException`.
This hack is mainly done to fix very annoying KT-51240 for the time
being.
^KTIJ-20852 Fixed
Otherwise, when the function has inline class parameter, we get ICE.
We do not get the error without inline class parameter, since we
substitute type parameters in limited situations, which includes
inline class lowering.
#KT-51157 Fixed
This will rely on a task called `prepareKotlinIdeaImport` which,
if present, will be invoked by the IDE before import.
Co-authored-by: Sergey Igushkin <Sergey.Igushkin@jetbrains.com>
Merge-request: KT-MR-5688
Merged-by: Sebastian Sellmair <Sebastian.sellmair@jetbrains.com>
In the Android eco-system, there are jars with entries with a
versionNeededToExtract of 0. That should probably have been 10,
but will be hard to fix. This change proposes to just check
that the versionNeededToExtract is between 0 and 20.
Parameter names of some methods are different in JVM IR, for example
extension receivers of property `$annotations` methods are named
`<this>`, which made the `Name.identifier` call fail. It seems fine to
use the "p + index" name for this instead.
#KT-49682
Behavior differs between JVM and JVM_IR backends here because in JVM,
the class descriptor comes from the frontend, and its modality for enum
is never final. For JVM IR, the class descriptor is based on IrClass,
whose modality is sometimes final for enum, presumably because it's
easier for backends (see `ClassGenerator.getEffectiveModality`).
#KT-49682
Similarly to the other places in the IR backend (e.g. see
`copyValueParametersToStatic` in the same file).
In JVM IR, these names are used for example for receiver parameters of
methods copied to DefaultImpls classes. Since Java stub code generated
by kapt mentions them, it fixes a few issues in tests on kapt + JVM IR
(KT-49682).
All of these have a different order of declarations and/or extra
`@NotNull` annotations on fields, both of which doesn't seem like a
problem.
#KT-49682
Since all anonymous types are approximated to a supertype in kapt, type
mapping doesn't require backend information (mapping of anonymous types
to class names) and can be performed statically, independently from
particular JVM backend internals, via descriptorBasedTypeMapping.
#KT-49682
- Include stdout & stderr dump to the exception message if the Java
command fails
- Support running JVM_IR tests
- Do not print anything to the stdout of the test itself in case it's
successful
#KT-49682
The test expects to track block result lifetime in Swift, so we should
add it to the tracker.
Also fix the same problem for testReceiveBlockFromKotlinAndCall
(which didn't fail because we added the block itself to the tracker).
- Clean up BuildCacheRelocationIT.testKotlinIncrementalCompilation
- Delete BuildCacheIT.testKotlinCompileIncrementalBuildWithoutRelocation
as it is already covered by the test in BuildCacheRelocationIT
- Add BuildCacheRelocationIT.testKotlinIncrementalCompilation_withClasspathSnapshot
- Updated BuildCacheRelocationIT.testKotlinIncrementalCompilation_withClasspathSnapshot
Alexander Udalov