Some implementations of definitelyDoesNotContainName method were
missing that led to performance problems during symbols resolution
using TowerResolver.
Relates to KT-39139.
* The new idea-frontend-independent module created
* Moved KtReference and it inheritors to that module & implement them in idea-analysis module by using descriptors frontend
Resolution anchors are IDE-specific.
Creating dedicated methods for them in AbstractResolverForProject leads to meaningless
implementation in non-IDE resolvers. Now this method is implemented only
for IDE resolver and accessed through JvmPlatformParameters.
#KT-24309 In Progress
- Replace leaking ModuleResolverTracker with use of ModuleDescriptor.Capabilies
- Provide API for retrieving ResolverForProject from ResolutionFacade
- Update names
A mechanism that allows kotlinx.serialization plugin to preserve the
correct (program) order of properties after serializing/deserializing
descriptors to kotlin metadata, which is needed for correct and stable
json serialization of class hierarchies in incremental/multi-module scenario.
It uses protobuf extensions.
There are multiple ways to declare a named variable-like entity in
Kotlin:
1. val/var variable declaration
2. destructuring declaration
3. parameter of a function
4. parameter of a lambda
5. destructured lambda parameter
6. for-loop's variable declaration
7. catch block exception declaration
8. val in when
9. field declaration
Out of them, only variable and field can be assignable, in other words,
they can be on the left hand side of an assignment.
Val/var variable declarations were already supported.
So, we needed to just support field initialization and tell the backend
that other ways are prohibited. Function and lambda parameters were
already been supported. So, the only thing to explain to the backend are
remaining ways.
#KT-39113 Fixed
#KT-34048 Fixed
Fix compilation errors, revealed by this fix.
SmartCastManager is unnecessary for error reporting, intermediate diagnostics from the NI contain all required infromation.
When SmartCastManager is used it leads to missing unstable smart casts in case of expressions with captured types.
This happens, because data flow info is recorded for original expression without captured types, which is used as a key.
DataFlowValues created from receivers with captured types can't be used to retrieve that info.
^KT-39010 Fixed
Ilya Muradyan