to ensure binary compatibility with stdlib inside IntelliJ.
This includes using the latest stable kotlin API version and
forbidding using experimental declarations from stdlib.
^KT-62510
In previous commit (K2: prefer derived class sources...)
we changed default source for callable copy (e.g. substitution override)
to its owner class. This can create an unexpected situation in LL API,
because normally KtCallableDeclaration is expected to be a source.
This commit introduces "compensation" on analysis API side.
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.
Ilya Kirillov