LightParameterListBuilder, as a subtype of PsiParameterList, is good
enough for LightMethod's parameter list abstraction. However, it does
not have a parent link, which bothers upward conversion in UAST
(a.k.a. convertParent APIs). So we need an abstraction similar to
KtLightParameterList (in FE 1.0 LC).
This additional API and changes in CInteropCommonizerDependencies.kt
will make sure, that test source sets will still receive commonization
results, even when the exact targets are not requested by
any of the main source sets.
^KT-48138 Verification Pending
The dropped condition is bad, since source sets like 'commonMain'
might still participate in a 'compileKotlinMetadata' task,
which is not a shared native compilation.
It is absolutely okay to just rely on the return of
'getCommonizerTarget': If a shared commonizer target is returned,
then the source set is guaranteed to be a shared native source set.
^KT-48118 Verification Pending
This commit fixes:
```
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/intellij/jps/impl/JpsIdePluginManagerImpl has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
```
New tests `testHmppLibAndConsumer` and `testMultiModulesHmpp` were added
The first is a test with MPP library and its consumers, it checks import
and also highlighting before and after the library was published
The second is a project which contains three multiplatform modules and
two platform modules and checks import and highlighting.
Original commit: https://jetbrains.team/p/ij/repositories/intellij/revision/15582b03530eba4fa0e3d0b512bb0a4c1fa3aa4c
FE1.0 only reports SENSELESS_COMPARISON if one of the operand is `null`.
This change makes FIR reports also in case one of the operand has type
`Nothing?`.
In addition, fix handling of type alias in ConeTypeContext#isNullableType
In order to make resolution still work for members not available from
`Nothing`, we track the type without `Nothing?` and use that for
resolution instead.
The logic should clear back aliases as well. To ensure all back aliases
don't lose any information, statements on the original variable are
copied over to its aliases.
Previously, if user compares an `it<String, Int>` with `String`, the
checker reports it since the flattened types `[String, Int, Int]` are
incompatible. But technically, before flattening, the intersection type
actually contain the other side, so they should really be compatible.
Jinseong Jeon