Previous attempt was at 6807ed6642, but it was reverted in 7771e5914d
(see that commit for the explanation). Now it should be fine to remove
these version requirements.
No issue reported because it's mostly not a user-visible change. The
main effect is that it reduces differences in metadata between K1 and
K2, namely it fixes the ValueClass.kt kotlinp test.
K1 uses `Any?` in `transformSuspendFunctionToRuntimeFunctionType`, so
use `Any?` in K2 too.
This type is not used for anything, it's just an artifact of how suspend
types are represented in metadata. It's removed during deserialization
(see `TypeDeserializer.createSuspendFunctionType` or
`FirTypeDeserializer.createSuspendFunctionType`). So it's not a
user-visible change. The only effect is that it reduces differences in
metadata between K1 and K2, namely in the test
`libraries/tools/kotlinp/testData/ValueClass.kt`.
Language feature InlineClasses is enabled since 1.3. The current lowest
supported language version is 1.4, so any compiler that can read
binaries produced by the current compiler also supports inline classes,
which means that the version requirement is not needed anymore.
No issue reported because it's mostly not a user-visible change. The
main effect is that it reduces differences in metadata between K1 and
K2, because K2 never supported writing this version requirement properly
due to the TODO in `hasInlineClassTypesInSignature`.
KGP supports only Gradle since 6.8.3, and we run tests on
buildserver only since this version, so we shouldn't try to work if
gradle < 6.8.3.
And in general in MPP plugin we shouldn't support version that is not
supported in KGP
#KT-59278
Do not try to find PSI element, but always use the IR element offsets
instead. This greatly simplifies test data because we don't need to have
custom PSI- and LT- based diagnostic ranges in every test, and K1/K2
behavior also is mostly the same.
The exact offset ranges are not as important for backend diagnostics, so
it's better to have K2+PSI and K2+LT behaving the same.
Specifically, the case when not all parts of a multifile class are
annotated with `@JvmSynthetic`. Report the error on the
`@JvmMultifileClass` annotation instead of the package directive,
because the latter is difficult to find via IR. This fixes the test
FirLightTreeDiagnosticsTestWithJvmIrBackendGenerated.MultifileClasses.testJvmSynthetic.
#KT-59586
This fixes the following
FirLightTreeDiagnosticsTestWithJvmIrBackendGenerated tests:
testPropertyInlineCycle
testInlineCycle
testSuspendInlineCycle
testIndirectInlineCycle
#KT-59586
In the vast majority of tests, diagnostics are reported at a slightly
different location in LT vs PSI. This is because in the light tree mode,
backend errors are reported basically on the start of the IR element,
which is for example the keyword "class" for a class and not its name as
in K1 or in K2+PSI. Similarly, the end of the diagnostic is at the
ending offset of the IR element.
Normally it would be a bit user-unfriendly to highlight the whole class
as red, starting from the keyword "class" and ending with the closing
brace "}". But remember that these are backend diagnostics in the K2+LT
mode, which is only possible in the compiler scenario, not in the IDE.
And in this case, the ending offset doesn't matter at all because it's
not presented to the user, and minor change in the starting offset is
not a problem as well.
There are some tests which legitimately fail in the LT mode because the
corresponding diagnostics haven't been supported. They will be dealt
with in subsequent commits:
testPropertyInlineCycle
testInlineCycle
MultifileClasses.testJvmSynthetic
testSuspendInlineCycle
testIndirectInlineCycle
#KT-59586
In the compiler, 'FirLazyDeclarationResolver' assumes
'lazyResolveToPhase()' appear only during code analysis. So there is
a check that requires calls to be wrapped with 'startResolvingPhase()'
and 'finishResolvingPhase()'. Checkers and backend are run on fully
analyzed code, so there is no need in calling 'lazyResolveToPhase()'
in the first place.
In the IDE, however, it's impossible to analyze all code in a project
before running the backend. Generally, it's not a problem as files that
are explicitly passed to the backend go through all FIR phases.
'IrBuiltInsOverFir', though, perform symbol lookups, so unresolved-yet
declarations might appear.
In the IDE, there might come declarations from other files/modules
that we link against, but not pass to the backend. As only declarations
from the compiled files end up being in the cache, the consistency check
should be relaxed.
In the IDE, it's impossible to pass classes from all modules to the
backend, so symbols for 'external' source declarations need to be
generated ad-hoc.
Such declarations do not go through the lowering phase, including one
that replaces the containing package fragment with a facade class.
In the IDE, there might come declarations from other files/modules
that we link against, but not compile. Type parameters are one of such
declaration kinds.
In the IDE, FIR declarations for libraries are built on top of binary
stubs. This helps to improve memory usage significantly, as Protobuf
metadata isn't loaded all the time. However, the containing file type
for stubs is different.
Alexander Udalov