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.
This solves no immediate deficiency, but is a to-do that arose as part
of an ongoing effort to port the old, slightly too restrictive
checkLocalVariableTable tests to the more "functional" debugger
infrastructure.
This just shaves a little bit of overhead off the test expectations
and couples them less tightly to the specifics of the test
infrastructure.
Dynamically calculating a year is problematic, especially in cases like
FIR where generation happens in every build. When you are working on a
last year's commit, each build creates a bunch of uncommited
changes of updating the year in copyrights.
Fix built-ins for JVM platform and make them consistent
with module's dependency on standard library. Changes
don't affect non-JVM platforms.
Previously all built-ins in IDE were loaded from classloader
and were based on the same pre-serialized .kotlin_builtins files.
This approach is generally not correct as built-in declarations
differ for different platforms, but it had been working for a while
without immediately observalble effects (see KT-33233 for more info).
After changes in standard library JvmBuiltins started producing
false errors (see KT-39728).
To fix this, JVM built-ins in IDE now utilize the same technique as
applied in CLI: using dependency on standard library as a module
for built-ins instead of artificial module that considers only
.kotlin_builtins.
Change summary:
- Provide JvmBuiltins with kind FROM_DEPENDENCIES
for all modules with stdlib dependency in IDE
- Add JvmBuiltinsPackageFragmentProvider to JVM-ish module resolvers
(JVM and Composite with JVM platform) to support their use as
built-ins module
- Create KotlinBuiltInsMetadataIndex file index for tracking libraries
containing .kotlin_builtins to support JvmBuiltinsPackageFragmentProvider
- Create KotlinStdlibIndex file index for tracking kotlin-stdlib(-common),
which looks for "Kotlin-Runtime-Component" manifest attribute
- Add caching service to track LibraryInfo for kotlin-stdlib(-common)
- Put LibraryInfo for kotlin-stdlib(-common) alongside SDKs
due to the need to resolve that modules in BuiltInsCache
- Update BuiltInsCache to separate JvmBuiltins by module's dependency
on stdlib and JDK
- Make platform of KotlinSDK common instead of JVM
- Set built-ins module lazily in IDE
^KT-33233 Verification Pending
There was a warning on line 78
(`diagnosticsToJspecifyMarksMap[diagnostic.name]`) which unconvered that
the map wasn't used in the same way in both call sites.
This commit includes:
- test runners for foreign annotation tests
- minor changes testdata related to changed directives syntax
- dropping tests with javac integration: old javac tests actually ran
compiler without javac because of bug in configuration, so some
nullability annotations features are not supported in javac mode.
It's fine to drop it since javac mode is not fully supported
by compiler
Vladimir Ivanov