Expect declarations do not survive serialization to KLIB. So they need to be explicitly filtered in order for tests that compare dumped IR before and after serialization to pass successfully.
^KT-61136
Added a new FIR based checker for both FINITE_BOUNDS_VIOLATION and
FINITE_BOUNDS_VIOLATION_IN_JAVA errors. Implementation copied from the
existing descriptor based checker with some minor changes.
#KT-59378 Fixed
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
This change is required to fix stdlib compilation with enabled
linking via signature. All primitive iterators are considered to be
builtins and are created during compile time as deserialized
declarations (at least in K1). But if we meet the definition of some
primitive iterator in code, for example, during stdlib compilation,
we will end up with two different descriptors (deserialized and lazy)
that describe the same entity. Because of that we have conflicts in
symbol table:
* For descriptors, we will end up with multiple IR declarations
that describe the same class, but with different descriptors. With
some magic compilation still works.
* For signatures, we will end up with only one IR declaration in the
table, but it will have wrong deserialized (instead of lazy)
descriptor.
In the end, this change allows us to initialize iterators in advance
with correct descriptor.
#KT-56230
CompareDistributionSignatures task is used to compare Native platform
libraries contents against a previous version.
Under the hood, it runs the klib tool to get a library contents. But it
didn't check the exit code, so if klib tool failed, the task could
mistakenly indicate that there are no differences in platform libs.
Fix this by checking the klib tool exit code and failing if it is not
zero.
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
... for non-const properties.
The meaning of this flag for non-const properties is in reality not
well-established, and it can vary from one release to another. In
particular, it's different in K2.
This commit has two parts:
1) The test (added in 5891617674) about clinit is changed. Original
motivation was to check that presence or absence of `<clinit>` is not
a part of the ABI. However, in addition to that, the test also
involuntarily checked that the aforementioned "hasConstant" flag for
the property y/Object.y is the same in both cases (which I believe
was not the intention) because these tests check that Kotlin metadata
is _exactly the same_ after applying jvm-abi-gen. So I've changed it
to be more straightforward: one version declares an obvious constant,
while another declares an obvious non-constant. After this change,
the test started to fail (even on K1) because the value of the
"hasConstant" flag was different between two versions.
2) Remove "hasConstant" flag for non-const properties when transforming
metadata via jvm-abi-gen. This fixes the test and assures it won't
fail when the project is migrated to LV 2.0.
#KT-60849 Fixed
For implicit invoke operator calls, there are two instances of
`FirResolvedNamedReference`. One of them references `invoke` function
and cannot be used to analyze the property access, and the second one
has `source == null`. Luckily, the parent of the second reference is
`FirPropertyAccessExpression`, which has the correct source
^KT-60957 Fixed
Previously, the different number of statements has led to
some unexpected behavior. E.g., the resulting script can have
duplicated declarations – one from the original script instead of
some statement and one from the copy
^KT-60987
Dmitriy Dolovov