in annotations if underlying type is not nullable reference type.
Previously, it worked only for inline classes with primitive
underlying type and nullable reference type.
#KT-44133
before checking whether they use the KProperty parameter. (Otherwise the
body is empty and the check always says that the parameter is unused.)
^KT-48825 Fixed
They may or may not be inlined later.
IDK how the test passes when both modules are compiled with the old
backend - perhaps this has something to do with the fact that when `f`
is compiled with the IR backend, the call to `x()` is followed by `pop`
and `getstatic kotlin/Unit.INSTANCE`? This is probably why the original
issue in kotlinx.coroutines reports that everything works fine with
kotlinx-coroutines-core:1.4.3.
^KT-46879 Fixed
^KT-48801 Fixed
The only way to make the compiler compile several modules with a
dependency loop is via the "build file", given by -Xbuild-file and used
in the JPS (IntelliJ built-in build system) plugin.
For the old frontend/backend it works like this: we _analyze_ sources of
all modules once, as if it's one big module, and then for each module,
we _generate_ (invoke backend) only sources of that module. Backend
needs to be invoked separately per-module because every module has its
own destination directory specified in the build file.
For JVM IR, this separation into just two steps, analyze and generate,
was problematic because there's psi2ir, which works like frontend, in
that it needs the global analysis result to be able to create and link
IR correctly. So, in case of JVM IR, we need to run psi2ir on the whole
module after analysis and before generation.
In this change, psi2ir is run on the whole module via
`CodegenFactory.convertToIr` (which does nothing in the old backend),
and then parts of the resulting IR module are extracted according to the
original separation of the combined module into individual modules via
`getModuleChunkBackendInput` by matching IrFile against KtFile. And
then, backend is run for each such module.
#KT-45915 Fixed
#KT-48668 Fixed
Consider the following code:
```
fun test(a: List<String>) {
a.first()
}
```
The dispatch receiver type of `first` in this case is `List<T>` before
this change. After this change, it's `List<String>`.
In addition, this change also replace the dispatch receiver type with
the more specific type if available. For example, consider the following
```
class MyList: ArrayList<String>()
fun test(a: MyList) {
a.get(0)
}
```
The dispatch receiver type of `get` is `MyList`, instead of
`ArrayList<String>`. That is, a fake override is created in this case.
Also change
org.jetbrains.kotlin.fir.types.TypeUtilsKt#hideLocalTypeIfNeeded to skip
approximating anonymous objects if there are multiple super type refs so
that resolution behaves the same (for uncompilable code).
Note that this change does not implement check for
ApproximateAnonymousReturnTypesInPrivateInlineFunctions as the check is
already turned on in 1.5 and will likely not needed when FIR becomes
stable.
Keeping the origin as LOCAL_FUNCTION_FOR_LAMBDA was a mistake as this
tells codegen nothing. Changing the origin in allows, for example,
removing the hack that detaches inline lambdas from the IR tree before
verification and codegen, or treating inline lambdas and inline
anonymous functions the same way.
This includes fake functions created for inline callable references.
#KT-48319 Fixed
#KT-47279 Fixed?
ProhibitAssigningSingleElementsToVarargsInNamedForm is enabled from 1.3
so there is no need to make FIR accepting single element passed through
named arguments.
In addition, we may want to report only
ASSIGNING_SINGLE_ELEMENT_TO_VARARG_IN_NAMED_FORM_FUNCTION and not arg
type mismatch. But FE1.0 is reporting both so I am following it. If we
want to remove the redundant report, we will probably want to remove
FirNamedVarargChecker and report during resolution as a cone diagnostic.
Difference from FE1.0
* KT-4285: calls to virtual method with default argument should be
reported as not tailrec. FE1.0 is missing such cases.
* KT-48600: calls inside lambda should be reported as not tailrec. FE1.0
also misses such cases.
Their call sites are all in the same file, so we can check whether the
declarations used in the inline function are accessible from all the
places where it will be inlined.
#KT-48736 Fixed
Mikhail Glukhikh