In some cases, 'LLFirProvider' doesn't return the existing class, e.g.
when the class is inside the 'kotlin.' package but when the
'-Xallow-kotlin-package' flag is not passed.
This fixes the test 'DiagnosisCompilerTestFE10TestdataTestGenerated.
TestsWithStdLib.testInaccessibleInternalClass()'.'
The old 'FirProviderInterceptor' is too invasive, ad-hoc, and only a
few places in the compiler are aware of it.
This fixes the test 'FirOnAirResolveTestGenerated#testOnAirTypesResolve'
which started failing after the designation path collection refactoring.
The newly appeared class existence check started to fail:
```
val declaration = firProvider.getFirClassifierByFqName(classId)
check(declaration != null)
```
Indices are not available in the IDE for files outside content roots,
and the newly introduced 'PsiFile' can be used for searching
classifiers instead.
`INVISIBLE_REFERENCE` may be reported due to CandidateApplicability via
a ConeDiagnostic, or in a checker. The former leads to
`FirErrorResolvedQualifier`, so the checker is not called.
This makes little sense, because CandidateApplicability may result in
`NO_COMPANION_OBJECT`, which would prevent other more meaningful
diagnostics from being reported (like `API_NOT_AVAILABLE`).
If we run checkers for `FirErrorResolvedQualifier` we may get duplicate
`INVISIBLE_REFERENCE`. The change in the checker prevents it.
Callable symbols with SinceKotlin are filtered out by a
resolution stage, but in K1 classifiers and property accessors
report API_NOT_AVAILABLE. K2 filters out properties with
unavailable accessors, but does nothing for classifiers.
This change fixes it.
^KT-54410 Fixed
^ KTIJ-24373
when resolving selector expr of a dot qualified expression,
parent qualified expression is resolved
see `KtFirCallResolver.getContainingDotQualifiedExpressionForSelectorExpression`,
Fir is filled with the data. Then,
during final mapping from Fir -> psi, one need to perform the opposite:
take `selectionExpression` to get the initial KtCallExpression
It's done by hardcoding the task classes unlike to approach with other build services (with adding interfaces like Uses<blah-blah-service>), because the J/S services are subject to rework in a short time. This way earlier task initialization shouldn't cause problems.
#KT-56131 Fixed
Included builds will still resolve using a regular
ArtifactMetadataProvider (but using a ProjectComponentIdentifier).
Such dependencies shall not try to go through cinterop metadata
transformation. Right now commonized dependencies from
included builds will just not be visible/exported to the
consumer builds.
Using cinterop declarations inside the API surface will
not be enabled until more stability guarantees for cinterops can
be provided
^KT-56115 Verification Pending
Yan Zhulanow