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
It doesn't matter because this built-ins instance will be used only to
get names of default imports, so nothing can be resolved to those
built-ins => no diagnostics will be reported
- KtClassLikeSymbol.primaryConstructor was removed
- Constructors were removed from getCallableMembers because
constructors has no name (or special name `<init>`) and previous
implementation was incorrect
- KtScope.getAllSymbols returns constructors as before. Before it was
like this because of the incorrect implementation of getCallableMembers
- getConstructors has sence only for class scope,
for the rest cases it is empty
This visibility is used for some cases where it isn't allowed to access
to private members of the object from other instances of the same object
because of the type parameter variance.
For almost all clients this visibility is the same as PRIVATE
So far, quick-fix tests infrastructure neither supports the check
for multiple files (several .before/.after pairs) nor multi module
structure. Provided tests are quite limited yet allow to make sure that
the fix in question appears in expected context and get activated.
^KT-44043 fixed
Exclude modules where there are still warnings in an explicitly declared
variable `tasksWithWarnings`.
Also remove "-progressive" from compiler arguments in modules which are
built with non-latest language version, as the warning about that leads
to an error with -Werror.
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.
Use the position in the source file if possible, and
only if the members are coming from other source files,
use their name and descriptor. This is necessary in order
to ensure deterministic output in clean and incremental
runs, while preserving the order of members in the sources.
This PR makes sure we have following cases covered for :compileKotlin,
:kaptKotlin, :kaptGenerateStubsKotlin tasks.
1. incremental change + input relocated
2. incremental change + input not relocated
This is so AGP does not try to apply AndroidX substitution
to dependencies found in the annotation processor classpath.
AGP does this by checking if the configuration name starts
with "kapt".
Test: Kapt3Android42IT
Nikolay Krasko