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
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
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)
This commit includes the basic Java stubs generation infrastructure and
the corresponding tests. The main entry point is called
Kapt4StubGenerator. Calls to it from production code will be added in a
separate commit.
#KT-51982
As 'FirCodeFragments' are converted to IR independently of its context,
in some cases duplicate (and not quite correct) symbols for local
classes and functions are created.
Until properly fixed in fir2ir, here we replace such duplicates with
original symbols.
In the old JVM backend, local functions were compiled as JVM classes,
so there were an instance to pass around. Today, they are compiled to
static functions in the containing class/facade, and calls to them
compile natively.
Problem: transformSingle for expressions can return another expression,
and we should replace the original one with such new expression
^KT-61011 Fixed
^KT-61009 Fixed
The change in `FirPsiDiagnosticTestGenerated.Resolve#testCast`
only highlights the existing
problem that we don't assign a
valid type to `_`.
^KT-58906 Fixed
Roman Golyshev