Otherwise, it will throw exception like:
```
IllegalStateException: No 'FirJvmTypeMapper'
```
Anyway, PsiType is JVM conception, so it is not supposed to be used
outside the JVM platform
^KT-60318
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
Originally it was named createModuleFragmentWithSignaturesIfNeeded, because
there was a counterpart `...WithoutSignatures`. Now that function has
gone and there is only one entrypoint left
It is true that for vararg parameter `arrayElementType` always have to
be not null, but it required resolution to TYPES phase. But in case of
the error type, the type reference is treated as resolved, so we are not
obligatory to resolve such reference to TYPES, because we already have
the resolved type.
So we can make the rule of KtFirValueParameterSymbol#returnType less
strict, and varargElementType will effectively do the same as
lazy resolve + arrayElementType
^KT-61422 Fixed
- revert some accidental changes in
`findSmallestElementOfTypeContainingSelection` function (see 48433bf9)
- simplify `dropFakeRootPrefixIfPresent` by using `tail`, add a new
test-case to check that it works
- simplify `findClassifierElementsToShorten` by not passing lambdas and
calling a common functions instead
Deprecate `unusedImports`, since they are supposed to be computed
on the IDE side from now on based on the information from
Analysis API
Currently the `unusedImports` property is not removed completely
so it can still be used by the Kotlin side import optimizer
tests; they should be moved/adapted to the intellij repository
also
Correctly handle `KtDotQualifedExpression`s with function calls as
selectors (like `foo.Bar()`). Without such handling, processing of
member invoke calls on objects was broken both
for reference shortener (causing KTIJ-26695)
and import optimizer (causing KTIJ-23407)
Also, to fix KTIJ-23407, do not ignore qualifiers with
`ImplicitInvokeCall` fake source
^KTIJ-26695 Fixed
^KTIJ-23407 Fixed
Also adds rendering of @Metadata annotations in Kapt3 and Kapt4 tests
(currently disabled for a few tests).
Co-authored-by: Alexander Udalov <alexander.udalov@jetbrains.com>
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
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
^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)
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.
Dmitrii Gridin