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
Basically, the former uses an old quickly-scrapped infrastructure,
which were not applicable for HMPP, so the latter tests were written.
So, both check for one and the same thing (highlighting in MPP projects),
but MultiplatformAnalysisTest is more modern,
and has a lot of inconvenient stuff in MultiplatformHighlighting fixed
^KT-43116 Fixed
Smartcasts for public properties from different module are not
stable because module declaring a property in general can be
compiled separately from the module using it. However, if client
module has dependsOn relation with declaring module their simultaneous
compilation is guaranteed which makes this smart cast safe.
Cache all transitive 'expected by' modules in module dependencies.
Extend test to check smart casts are allowed for properties from transitive
'expected by' dependencies and prohibited otherwise.
^KT-42754 Fixed
#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
This problem is only relevant when isTypeRefinementEnabled == true (HMPP projects)
Ambiguity accidentally was removed after 471134d
There, for areCallableDescriptorsEquivalent we stopped assuming
as impossible a situation of having identity-different descriptors
in the same containing declaraton that still might be considered equal
So, before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration.
But some of the usages expect that it also makes sure that descriptors
have the same substitution (see org.jetbrains.kotlin.resolve.calls.smartcasts.IdentifierInfo.Variable#equals)
So, the straight solution is using original descriptors for the cases
where we need to make sure that descriptors relates to actually different
declarations
^KT-34027 Fixed
Now, call 'configureDefaultCheckers' and 'configureExtensionsAndCheckers'
from all childs configurators, instead of taking just container from
CommonPlatformAnalyzerServices
This is needed because some IDE services tend to re-create containers
(in particular, PerFileAnalysisCache and ResolveElementCache do that to
re-inject new trace) and use usual injection DSL, which, in particular,
takes 'platformSpecificContainer'.
Returning 'common'-conatiner leads to losing all platform-specific checkers.
On the other hand, calling exactly 'configureDefaultCheckers' +
'configureExtensionsAndCheckers' should be correct, because that's how
single-platform 'platformSpecificContainer' is composed (see
PlatformConfiguratorBase), and in 'createContainerForCompositePlatform'
we don't use 'platformSpecificContainer' anyways
^KT-23305 Fixed
Note that Native built-ins are not resolved correctly in this module
(CPointed and similar). This is not a bug, but rather a technical
limitation of the current testing infrastructure: we can't depend on
kotlin-native stdlib in "big-Kotlin" repo, and native stdlib is used as
the only one source of Native built-ins.
Pavel Kirpichenkov