Instead, check the refiner from the DI-container or refiner from
capability of a module descriptor.
The reason is because in the IDE there might be multiple
ResolutionFacades (-> multiple DI-containers -> multiple module
descriptors) for one and the same IDE module, with different refinement
settings.
However, due to how the code is written, it's hard to have
different LanguageVersionSettings for one and the same module.
After this commit the refinement settings are determined by the
moduleDescriptor capabilities, which is much easier to tweak
See usage of that change in Kotlin IDE Plugin (commit is linked to the
YT issue)
^KTIJ-20775
- Correctly set explicit receiver value.
- Restore original function call from FirImplicitFunctionCall (i.e.,
calls implicitly resolved to `invoke`) to get the correct name for
getting all candidates.
- Collect candidates at all tower levels.
Also make order of candidate calls in tests deterministic.
- Output ES modules instead of plain files
- Support -Xwasm-launcher=d8 for d8 shell used in tests and benchmarks.
- Reuse launcher generation logic in CLI and box tests runners.
- Create separate output directory for each box since
there are multiple output files generated for each test.
- Stop using absolute paths in generate JS files
to simplify running generated code on different machine
- Remove ">>>" from println output
Merge-request: KT-MR-5729
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
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
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
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.
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).
- 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
[JS IR] Fix compilation in tests
[JS IR] Fix test after migrating IC to compiler
[JS IR] Fix memory leak
[JS IR] Move js ic to compiler
Merge-request: KT-MR-5673
Merged-by: Ilya Goncharov <Ilya.Goncharov@jetbrains.com>
Dmitry Savvinov