^KT-61573 Fixed
Review: https://jetbrains.team/p/kt/reviews/11969/timeline
Tests:
- MultiPlatformIntegrationTestGenerated
- CliTestGenerated
- MultiPlatformIntegrationTestGenerated
- DiagnosticTestGenerated.Multiplatform
- FirLightTreeOldFrontendDiagnosticsTestGenerated
Also add -Xexpect-actual-classes flag to all necessary ./libraries/* modules
Otherwise compilation of those modules failes because of `-Werror`
K2 IDE Plugin uses only a partial set of built-ins.
It only has declarations which are not present in
the JVM stdlib as classfiles.
Because of that, some major declarations like
`kotlin.Unit` are missing,
so resolution inside kotlin stdlib common modules does not work.
Because of incorrectly resolved stdlib,
highlighting and resolution in other files in the kotlin project does not work.
This commit adds source versions of stdlib declarations
(`/core/builtins/src/kotlin/`) to the common stdlib as a source-set
for IDE import.
This way all declarations in stdlib common module are properly resolved.
The approach might be incorrect as it might introduce possible redeclaration
conflicts between common and platform stdlib sources
as `/core/builtins/src/kotlin/` source-set is also registered as a source-set for
platforms.
^KT-59665 Fixed
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
It's better to have this logic in common place
(AbstractExpectActualCompatibilityChecker) to avoid missing compilation
errors in the future
This commit fixes:
1. Missing compilation error for actual function with default arguments
for 'actual typealias' KT-59665
2. Missing compilation error for actual function with default arguments
for actual fake-override KT-59665
Alternative solution for KT-59665 is to create a special checker.
"incompatibility" vs "special checker":
Arguments for common incompatibility:
- What if we had a rule that expect and actual default params must
match? If so then it certainly would be an incompatibility.
- Technically, we do the matching of expect and actual params (because
we allow default params in common ancestors of expect and actual
declarations).
- It's hard to check that the actual definition doesn't use default
params because `ExpectedActualResolver.findActualForExpected` filters
out fake-overrides and doesn't return them. It's not clear logic for
me, that I'm afraid to touch.
implicitActualFakeOverride_AbstractMap.kt test breaks if you drop this
weird logic
- WEAK incompatibilities can be considered as "checkers". So it doesn't
matter how it's implemented, as a "incompatibility" or a "checker"
Arguments against common incompatibility:
- Although we match expect and actual declarations to allow default
params in common ancestors of expect and actual declarations, it's
still can be considered that we check that the actual declaration
doesn't have default params. And it doesn't feel right that we check
correctness of the actual declaration in expect-actual matcher.
- ~~It may change the rules of expect actual matching~~ (It's not true,
because ActualFunctionWithDefaultParameters is declared as WEAK
incompatibility)
Exclude kotlin-stdlib-js project for JPS build. Related to KT-56106
#KT-61059 Fixed
Merge-request: KT-MR-11527
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
...other variants where it can be expected. Such as:
* commonMainMetadataElements (legacy metadata)
* metadataElements (klib metadata)
* nativeApiElements
This would prevent from leaking kotlin-stdlib-common dependencies of
older Kotlin versions. So every KGP configuration where
stdlib dependencies is configured automatically will enforce dependency
constraints on kotlin-stdlib-common.
^KT-61053 Verification Pending
- Specify disambiguating attributes in kotlin-dom-api-compat
compile dependency configurations
because it uses the flag that removes JS compiler type attribute
from all configurations and variants
KT-56106
Mikhail Glukhikh