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.
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.
instead of statically registering it.
Static registering can cause subtle errors when plugin implementation
(e.g. SerializationDescriptorPluginForKotlinxSerialization) is registered
from multiple classloaders: in multi-module with daemon compilation scenario
#KT-41857 Fixed
To be able to check descriptor's platform in frontend during plugin processing.
This is needed for serialization plugin because some synthesized descriptors (annotation interface implementation) must be JVM-only (or the Native compilation fails).
This decouples simple data (TargetPlatform) from other subsystem-specific
logic (like default imports, built-ins, etc.).
Aside from purely aesthetic improvements, it also makes it easier
to move 'TargetPlatform' into core (see next commits)
Use the version requierement table of the outer DescriptorSerializer
instance when serializing metadata for a class. Pass parent serializer
to DescriptorSerializer.create to make sure the correct table is used.
Serialize nested classes before the outer class in JS and common code,
to make sure requirements are not lost. Also, split
VersionRequirementTest to JVM and JS
#KT-25120 In Progress
Use type-safe keys in CompilerConfiguration instead of multiple parameters,
duplicated in the base class (JsConfig), derived class (LibrarySourcesConfig)
and its builder (LibrarySourcesConfig.Builder)
Will be used to store common compiler options (such as source version, inline
disabled, etc) as well as JS-specific options, to unify the logic of compiler
option initialization between JS and JVM compilers
- move enums and messages nested in Callable to top level, since they're likely
to be reused in other messages soon
- delete obsolete comments: some did not any value, some became obsolete with
custom options ("id in StringTable" -> name_id_in_table)
Refactor: no need to create package view in order to obtain its subpackages
LazyPackageViewDescriptorImpl to replace PackageViewDescriptorImpl
This allows to avoid computations when package views are requested but their contents not necessarily queried
For example: DescriptorResolver.resolvePackageHeader()
Ting-Yuan Huang