Adds new warning diagnostic that checks that selected Xcode version is not higher than latest tested with the current Kotlin version
^KT-62373 Verification Pending
The expected format was Kotlin language version (e.g. `2.0`), however the actual passed values were Kotlin release versions (e.g. `2.0.0`)
^KT-65986 In Progress
This diagnostic is reported in rare situations when
StubTypeForBuilderInference is kept as a parameter type
of for loop or lambda. Before this commit, we had in K1
"Could not load module <error module>" from IrLinker instead.
Related to: KT-52757, KT-53109, KT-63841, KT-64066
#KT-53478 Fixed
All dependencies should be registered before the Backend::associate().
^KT-65429
Merge-request: KT-MR-14616
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
This issue should warn users about possible problems in K2 compiler.
Because in this setup there will be no symbols visibility between
those source set roots as it used to be in K1.
There is an assumption that this case usually appears in the code
generation setup. And users might not experience any problems before.
^KT-64913 Verification Pending
- The module structure for these tests was set up backwards: We should
keep the test module kind of the main module flexible (as it is
configured by test configurators), but keep the module kinds of the
binary libraries fixed.
^KT-65960
^KT-64994
- The name wasn't specific enough.
- Remove default `emptyList()` argument from `CompiledLibraryProvider`
so that passing `dependencyBinaryRoots` isn't missed. (My changes
didn't include it in `KtLibraryBinaryModuleFactoryBase` yet, but it
was actually missed from `KtLibrarySourceModuleFactory` even in the
original commit.)
^KT-65960
^KT-64994
- The test infrastructure already requires test modules to be properly
ordered regarding dependencies, so a module A which is a dependency
for a module B must always be ordered before B. Hence, it makes no
sense to also order modules topologically.
- Reordering modules may cause the resulting `KtTestModule`s to be
out-of-order with the test modules, because the topological order
might be different from the test module order, even if the dependency
relationship already holds in the original order.
`KtTestModuleProjectStructure` requires the same ordering as test
modules to ensure the same order during iteration of `KtTestModule`s.
^KT-65960
^KT-64994
- Since binary libraries don't carry decompiled files anymore, the
static declaration provider doesn't index binary libraries in the
Standalone mode, where we don't use stub-based deserialization. This
led `LLSealedInheritorsProviderFactoryForTests` to fail in Standalone
mode for sealed classes from binary libraries, as this provider is now
populated from the declaration provider's index (see the previous
commit). Luckily, class-based deserialization sets
`sealedInheritorsAttr`, so we can simply use this attribute.
^KT-65960
- Now that binary libraries are decompiled to stubs instead of PSI
files, we cannot collect sealed inheritors from `KtFile`s anymore.
Since all `KtFile`s and binary library stubs are both indexed by the
declaration provider, we can collect inheritors from its index
instead.
- Invalidating all sessions at the end of `prepareSealedClassInheritors`
fixes some improper resolve phases in lazy resolution test data. While
the previous implementation requested an uncached resolve session, it
didn't account for sessions of dependencies still being cached.
^KT-65960
- Instead of indexing binary library declarations from decompiled PSI,
the static declaration provider now builds and indexes stubs. As noted
in KT-65960, this brings IDE mode tests much more in line with
decompiled stubs indexing in the IDE. It should allow us to catch
issues with the stub-based deserialized symbol provider outside of IDE
tests.
- In the Standalone mode, we can skip stub-indexing completely, as we
provide FIR symbols via class-based deserialization. This also extends
to shared binary roots.
^KT-65960 fixed
- `LibraryBinary` should not contain any decompiled files, as we want
FIR symbols in tests to be provided from indexed stubs or class files,
but definitely not from decompiled PSI. This brings `LibraryBinary`
much closer to the behavior of binary libraries in the IDE.
- Some tests may still require access to a decompiled file, for example
when trying to test `getOrBuildFir` for some `KtElement` coming from a
library. This commit introduces `LibraryBinaryDecompiled`, which
does contain decompiled files.
- We don't really need `LibraryBinary` as a main test module kind
anymore, since tests generally want to access some main `KtFile`.
Hence, test configurators for `LibraryBinary` have been turned into
configurators for `LibraryBinaryDecompiled`.
- An alternative would be decompiling files on demand, but this is not
currently feasible because the Standalone API doesn't reconcile stubs
with decompiled PSI, like the IDE does automatically. (For the same
declaration, the stub and the PSI will have a different identity.) As
long as there is no support for this, we'll have to rely on a separate
test module kind.
^KT-65960
- `TestModule.explicitTestModuleKind` requires a directive to be present
to get the `TestModuleKind`. But we still want to find out the test
module kind for test modules without a directive. Hence, we have to
add this property to `KtTestModule` during its construction.
^KT-65960
- `KtModuleWithFiles` isn't actually used in a production Standalone API
context, but it was exposed via `analysis-api-standalone-base`. In
current production usages, the project structure is built with the
module builder DSL.
- Hence, `KtModuleWithFiles` is only relevant for tests. This commit
moves `KtModuleWithFiles` to the Analysis API test framework and
renames it to `KtTestModule`. This removes any risk that an outside
user could start using `KtModuleWithFiles` and completely uncouples
the test project structure from production APIs.
- In addition, we can add the `TestModule` to `KtTestModule`, allowing
tests to quickly access the original test module, for example to check
the test module kind.
- The commit also removes the data class status of `KtTestModule` and
`KtTestModuleProjectStructure` to avoid issues with destructuring when
properties are added or removed.
^KT-65960
- The configuration allows the test infrastructure to decide whether to
index binary libraries to stubs (when stub-based deserialized symbol
providers are used) or to skip indexing (when class file-based
deserialization is used).
- The information is needed in `AnalysisApiBaseTestServiceRegistrar`,
where the `KotlinStaticDeclarationProviderFactory` is created. This
service registrar shouldn't access `LLFirLibrarySymbolProviderFactory`
and so checking the library symbol provider factory wasn't an option.
- Another alternative was adding a property to
`AnalysisApiTestConfigurator`. However, this then requires passing the
property to `AnalysisApiBaseTestServiceRegistrar`, because it doesn't
have access to the configurator out of the box. This however goes
against the design of our service registrars, which generally only
access test services. So adding a test service seemed like the best
solution.
^KT-65960
When a symbol X from a binary library A uses another symbol Y from
another binary library B, `LLFirDependenciesSymbolProvider` cannot
resolve Y for X. This is because the existing
LLFirAbstractSessionFactory passes symbol providers for only builtin
libraries to `LLFirDependenciesSymbolProvider` even when the session has
dependencies. As a result, when `LLFirDependenciesSymbolProvider`
searches a symbol, it can find only symbols from the builtin libraries,
but it cannot find a symbol from libraries other than builtin libraries.
This happens only for the binary libraries.
^KT-65240 Fixed
Andrei Tyrin