If some of builtin classes is declared in sources, trying to load it in
IrBuiltInsOverFir before fir2ir pass which generates IR for source
declarations will lead to creating lazy class instead of normal one
Without this change the following tests are failing:
- `FirLightTreeBlackBoxInlineCodegenWithBytecodeInlinerTestGenerated.Signature`
- `testByteIteratorWithWhileLoop`
- `testByteIteratorWithForLoop`
Accessing list of declaration may trigger lazy declaration list computation for lazy class,
which requires computation of fake-overrides for this class. So it's unsafe to access it
before IR for all sources is built (because fake-overrides of lazy classes may depend on
declaration of source classes, e.g. for java source classes)
So this OptIn is needed to carefully handle all cases of .declarations access in FIR2IR
A common platform builtin session before were created with `::wrapScopeWithJvmMapped`.
This required some other JVM session components to be registered.
We cannot register all JVM components in builtin session;
it would lead to problems like KT-62777.
So we use `::wrapScopeWithJvmMapped` only for true JVM sessions.
This commit fixes a test added in the previous commit for KT-62768.
^KT-62768 fixed
Added test `FirSourceLazyDeclarationResolveTestGenerated.Classes.testClassDelegatedInCommonCode`
now fails with another exception (KT-62772). It's fixed in the following commit.
^KT-62768 fixed
There was a case when we visited the same declaration multiple times
because of forward-referencing and visiting with designation
So because of this there were two changes required:
- remove assertion about visiting the same declaration twice (it's fine
since we don't actually resolve annotations twice)
- not skipping resolution of class children if annotations on this class
are already resolved
^KT-61388 Fixed
KT-62854
This print statement should either be delated, as I did here, or if it must be kept should be properly logged at an INFO level so that gradle builds that are at the WARN level do not see this.
Implicit receivers generally do not affect the resolution of types.
However, they generate scopes which might contain undesirable
classifiers, which can confuse reference shortener.
Dropping all the implicit receivers when dealing with type references
allows completely avoid such undesirable scopes instead of filtering
them by `instanceof` checks.
Also, temporary move `hasTypeParameterFromParent` check higher to the
`findClassifierElementsToShorten`, because ATM we don't know how to
properly decide whether to shorten the fully-qualified inner types
with implicit parameters or not (see KTIJ-26072).
^KTIJ-26057 Fixed
Split it to 4 functions for clarity: resolveFakeOverride,
resolveFakeOverrideOrFail, resolveFakeOverrideMaybeAbstract,
resolveFakeOverrideMaybeAbstractOrFail. Remove/inline duplicated
utilities and remove unused parameters.
- This adds KDoc reference resolution tests for callables in nested and
inner classes, overloaded functions, and private callables.
- Private declarations are visible in KDoc from outside their containing
classes. This is in line with K1 KDoc behavior.
^KTIJ-22324
- We should use member scopes to find symbols from supertypes.
- The issue was already fixed for static callables because the declared
member scope was composed with the static member scope. See
KTIJ-25960.
^KTIJ-26003 fixed
Mikhail Glukhikh