Introduce *CommonizedCInterop & *CommonizedCInteropElements configurations
and fix CInteropCommonizerTask to consume dependencies / expose artifacts
via these configurations.
There were remaining configurations in legacy JS projects with amiguous attributes requesting kotlin-stdlib. They are not used in build, but resolved on import.
IC caches often contain file paths. To make them relocatable, we need
to convert these file paths into relative paths, relative to a base
directory.
- If the file paths are source files, we can use the root project
directory as base.
- If the file paths are class files, we should use the classes
directory as base (before this commit, we used the root project
directory in both cases, that's why we hit KT-58547).
The key changes in this commit include:
- RelocatableFileToPathConverter: converts paths to relative paths
- IncrementalCompilationContext: contains 2 different path converters,
one for source files and one for class files
- SourceToOutputFilesMap: maps source files to class files using the
above path converters
- IncrementalCompilerRunner: creates the path converters based on file
locations
Test: RelocatableFileToPathConverterTest unit test
SourceToOutputFilesMapTest unit test
BuildCacheRelocationIT.testCustomBuildDirectory integration test
^KT-58547 Fixed
IDEA sync is always launched with equivalent of `--stacktrace`, so
checking startParameter.showStacktrace is unreliable.
This commit instead mutes printing of stacktraces in sync unless the
internal property is specified. If users want stacktraces, they're
expected to launch Gradle task with `--stacktrace`.
In the extremely rare cases where the stacktrace is needed
*specifically* during IDE sync,
`kotlin.internal.diagnostics.showStacktrace=true` can be used
^KT-61172
We expect that some configurations might fail to resolve in the case of
stdlib-js dependency if they are resolved explicitly. These configurations
should not actually resolve for the KGP user.
^KT-60901
^KT-61126
This will prevent transformed kotlin-stdlib source sets from
being resolved for leaf (e.g. jvmMain) as well as bamboo (jvmBambooMain)
source sets. For such source sets only the jvm jar shall be attached
^KT-60901 Verification Pending
Let ConeCompositeConflictResolver pass the results of the previous
resolver to the next one.
Otherwise, we get false positive conflicts when a set of candidates
can't be fully reduced by one resolver but could be resolved by the
subsequent application of multiple ones.
This change makes ConeCompositeConflictResolver order-dependent and
thus, ConeOverloadConflictResolver must be invoked last, because it
must work on a pre-filtered list.
Also, let ConeEquivalentCallConflictResolver use
FirStandardOverrideChecker instead of compareCallsByUsedArguments
because it's stricter.
This all fixes a false positive overload resolution ambiguity in common
metadata compilation that is caused by stdlib using the new KMP
format.
Now stdlib metadata is in the classpath, and so declarations from the
stdlib are returned from both MetadataSymbolProvider and
KlibBasedSymbolProvider.
This isn't a problem per se because duplicate candidates are filtered
out by ConeEquivalentCallConflictResolver (K1 works analogously), but
in the case of top-level functions with generic receivers like
Collection<T>.toTypedArray, the check failed because of the direct
comparison of receiver types.
#KT-60943 Fixed
- Mention link to docs about templates in warning messages
^KT-60491 Fixed
- Make sure that each warning mentions some way to solve the problem
aside from disabling default template
- Fix small syntactical bug in code sample
- fix incorrect indentation in trimMargin after joinToString
- Use kotl.in in Kotlin12XMppDeprecation
^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>
This helps to completely get rid of Visitors API during reading and writing
of the JVM metadata.
Note: Klib writers still use .accept and left for future refactorings.
See also #KT-59442
Rewrite Readers.kt and Writers.kt to avoid using
Visitors API
Align KotlinCommonMetadata/KotlinModuleMetadata API with
KotlinClassMetadata one (it is necessary for restructured reading/writing)
#KT-59442 In Progress
...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
Anton Lakotka