Compiler plugins can add new source roots to the next compilation round
by using `AnalysisResult.RetryWithAdditionalRoots`. Some plugins added
already existing source roots to this list in some cases. For example,
this is reproducible with `square/anvil` with incremental compilation
(KT-45100, KT-44925). Psi2ir didn't deduplicate the source files before,
which resulted in several classes with the same name linked to the same
symbol. This led to a "symbol is already bound" exception, and in case
of KT-44925, to an additional NPE when we were rendering the class to
display it in the message.
The solution is to deduplicate classes before psi2ir. Note that this
commit has two changes, in CLI and in psi2ir. Any one of these is
sufficient for fixing the problem, however both are made just to make it
more future-proof against new components and/or changes in existing
subsystems (e.g. fir2ir).
In the old JVM backend, similar deduplication was happening in
`ClassFileFactory.registerSourceFiles`, which is why the problem is not
reproducible there.
#KT-45100 Fixed
This breaks from the loop itself which is inconsistent with
what happens for breaks in while conditions.
Also, the frontend will report that code after the loop is
unreachable, which it isn't. :-\
However, those issues are covered in
https://youtrack.jetbrains.com/issue/KT-17728, so for now
we follow the old backend to not "break" anyone. :)
Fixes KT-44412
Also improve an error message in `IrType.erasedUpperBound`, which seems
like a frequent first place where the JVM IR backend crashes in case an
error type has made it past psi2ir.
This will help in diagnosing problems such as KT-45016.
Because generateDefaultGetterBody/generateDefaultSetterBody reference
the property's backing field, which in case of extension properties
leads to an error "Unbound symbols not allowed" because extension
property cannot have a backing field.
In some way, this check is similar to the `isExpect` check in
`generatePrimaryConstructor`.
Add a new module 'backend.jvm.entrypoint' which depends on psi2ir and
contains code that runs psi2ir + JVM IR backend with serialization
implementations.
Hopefully this will allow to compile these modules in parallel and
reduce the build time.
Move most of the implementation from JvmGeneratorExtensions to
JvmGeneratorExtensionsImpl. The latter implements
StubGeneratorExtensions from psi2ir, and doing so helps to remove direct
dependency on this part of psi2ir from backend.
Steven Schäfer