See the comment at updateSubstitutedMemberIfReceiverContainsTypeVariable
It became necessary after delegate inference is rewritten, since before
that happened, stub types were being left there and FIR2IR handled
them accidentally properly because stub types are equal to anything.
But that wasn't really correct even there because stub types are not
intended to leak out of the FIR
^KT-61060
The main idea is getting rid of stub types and using just type variables
See more detailed description at docs/fir/delegated_property_inference.md
The problem with stub types is that they need really special treatment
in many places, and on the other hand, there are no clear contracts on
how they should work (that regularly leads to bugs like KT-59529)
^KT-61060 Fixed
^KT-61075 Fixed
^KT-61077 Fixed
^KT-59529 Fixed
^KT-61633 Related
^KT-61618 Related
^KT-61740 Related
^KT-59107 Related
^KT-61747 Related
^KT-61077 Related
^KT-61781 Related
Optimization in 2439c22ff6 introduced an array `absentArguments` with
default values of all parameter types, which is copied in `callBy`
instead of being recomputed each time. Unfortunately, its size was
computed incorrectly: `maskSize` should only take into account
value parameters (see the `parameter.kind == KParameter.Kind.VALUE`
check in `callBy`).
This led to an issue where if the function had 32 * N value parameters
and 1 receiver parameter, `maskSize` was greater by 1 than expected,
which caused an exception due to mismatching argument array sizes.
#KT-61304 Fixed
In order to properly analyze top-level property initialization, a
control-flow graph must be created for FirFiles. This change adds the
foundation for the file CFG and updates body resolve to create the CFG.
Checking the CFG for proper initialization is separated into a following
change to ease code review.
KT-56683
fixup! Fix `isKotlinFunctionWithBigArity` function
Fix `isKotlinFunctionWithBigArity` function
Previous implementation could return false positive results, e.g. for
class named `abacaba.kotlin.Function42`
^KT-61548: Fixed
Merge-request: KT-MR-11928
Merged-by: Vladislav Grechko <Vladislav.Grechko@jetbrains.com>
The only case when erasure matters in a context of materialization of
`PromisedValue` is when the type is a type parameter which upper bound
is an inline class. Since `PromisedValue::materializeAt` is a hot spot
and `eraseTypeParameters` is an expensive operation, we should not do
type erasure in other cases.
Reporting it for `VIRTUAL_MEMBER_HIDDEN`
is ok, because `VIRTUAL_MEMBER_HIDDEN`
has always been an error, so we are
allowed to treat these as overrides
implicitly.
^KT-59408 Fixed
^KT-59419 Fixed
^KT-57076 Fixed
If some function is not fake-override, then its type should be just
default type of containing class
For fake overrides the default type calculated in the following way:
1. Find first overridden function, which is not fake override
2. Take its containing class
3. Find supertype of current containing class with type constructor of
class from step 2
^KT-60252 Fixed
This change uncovered the following problem in pipeline: we have a contract,
that all bodies will be generated after all fake overrides will be preprocessed.
But DataClassMembersGenerator generates bodies before f/o creation,
which leads to the problem, if data class has forward reference to some
class which was not processed before (because in this case generator
of `hashCode` function will try to reference f/o, which is not created yet,
which leads to `SymbolAlreadyBound` problem)
```
data class Some(val a: A) {
generated fun hashCode(): Int {
return a.hashCode() // (1) is not generated yet
}
}
class A {
fake-override fun hashCode(): Int // (1)
}
```
This problem will be fixed in the next commit
(related test is compiler/testData/codegen/box/ir/kt52677.kt)
^KT-60924
single builder parameter
single postponed type variable
single origin of type information
relevant issues:
KT-60719
KT-60720
KT-60855
KT-60877
KT-60880
Currently, there is only attribute `ExpectForActualAttributeKey`
where mapping is stored only for source declarations with `actual`
modifier. But we need mapping of all class members, including classes
which were actualized via `actual typealias` or fake override members.
This data will be needed for the annotation checker in subsequent
commits.
^KT-60668
^KT-60936
Disabling the language feature is supported,
otherwise there are too many tests that
would need to be updated to account for
K2's inability to do it.
The `ifConstVal.kt` test is deleted,
because now it must also be ignored in K2,
and since it is ignored for both the
frontends, and the ignored backends
include all the target backends, this test
is basically unused.
Note that now both the frontends report
`CONST_VAL_WITH_NON_CONST_INITIALIZER`.
for `condition`.
^KT-55196 Fixed
It's possible to write a fix that
would prevent false positives with
this checker, but the core
intuition behind it is invalid.
This checker assumes that it's
enough to only check direct
overriddens, while in reality
even simple `Source` override
functions are not allowed to
contain default values, so they
can't be used to make judgements
about them.
^KT-59408 Open
^KT-59408 Open
^KT-61095 Fixed
^KT-61165 Fixed
^KT-61029 Fixed
IrSetField was transformed to its value to preserve side effects
This transformation produced invalid IR in cases where
IrSetField used in Unit-returning expression context.
This commit fixes it by producing Unit-typed expression
^KT-59084 Fixed
This fixes a KMP issue where IrActualizer would add duplicate
fake overrides because the parent class would have both the getter
and the synthetic property in its list of declarations.
Now, the synthetic property fake overrides are still generated and
cached in the Fir2IrDeclarationStorage, but not added to the class.
#KT-60854 Fixed
When detecting function delegation at the last statement position we
need to make sure that delegating call has unit return type, otherwise
we would try to return non-Unit value from a parent function returning
Unit
^KT-60700 Fixed
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
^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)
This change covers the case where some f/o was generated in common module
and it is referenced in platform code. But signature of this f/o may be
different in different modules because of e.g. actualization of value
parameters with actual typealias
^KT-60850 Fixed
Alexander Korepanov