- `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
- `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
- remove ENABLE/COMPATIBILITY because they can no longer be used
- remove forAllMethodsWithBody because its behavior is now equivalent to
isEnabled
- inline isCompatibility
- inline DEFAULT
- rename ALL_INCOMPATIBLE -> ALL
Since the declarations generated by compiler plugins do not have proper
PSI (`classOrObjectDeclaration` in this case), we need to resort to
symbols for such declarations to compute the proper qualified name
^KT-65425 Fixed
...by honoring accessors' visibility
We need a special handling for backing field visibility,
e.g., lateinit, const, or JvmField, but that's not the case
for accessors' visibility.
^KT-64937 fixed
This MR fixes two independent issues causing build failures when using Kapt in combination with the Kotlin serialization plugin (and, very likely, with other plugins as well):
Kapt applied compiler plugins twice, causing errors similar to the one described in KT-65006
Kapt failed to generate @Metadata annotations for plugin-generated companion objects because the corresponding SLC missed containingFile needed for generation of method and class signatures
Merge-request: KT-MR-13970
Merged-by: Pavel Mikhailovskii <Pavel.Mikhailovskii@jetbrains.com>
We should provide valid getReferenceName as it is used
in many places (e.g. from com.intellij.psi.impl.PsiImplUtil.findAnnotation)
^KT-61605 Fixed
^KT-64605 Fixed
This commit introduces dangling file modules, which may be either
code fragments or ordinary Kotlin files. As before, code fragments are
analyzed against some context element, however ordinary files only
have a context module.
Code fragments can also have a dangling file module as a contextual one,
including other code fragment. This is done to support potential usages
in completion, intentions and refactorings.
We shouldn't build expect declarations as they do not
exist. We can omit check on member declarations as we
won't request them as we skip expect classes
^KT-57536 Fixed
Multifile-class can contain not only files from the same
module, but also files from the common part.
This commit also fixes KotlinByModulesResolutionScopeProvider as
it should provide all transitive dependencies
^KT-64714 Fixed
Previously we just skipped Java sources.
The order of classes in light classes test data is changed due to
differences in implementations of `compileLibraryToJar` and `runJvmCompiler`
^KT-62892
We should use PsiLiteralExpression instead of PsiLiteral as it
is used in the Java world. Effectively, `psiLiteral` property
already has this type (as `createPsiExpression` produce `PsiExpression`),
but we missed this part before and used just PsiLiteral for our
own class
^KT-63949 Fixed
When we check Java field for constant initializer, we could
be asked to get and check the type of Kotlin's property that
is used in this Java field. But there is no guarantee that the type
resolve phase was finished and this type is available. So we just
check for `const` modifier and skip type check.
#KT-63752 Fixed
#KT-62558 Obsolete
#KT-61786 Declined
Use test compiler runner to compile JS libraries. Determine compiler
by the specified TARGET_PLATFORM. Add tests for dynamic type and
JS-specific .proto extensions.
Refactor the code for mock library compilation to make the switch
between platforms more straightforward.
KTIJ-27566
KT-63217
Marco Pennekamp