Such as:
- PackageFragmentProviders, and, in particular,
CompositePackageFragmentProviders
- JavaPackageFragments
- Scopes produced by those providers
The rationale is that a lot of frontend-facing bugs (like red code) are
easily recognizeable in resolution. But at that point you just see a
bunch of scopes, without meaningful toStrings, you don't know who has
produced them, and what's exactly wrong.
With this commit it should make debugging slightly easier: now at least
you'll be able to see that "this scope is a scope of package fragment
for foo.bar of module baz" and decide whether the declaration should or
should not have been resolved from such scope.
Add extension point for java descriptors
Add simple usage of this point to generate getter method
Add simple test infrastructure to test compilation with lombok plugin
AnalysisHandlerExtension allows compiler plugins to:
1. Intercept and override the default analysis.
2. Utilize the compiler infrastructure to do custom analysis.
A well know plugin on the JVM platform is KAPT.
Before this fix, if some imports were not resolved during compilation,
this result had been saved in caches, and this import couldn't been
resolved during following compilations even if it was added to the
module dependencies. This commit adds special handling of resolution
caches for the REPL compiler.
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
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.
Extract a service interface out of ControlFlowInformationProviderImpl
and register its implementation in two "leaf" modules: 'cli',
'idea-core'.
This improves parallel build, since a lot of modules depend on
'frontend' but only these two modules reference the implementation and
thus depend on the full CFA implementation now.
This is needed in order to have a single convenient place where to
register frontend services implemented _outside_ of the 'frontend'
module, such as the control flow analysis, extracted to a separate
module in a subsequent commit.
Dmitry Savvinov