Previously, composed checker passes the `allXXX` flavor of checkers to
each category of checkrs. This makes the composed checkers
non-transparent: behavior changes after composing. In addition, nested
composing would create redundant checkers.
As a result, some checkers registered in the IDE mode
(org.jetbrains.kotlin.idea.fir.low.level.api.diagnostics.AbstractFirIdeDiagnosticsCollector)
are not invoked with the FIR plugin.
This change does two things:
1. pass on checkers to composed checkers without combining
2. use combined checkers in DeclarationCheckersDiagnosticComponent and
ExpressionCheckersDiagnosticComponent
Specifically, the report the following 4 errors.
* NON_VARARG_SPREAD
* ARGUMENT_PASSED_TWICE
* TOO_MANY_ARGUMENTS
* NO_VALUE_FOR_PARAMETER
Also added/updated the following position strategies.
* NAME_OF_NAMED_ARGUMENT
* VALUE_ARGUMENTS
Currently, FIR reports errors caused by previous resolution failure. For
example with unresolved `a` and `b` in code `a.b`, both `a` and `b` are
highlighted. FE1.0 only highlights `a` since it's the root cause. This
change applies this heuristics when reporting FirDiagnostics.
Similarly to FIR diagnostic tests. This commit enable all available test
data and check the reported error messages by FIR. This helps identify
some issues in formatting of FIR diagnostics.
The changes on the test file are mechanically generated. Failed tests
are disabled with `// IGNORE_FIR` and are re-enabled in the second
commit.
From now on sealed declarations get resolved with the help of
FirIdeSealedHierarchyProcessor. This change entails correct IDE side
check for sealed when exhaustiveness.
For a vararg parameter type, there corresponding FIR element has a fake
source of kind ArrayTypeFromVarargParameter. As a result,
`getOrBuildFir` returns the whole `FirValueParameter` for the parameter
type reference. Therefore, we need some special handling for this case
in order to resolve the proper `KtSymbol`.
The main purpose is to show that old frontend and FIR work differently
in the case of the conflicts of local and top level classes/objects
See the tests that marked with // IGNORE_FIR
Corresponding ticket is ^KT-45192
Note that LazyClassMemberScope actually has a separate field for
KotlinTypeRefiner, and it might be actually different from the one in
c.kotlinTypeChecker.
The one in c.kotlinTypeChecker is the refiner of *owner* module, i.e. a
module in which the class has been declared. If we have a class Foo :
Expect in common, then the refiner will be from common, and thus it
won't be able to refine supertypes to their platform-dependent values.
The one passed in constructor is actual refiner of dependant-module.
Say, if we're looking at Foo from the point of view of jvmMain, then
we'll create a (view-dependent) LCMS for that, and it will contain
refiner for jvmMain.
It is important to use proper refiner, otherwise the idea of having
"module-dependent view" breaks, and we might suddenly mismatch some
overrides with expect-classes in their signatures.
^KT-44898 Fixed
yantimirov-timur