^KT-62656 Fixed
I blindly converted all `@AllowDifferentMembersInActual` to suppresses.
But some suppresses in stdlib are redundant. I'm too lazy properly
annotate only the necessary places. All these suppresses will go away
after the bootstrap update anyway
I drop allowDifferentMembersInActual_class and
allowDifferentMembersInActual_typealias tests because their only purpose
was to check that `@AllowDifferentMembersInActual` works as expected
Note: some tests are failing in the compiler because of that. I will fix
them in the next 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)
Before this change `./gradlew help` (with native enabled)
Created immediately: 1322
Created during configuration: 1541
after this change:
Created immediately: 596
Created during configuration: 1509
To know more about configuration avoidance: https://docs.gradle.org/current/userguide/task_configuration_avoidance.html
^KT-58985 Fixed
Review: https://jetbrains.team/p/kt/reviews/10385
`isData` returns `true` for `data object`s even if kotlin-reflect
version is old (1.2.0), so it looks like we got correct `KClass.isData`
behaviour for "free". That's why this behaviour was never covered with
tests.
This commit updates the documentation and covers the behaviour described
in the KDoc with tests.
- return single instance of emptySet for build method from SetBuilder
- return single instance of emptyMap for build method from MapBuilder
- return single instance of emptyList for build method from ListBuilder
^KT-54739 fixed
Ilya Gorbunov