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
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
Motivation:
- Functions with prefix "are" must return Boolean. And
AbstractExpectActualCompatibilityChecker even already contains some
functions with prefix "are" that return Boolean (e.g.
`areCompatibleCallableVisibilities`,
`areCompatibleSupertypesOneByOne`, etc)
- Unification with functions that are prefixed with "are" and return
Boolean
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
For StrongIncompatible `actual` declaration is considered as overload
and error reports on expected declaration. For WeakIncompatible the
error is reported straight away
Before the refactoring `areCompatibleClassScopes` returned just
`Incompatible`. It is bad because StrongIncompatible isn't possible for
classes (classes can't be overloaded). Now all class incompatibilities
are weak.
The commit has a minor impact on observable behavior (cases where we
reported the compilation problems are still reported but on another
elements):
- We no longer report type parameter class incompatibilities on expect
declaration, we report them only on actuals (it happened because all
WeakIncompatible are reported only on actuals)
- In a sense, Java implicit actualization was the only way to "overload"
classes (it would be a redeclaration compilation problem, so it
doesn't count as a valid "overload"). And since type parameters
incompatibility was StrongIncompatible for classes, we counted them as
"overloads" and didn't report incompatibility problems on Kotlin
class. Now we do report. (see
implicitJavaActualization_multipleActuals)
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
Extract main logic of `areCompatibleCallables` into two functions:
`areStrongIncompatibleCallables` and `areWeakIncompatibleCallables`.
The main point is that `areStrongIncompatibleCallables` &
`areWeakIncompatibleCallables` have very specific return types.
This commit doesn't change any logic. The commit makes the API more
type-safe ensuring that bugs like in previous commit (KT-60902) won't
happen again
^KT-60902 Fixed
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
We should prioritize to return STRONG incompatibilities over WEAK
incompatibilities. But this invariant broke in `areCompatibleCallables`,
because `areCompatibleTypeParameters` returns incompatibilities of both
types, and `areCompatibleTypeParameters` is called in WEAK
incompatibilities section.
The fix is to split `areCompatibleTypeParameters` into two functions:
`areStrongIncompatibleTypeParameters` and
`areWeakIncompatibleTypeParameters`. And call each of this function in
appropriate `areCompatibleCallables` sections.
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
This is a preparation refactoring for the following KT-60902 fix and
type-safety refactoring.
This commit doesn't have observable side effects (and can be called pure refactoring) because the following conditions:
1. `expectDeclaration is ConstructorSymbolMarker && actualDeclaration is ConstructorSymbolMarker`
2. `expectDeclaration is FunctionSymbolMarker != actualDeclaration is FunctionSymbolMarker`
can't be both `true` at the same time
This is needed to workaround broken incremental compilation in JPS in
Kotlin plugin. The incremental compilation bug is reported KT-60759
In Kotlin plugin I created the same commit which changes the name of the
function on the call-site.
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
After a few days in master branch, I will revert this commit
^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)
* Use type_layout to declaratively express heap object headers in both
custom allocator and ObjectFactory.
* Invoke constructor (w/o invoking Kotin constructors) for created
objects and arrays from both custom allocator and ObjectFactory.
Previously:
- custom allocator only checked body for nullability (now this is
performed in body constructor)
- ObjectFactory only constructed ObjectData
* In each GC have a AllocatorImpl.hpp and ObjectData.hpp headers
the first encapsulating allocator-specific types, the second
containing specific ObjectData implementation.
* In each GC have a separate ObjectFactoryTraits that does not
actually depend on the specific GC anymore.
* Each GC now expose ObjectData (as undefined type) and its descriptor,
the latter being used by the custom allocator and ObjectFactory.
* Descriptors for ObjectBody and ArrayBody now live in Memory.h and the
code calculating size is now shared. Their constructors check that the
memory is zeroed (Kotlin constructors will expect this).
This is needed because after changing default language version to 2.0,
we still need to test many scenarios from this test in K1.
Move K1-specific tests to OldCompileKotlinAgainstCustomBinariesTest, and
K2-specific tests to FirCompileKotlinAgainstCustomBinariesTest.
Mute failing K2 tests via `muteForK2`. It will throw exception if the
muted test will suddenly start passing.
This test uses multiple features which are obsolete and will be
discontinued soon:
- Language version 1.4
- Expect/actual declarations in the same module
- Declaring inline classes via "inline class"
Check that the client code compiles against the "broken" classpath
instead. Descriptor text dump is a part of the obsolete test
infrastructure and should not be used anymore.
`DelegatingConstructorCall` -
because in this case there is
either `UNRESOLVED_REFERENCE` or
`SYNTAX` already.
`ErrorTypeRef` - because in this
case there is `SYNTAX` already.
Note that there is only 1 test
that shows this behavior, and
it's LT-specific. It's
`FirLightTreeOldFrontendDiagnosticsTestGenerated.testKt847`, and
in this test the string template
is parsed and processed
differently in LT and PSI:
- in LT there are 6 nodes: "",
"$this", " must be", "$as", "$t",
"".
- in PSI there 4 notes: "$this",
" must be", "$as", "$t".
Because of KT-50547, this test doesn't work on Windows with HMPP
enabled.
Previously, because of that HMPP was disabled for all samples.
But now disabling HMPP is no longer possible, so ce9a45b enables HMPP
for samples.
Disable echoServer sample on Windows to workaround ^KT-50547
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>
Dmitrii Gridin