'DFANode' is not created for certain elements, such as types or
references. Before the change, only the target element itself was
queried for DFA, making the 'ContextCollector' return an empty map of
smart casts.
^KTIJ-26973 Fixed
Implement the same behavior as in K1 evaluator. Also see
'IRFragmentCompilerCodegen#codegenFactory' in the IntelliJ project.
The commit fixes the following failing tests in the IntelliJ project:
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$CompilingEvaluator$InaccessibleMembers.testPrivateAnnotationCompanionValue
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$CompilingEvaluator$InaccessibleMembers.testSelfMembers
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$CompilingEvaluator$InaccessibleMembers.testOuterMembers
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$Uncategorized.testPrivateMember
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$Uncategorized.testProperties
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$Uncategorized.testPrivatePropertyWithExplicitDefaultGetter
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$Uncategorized.testPrivateClass
Before, 'KtCodeFragment's were analyzed as a part of their context
session. Now, a separate session is created for each code fragment,
and the LLLibraryScopeAwareCallConflictResolverFactory registration
moved there.
Before, `KtCodeFragment`/`FirCodeFragment` was analyzed as a part of
its context `KtModule`. This has the following complications:
- In non-source sessions, diagnostic reporting is globally disabled.
For code fragments, however, checking the code before passing it to
the backend is essential.
- Special treatment for call ambiguities in libraries
(`LLLibraryScopeAwareCallConflictResolverFactory`) becomes complicated
as the conflict resolver has to be applied to a library module.
- `KtCodeFragment`s usually have a shorter lifetime than their own
context. Caching may potentially be implemented differently for them.
^KT-61783 Fixed
Primary constructors can't have any contracts.
This change also should improve memory consumption because we will
less frequently calculate bodies.
^KT-55750
FirContractResolveTransformer under the hood calls
```
if (property is FirSyntheticProperty) {
transformSimpleFunction(property.getter.delegate, data)
}
```,
so this leads to unsafe transformation of the original function
^KT-55750
Delegated properties can't have any contracts.
This change also should improve memory consumption because we will
less frequently calculate bodies.
^KT-55750
Legacy (current) contracts can exist only on functions with bodies.
This change also should improve memory consumption because we will
less frequently calculate bodies.
^KT-55750
It's implemented as IR checker because in K2 constant expressions are
evaluated on backend. FIR diagnostic removed because isn't needed.
"annotationViaActualTypeAlias" test has no `// FIR_IDENTICAL` because
diagnostic reported on entire typealias declaration instead of its name.
This is because in IR+LightTree we have only offsets, so can't navigate
to typealias name element.
^KT-59940 Fixed
In-block modifications are applicable only for FIR declarations with
fully resolved bodies. It can happen only during implicit type and body
phases. The implicit type phase probably is not applicable for our
particular case, but we will play safe because properties have a
complicated resolution logic, so it is hard to be sure that only body
phase will be enough.
Changes inside contracts are treated as out-of-block, so we can avoid
marker from this phase. Also, all mentioned calls inside bodies resolve
the corresponding declarations to the contract phase, so we will save a
lot with this optimization.
Q: Why in-block modification can be heavy?
A: In most cases this invalidation is pretty cheap because we have all
required information inside caches. But it is possible that we can
receive an in-block modification event for PSI without a corresponding
FIR element, or it is not yet fully resolved. In this case, for example,
we will do such redundant works as a raw FIR building or KtModule search
^KT-61842 Fixed
This is more consistent with the code of
the common compiler checkers.
It would be nice to refactor the contents
of this object further, but it's out
of scope of the current branch.
^KT-54596
Yan Zhulanow